Re: Fetching signal quality during data connection?

[Dan Williams]

On Wed, 2017-02-08 at 14:46 +, colin.helliw...@ln-systems.com
wrote:
> I'm re-visiting this initial issue, of MM not spotting the 'NO
> CARRIER' when the modem times out of data mode. Because of aggro
> getting it working direct on the serial port, I'm back with my mux
> driver (which is what I ultimately need to use anyway).
> I've logged debug messages from both driver and MM. You can see that
> it gets the 'CONNECT', and presumably it would filter out the non-
> text data negotiation bytes anyway. But the 'NO CARRIER' - after the
> timeout - is missed.
> If I do a 'cat /dev/ttyMux0' on one shell, and 'printf
> "ATD*99***1#\r" > /dev/ttyMux0' on the other, then I do see the 'NO
> CARRIER'.
> By the way, the driver debug is of the mux messages hence they're in
> the Data Link Layer form (first 4 bytes are header, last 2 are
> trailer)

I think I see what's going wrong here; it's a mismatch of expectations.

MM puts the port in "connected" mode once it sees the CONNECT, and then
immediately lets whatever is actually driving the data connection
(pppd, something else) handle everything after that.  MM does this
because were it to try to intercept data on the port, that would screw
up the PPP data flow.

So to actually hang up the port, MM depends on the thing that's doing
the PPP to notify MM that the connection has failed, and that MM should
disconnect the bearer.  Once that's done, MM will then re-open the port
and start doing normal stuff like signal strength and registration
checks.  But while PPP is happening, and until PPP says it's done, MM
is completely ignorant of any data on the port.

You could test this manually by disconnecting the bearer with mmcli.

Dan

> I'll keep trying to trace upwards out of the driver, but where would
> be a good point 'low down' in MM to try to see where the message
> is/isn't getting to? (i.e. somewhere lower down than [src/mm-port-
> serial-at.c:459] debug_log())
> 
> 
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.276338] [src/mm-broadband-bearer.c:961] parse_pdp_list():
> Found '2' PDP contexts
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.276489] [src/mm-broadband-bearer.c:970]
> parse_pdp_list():   PDP context [cid=1] [type='ipv4']
> [apn='mobile.o2.co.uk']
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.276613] [src/mm-broadband-bearer.c:970]
> parse_pdp_list():   PDP context [cid=2] [type='ipv4']
> [apn='02.mobile.co.uk']
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.276734] [src/mm-broadband-bearer.c:994] parse_pdp_list():
> Found PDP context with CID 1 and PDP type ipv4 for APN
> 'mobile.o2.co.uk'
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.276920] [src/mm-port-serial.c:1290]
> mm_port_serial_open(): (ttyMux0) device open count is 3 (open)
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.277053] [src/mm-broadband-bearer.c:214]
> common_get_at_data_port(): Connection through a plain serial AT port
> (ttyMux0)
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.277258] [src/mm-port-serial.c:1290]
> mm_port_serial_open(): (ttyMux0) device open count is 4 (open)
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.277516] [src/mm-port-serial.c:1347] _close_internal():
> (ttyMux0) device open count is 3 (close)
> Feb  8 14:32:00 wg6s daemon.info ModemManager[969]: 
> [1486564320.277791] [src/mm-port-serial-at.c:459] debug_log():
> (ttyMux0): --> 'ATD*99***1#'
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: <-  bp_ThreadMuxMsg()
> Ret=true, Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: ->  bp_ThreadMuxMsg()
> Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  8 of 8 bytes written:
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  F9 07 EF 05 41 54 30
> F9  AT0.
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: <-  bp_ThreadMuxMsg()
> Ret=true, Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: ->  bp_ThreadMuxMsg()
> Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  7 of 7 bytes written:
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  F9 07 EF 03 44 D4
> F9 D..
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: <-  bp_ThreadMuxMsg()
> Ret=true, Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: ->  bp_ThreadMuxMsg()
> Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  7 of 7 bytes written:
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  F9 07 EF 03 2A D4
> F9 *..
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: <-  bp_ThreadMuxMsg()
> Ret=true, Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux: ->  bp_ThreadMuxMsg()
> Port=a08ad000 [MuxMsg]
> Feb  8 14:32:00 wg6s user.warn kernel: LinMux:  7 of 7 bytes written:
> Feb  8 14:32:00 wg6s 

crash in mm-device.c:modem_valid

[Ben Chan]

Hi Aleksander and Dan

I encountered a crash in mm-device.c:modem_valid:345 where 'self->priv'
seemed invalid, but 'modem' looked fine. As there is no code to clear the
"notify::base-modem-valid" signal in MMDevice, I think MMDevice currently
relies on auto disconnection of the signal when MMBaseModem is destroyed.
However, there seems to be a circular reference between MMBaseModem and
MMBaseSim (as also indicated in mm_device_remove_modem), so it seems like
MMDevice::dispose doesn't break the cycle.

Both MMDevice::dispose and MMDevice::set_property call 'g_clear_object
(>priv->modem) without calling 'g_object_run_dispose (G_OBJECT
(self->priv->modem)), which seems problematic.  I was thinking about adding
the g_object_run_dispose call, but then wondering if we should instead
address the circular reference between MMBaseModem and MMBaseSim with a
weak reference?

Thanks,
Ben
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

On Feb 10, 2017 4:40 PM, "Aleksander Morgado" 
wrote:

On Fri, Feb 10, 2017 at 11:37 PM, Russ Westrem
 wrote:
> And generic firmware on the mc7455 is what I'm referring to.
>

Oh, so with the Generic firmware you do get a good persistent
connection but not with the Sprint firnmware?

--
Aleksander
https://aleksander.es


Sprint firmware is unusable on the mc7455  on any system.  Generic firmware
is the only one that works with sprint when not authorized by sprint.

I'm using generic firmware.   Its just a little known loophole that works.
The problem is its not working with modem manager for some reason after an
ifup broadband.  It will work for hours but then if a connection drops and
you need to ifup, I start getting the error you saw.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 11:37 PM, Russ Westrem
 wrote:
> And generic firmware on the mc7455 is what I'm referring to.
>

Oh, so with the Generic firmware you do get a good persistent
connection but not with the Sprint firnmware?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

On Feb 10, 2017 4:33 PM, "Aleksander Morgado" 
wrote:

On Fri, Feb 10, 2017 at 11:08 PM, Russ Westrem
 wrote:
> OK.  I think we're getting to the bottom of this.  For some reason if I
drop
> the connection for any reason the mc7455 tries to re-authenticate my
> connection.  I am not authorized to use this device from Sprint so the
work
> around is using it in generic mode and this works as long as a
> reauthorization doesn't try to go through.  Its all making sense now.
>
> That's why after the first drop it would consistently drop after that.  It
> looks like a at!reset is needed for a dropped conection instead of an ifup
> broadband.  Unless I can figure out how to make the mc7455 try to
> reauthorization in generic mode again.

What do you mean with generic mode?

Doesn't MM retry the auth step on the next reconnection?

--
Aleksander
https://aleksander.es





It does after I issue an ifup broadband.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

On Feb 10, 2017 4:35 PM, "Russ Westrem"  wrote:



On Feb 10, 2017 4:33 PM, "Aleksander Morgado" 
wrote:

On Fri, Feb 10, 2017 at 11:08 PM, Russ Westrem
 wrote:
> OK.  I think we're getting to the bottom of this.  For some reason if I
drop
> the connection for any reason the mc7455 tries to re-authenticate my
> connection.  I am not authorized to use this device from Sprint so the
work
> around is using it in generic mode and this works as long as a
> reauthorization doesn't try to go through.  Its all making sense now.
>
> That's why after the first drop it would consistently drop after that.  It
> looks like a at!reset is needed for a dropped conection instead of an ifup
> broadband.  Unless I can figure out how to make the mc7455 try to
> reauthorization in generic mode again.

What do you mean with generic mode?

Doesn't MM retry the auth step on the next reconnection?

--
Aleksander
https://aleksander.es





It does after I issue an ifup broadband.




And generic firmware on the mc7455 is what I'm referring to.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 11:08 PM, Russ Westrem
 wrote:
> OK.  I think we're getting to the bottom of this.  For some reason if I drop
> the connection for any reason the mc7455 tries to re-authenticate my
> connection.  I am not authorized to use this device from Sprint so the work
> around is using it in generic mode and this works as long as a
> reauthorization doesn't try to go through.  Its all making sense now.
>
> That's why after the first drop it would consistently drop after that.  It
> looks like a at!reset is needed for a dropped conection instead of an ifup
> broadband.  Unless I can figure out how to make the mc7455 try to
> reauthorization in generic mode again.

What do you mean with generic mode?

Doesn't MM retry the auth step on the next reconnection?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

On Feb 10, 2017 3:24 PM, "Bjørn Mork"  wrote:

Aleksander Morgado  writes:

> You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:
>
> Cause value = 36 Regular deactivation

Oh, I didn't fint that.  I guess this is in some other table there?

I'm glad I don't have to navigate these standards


Bjørn



OK.  I think we're getting to the bottom of this.  For some reason if I
drop the connection for any reason the mc7455 tries to re-authenticate my
connection.  I am not authorized to use this device from Sprint so the work
around is using it in generic mode and this works as long as a
reauthorization doesn't try to go through.  Its all making sense now.

That's why after the first drop it would consistently drop after that.  It
looks like a at!reset is needed for a dropped conection instead of an ifup
broadband.  Unless I can figure out how to make the mc7455 try to
reauthorization in generic mode again.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Bjørn Mork]

Aleksander Morgado  writes:

> You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:
>
> Cause value = 36 Regular deactivation

Oh, I didn't fint that.  I guess this is in some other table there?

I'm glad I don't have to navigate these standards


Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Bjørn Mork]

Aleksander Morgado  writes:

> On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
>  wrote:
>> Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
>> message...
 RAW:
   length = 80
   data   =
 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0C:00:00:00:24:00:00:00:00:00:00:00:03:00:00:00:00:00:00:00:00:00:00:00:7E:5E:2A:7E:4E:6F:72:72:73:6B:65:6E:7E:5E:2A:7E:24:00:00:00
>> Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
>> message (translated)...
 Header:
   length  = 80
   type= indicate-status (0x8007)
   transaction = 0
 Fragment header:
   total   = 1
   current = 0
 Contents:
   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
   cid = 'connect' (0x000c)
>> Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Received notification
>> (service 'basic-connect', command 'connect')
>> Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Session ID '0' was
>> deactivated.
>
> Interesting; the last 4 bytes in the indication give us NwError =
> 0x24, which we don't have mapped in the enum:
>
> MBIM_NW_ERROR_GSM_AUTHENTICATION_UNACCEPTABLE = 23,
> MBIM_NW_ERROR_NOT_AUTHORIZED_FOR_CSG  = 25,


Well, those numbers are in decimal :)

But it doesn't help us much.  36 is also undefined AFAIK. I had to go
and look at the latest version of TS 24.008 table 10.5.95 "Reject Cause
information element", and there is a hole between

  34 "Service option temporarily out of order"

and

  38 "Call cannot be identified"

But it does still ring a bell... Haven't we seen this before somewhere?



Bjørn

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

You're getting error 0x24 (dec 36), and according to 3GPP 24008 that is:

Cause value = 36 Regular deactivation
This cause code is used to indicate a regular MS or network initiated
PDP context deactivation or a regular network initiated MBMS context
deactivation.

so the network is de-registering you for some reason...

BTW; we should update the NwError list with all codes...

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Sorry I meant remap =24 to be acceptable?

On Feb 10, 2017 2:58 PM, "Russ Westrem"  wrote:

> Could we remap =23 to be acceptable?
>
> On Feb 10, 2017 2:56 PM, "Russ Westrem" 
> wrote:
>
>> I am using a sprint plan in generic mode on the mc7455.  Does this have
>> anything to do with it?
>>
>> On Feb 10, 2017 2:46 PM, "Aleksander Morgado" 
>> wrote:
>>
>> On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
>>  wrote:
>> > Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
>> > message...
>> >>> RAW:
>> >>>   length = 80
>> >>>   data   =
>> >>> 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:
>> A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0C:00:00:00:
>> 24:00:00:00:00:00:00:00:03:00:00:00:00:00:00:00:00:00:00:00:
>> 7E:5E:2A:7E:4E:6F:72:72:73:6B:65:6E:7E:5E:2A:7E:24:00:00:00
>> > Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
>> > message (translated)...
>> >>> Header:
>> >>>   length  = 80
>> >>>   type= indicate-status (0x8007)
>> >>>   transaction = 0
>> >>> Fragment header:
>> >>>   total   = 1
>> >>>   current = 0
>> >>> Contents:
>> >>>   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec
>> 2aae6df)
>> >>>   cid = 'connect' (0x000c)
>> > Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Received
>> notification
>> > (service 'basic-connect', command 'connect')
>> > Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Session ID '0' was
>> > deactivated.
>>
>> Interesting; the last 4 bytes in the indication give us NwError =
>> 0x24, which we don't have mapped in the enum:
>>
>> MBIM_NW_ERROR_GSM_AUTHENTICATION_UNACCEPTABLE =
>> 23,
>> MBIM_NW_ERROR_NOT_AUTHORIZED_FOR_CSG  =
>> 25,
>>
>>
>> --
>> Aleksander
>> https://aleksander.es
>>
>>
>>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Could we remap =23 to be acceptable?

On Feb 10, 2017 2:56 PM, "Russ Westrem"  wrote:

> I am using a sprint plan in generic mode on the mc7455.  Does this have
> anything to do with it?
>
> On Feb 10, 2017 2:46 PM, "Aleksander Morgado" 
> wrote:
>
> On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
>  wrote:
> > Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
> > message...
> >>> RAW:
> >>>   length = 80
> >>>   data   =
> >>> 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:
> A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0C:00:00:00:
> 24:00:00:00:00:00:00:00:03:00:00:00:00:00:00:00:00:00:00:00:
> 7E:5E:2A:7E:4E:6F:72:72:73:6B:65:6E:7E:5E:2A:7E:24:00:00:00
> > Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
> > message (translated)...
> >>> Header:
> >>>   length  = 80
> >>>   type= indicate-status (0x8007)
> >>>   transaction = 0
> >>> Fragment header:
> >>>   total   = 1
> >>>   current = 0
> >>> Contents:
> >>>   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
> >>>   cid = 'connect' (0x000c)
> > Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Received
> notification
> > (service 'basic-connect', command 'connect')
> > Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Session ID '0' was
> > deactivated.
>
> Interesting; the last 4 bytes in the indication give us NwError =
> 0x24, which we don't have mapped in the enum:
>
> MBIM_NW_ERROR_GSM_AUTHENTICATION_UNACCEPTABLE =
> 23,
> MBIM_NW_ERROR_NOT_AUTHORIZED_FOR_CSG  =
> 25,
>
>
> --
> Aleksander
> https://aleksander.es
>
>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 9:37 PM, Russ Westrem
 wrote:
> Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
> message...
>>> RAW:
>>>   length = 80
>>>   data   =
>>> 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0C:00:00:00:24:00:00:00:00:00:00:00:03:00:00:00:00:00:00:00:00:00:00:00:7E:5E:2A:7E:4E:6F:72:72:73:6B:65:6E:7E:5E:2A:7E:24:00:00:00
> Fri Feb 10 14:33:23 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
> message (translated)...
>>> Header:
>>>   length  = 80
>>>   type= indicate-status (0x8007)
>>>   transaction = 0
>>> Fragment header:
>>>   total   = 1
>>>   current = 0
>>> Contents:
>>>   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>>>   cid = 'connect' (0x000c)
> Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Received notification
> (service 'basic-connect', command 'connect')
> Fri Feb 10 14:33:23 2017 daemon.info [1042]:  Session ID '0' was
> deactivated.

Interesting; the last 4 bytes in the indication give us NwError =
0x24, which we don't have mapped in the enum:

MBIM_NW_ERROR_GSM_AUTHENTICATION_UNACCEPTABLE = 23,
MBIM_NW_ERROR_NOT_AUTHORIZED_FOR_CSG  = 25,


-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Fri Feb 10 14:33:07 2017 daemon.info [1042]:  IPv4 configuration
available: 'address, gateway, dns, mtu'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:IP addresses (1)
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  IP [0]: '
25.22.233.27/29'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:Gateway:
'25.22.233.28'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:DNS addresses (2)
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  DNS [0]:
'68.28.67.132'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  DNS [1]:
'68.28.68.132'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:MTU: '1500'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  IPv6 configuration
available: 'none'
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  (wwan0): port now
connected
Fri Feb 10 14:33:07 2017 daemon.info [1042]:  Connected bearer
'/org/freedesktop/ModemManager1/Bearer/29'
Fri Feb 10 14:33:07 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Sent
message...
<< RAW:
<<   length = 48
<<   data   =
03:00:00:00:30:00:00:00:C9:02:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:00:00:00:00
Fri Feb 10 14:33:07 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Sent message
(translated)...
<< Header:
<<   length  = 48
<<   type= command (0x0003)
<<   transaction = 713
<< Fragment header:
<<   total   = 1
<<   current = 0
<< Contents:
<<   service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
<<   cid = 'packet-statistics' (0x0014)
<<   type= 'query' (0x)
Fri Feb 10 14:33:07 2017 daemon.info [1042]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (connecting ->
connected)
Fri Feb 10 14:33:07 2017 daemon.info [1042]:   Simple connect state
(8/8): All done
Fri Feb 10 14:33:07 2017 daemon.notice netifd: broadband (14308):
successfully connected the modem
Fri Feb 10 14:33:07 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
message...
>> RAW:
>>   length = 96
>>   data   =
03:00:00:80:60:00:00:00:C9:02:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:30:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
Fri Feb 10 14:33:07 2017 daemon.debug [1042]: [/dev/cdc-wdm0] Received
message (translated)...
>> Header:
>>   length  = 96
>>   type= command-done (0x8003)
>>   transaction = 713
>> Fragment header:
>>   total   = 1
>>   current = 0
>> Contents:
>>   status error = 'None' (0x)
>>   service  = 'basic-connect'
(a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>>   cid  = 'packet-statistics' (0x0014)
Fri Feb 10 14:33:07 2017 daemon.notice netifd: broadband (14308): network
operator name: Sprint
Fri Feb 10 14:33:07 2017 daemon.notice netifd: broadband (14308): network
operator MCCMNC: 310120
Fri Feb 10 14:33:07 2017 daemon.notice netifd: broadband (14308):
registration type: home
Fri Feb 10 14:33:08 2017 daemon.notice netifd: broadband (14308): access
technology: lte
Fri Feb 10 14:33:08 2017 daemon.notice netifd: broadband (14308): signal
quality: 0%
Fri Feb 10 14:33:08 2017 daemon.notice netifd: broadband (14308):
connection setup required in interface wwan0: static
Fri Feb 10 14:33:09 2017 daemon.notice netifd: broadband (14308): adding
IPv4 address 25.22.233.27, netmask 255.255.255.248
Fri Feb 10 14:33:09 2017 daemon.notice netifd: broadband (14308): adding
default IPv4 route via 25.22.233.28
Fri Feb 10 14:33:09 2017 daemon.notice netifd: broadband (14308): adding
primary DNS at 68.28.67.132
Fri Feb 10 14:33:09 2017 daemon.notice netifd: broadband (14308): adding
secondary DNS at 68.28.68.132
Fri Feb 10 14:33:09 2017 daemon.notice netifd: Interface 'broadband' is now
up
Fri Feb 10 14:33:09 2017 daemon.info dnsmasq[3116]: reading
/tmp/resolv.conf.auto
Fri Feb 10 14:33:09 2017 daemon.info dnsmasq[3116]: using local addresses
only for domain lan
Fri Feb 10 14:33:09 2017 daemon.notice netifd: Network device 'wwan0' link
is up
Fri Feb 10 14:33:09 2017 daemon.info dnsmasq[3116]: using nameserver
68.28.67.132#53
Fri Feb 10 14:33:09 2017 daemon.info dnsmasq[3116]: using nameserver
68.28.68.132#53
Fri Feb 10 14:33:09 2017 kern.info kernel: [ 7007.528440] 8021q: adding
VLAN 0 to HW filter on device wwan0
Fri Feb 10 14:33:09 2017 user.notice firewall: Reloading firewall due to
ifup of broadband (wwan0)
Fri Feb 10 14:33:10 2017 daemon.info odhcpd[736]: Initial RA router
lifetime 0, 1 address(es) available on br-lan
Fri Feb 10 14:33:11 2017 daemon.info [1042]:  (ttyUSB1) device open
count is 2 (open)
Fri Feb 10 14:33:11 2017 daemon.info [1042]:  (ttyUSB1): -->
'AT+CCLK?'
Fri Feb 10 14:33:11 2017 daemon.info [1042]:  (ttyUSB1): <--
'+CCLK: "17/02/10,20:33:29-24"OK'
Fri Feb 10 14:33:11 2017 daemon.info [1042]:  (ttyUSB1) device open
count is 1 (close)
Fri Feb 10 14:33:23 2017 

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Should I set it to 0?

On Feb 10, 2017 2:08 PM, "Russ Westrem"  wrote:

> It's unset at the moment.
>
> On Feb 10, 2017 2:07 PM, "Aleksander Morgado" 
> wrote:
>
>> On Fri, Feb 10, 2017 at 7:46 PM, Russ Westrem
>>  wrote:
>> > Ok.  So it seems I may have spoken a little too soon on the powered usb
>> hub
>> > working.  Here is something I have noticed.
>> >
>> > It works for hours and hours at a time on bearer 0. Once an ifup is
>> issued
>> > to fix a downed connection the bearer changes to 1 then 2 and so on.  On
>> > these other bearers the disconects happen after a few minutes
>> consistently.
>>
>> The bearer number shouldn't be an issue; the netifd protocol handler
>> does remove all bearers before relaunching a new connection each time
>> (not sure why I did it that way, though).
>>
>> Do you have by any chance the "lowpower" setting in the interface set
>> to 1? Or is that unset?
>>
>> --
>> Aleksander
>> https://aleksander.es
>>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 7:46 PM, Russ Westrem
 wrote:
> Ok.  So it seems I may have spoken a little too soon on the powered usb hub
> working.  Here is something I have noticed.
>
> It works for hours and hours at a time on bearer 0. Once an ifup is issued
> to fix a downed connection the bearer changes to 1 then 2 and so on.  On
> these other bearers the disconects happen after a few minutes consistently.

The bearer number shouldn't be an issue; the netifd protocol handler
does remove all bearers before relaunching a new connection each time
(not sure why I did it that way, though).

Do you have by any chance the "lowpower" setting in the interface set
to 1? Or is that unset?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Ok.  So it seems I may have spoken a little too soon on the powered usb hub
working.  Here is something I have noticed.

It works for hours and hours at a time on bearer 0. Once an ifup is issued
to fix a downed connection the bearer changes to 1 then 2 and so on.  On
these other bearers the disconects happen after a few minutes consistently.


On Feb 10, 2017 11:11 AM, "lspwaterproofing" 
wrote:

> 4 hours up using the usb powered hub.
>
>
>
> Sent from my Sprint Samsung Galaxy Note5.
>
>  Original message 
> From: Aleksander Morgado 
> Date: 2/10/17 3:34 AM (GMT-06:00)
> To: lspwaterproofing 
> Cc: Dan Williams , Sebastian Sjoholm <
> sebastian.sjoh...@gmail.com>, Mark Wahlert ,
> ModemManager 
> Subject: Re: How to issue an "ifup broadband" when this is logged
>
> On Thu, Feb 9, 2017 at 10:55 PM, lspwaterproofing
>  wrote:
> > Also I'm using the same exact modem in the same location on Ubuntu 16.04
> > using ModemManager with all the same settings and it stays up for hours
> with
> > no interruptions.  So its not a network issue.
>
> Ok, the network disconnection happen when using the modem on a router
> running LEDE, right? Maybe the router doesn't provide enough power in
> the USB port? Have you tried to use an external *powered* USB hub in
> between the modem and the router?
>
> --
> Aleksander
> https://aleksander.es
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Handling received SMS

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 3:40 PM,   wrote:
> I’m digging into SMS reception, and trying understand how MM deals with it.
>
> I can see that it/mmcli reads the messages when the modem is enabled. When a
> new SMS is then received, I can see the modem sending a “+CIEV: message,1”
> [but only the first time, if the first message isn’t then read?].
>
> I kind of expected/hoped MM would then fetch the message out and update its
> internal list, but it doesn’t seem to. Nor does mmcli have an option to
> re-read SMS’s from the modem?
>
> Is there this facility in the library, if not in mmcli, and/or am I missing
> something?

MM should be updating its internal list on every received SMS; if it's
not doing that please grab debug logs while reproducing the issue and
we'll try to see why.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Modem creation/startup order

[Aleksander Morgado]

On Fri, Feb 10, 2017 at 3:39 PM,   wrote:
> I’ve got two ports whitelisted for use by MM. What determines which one of
> them will be ‘Modem/0’ ?
>

Just the first modem that finishes first probing all ports.

> Is there a way to get MM to create/initialise 0 first, then 1 – as opposed
> to doing both in *parallel*?
>

Nope, no way, they will be done in parallel. Note, though, that you
can "name" modems or refer to them directly using the physical device
USB path, which won't change across reboots:
https://sigquit.wordpress.com/2016/10/06/naming-devices-in-modemmanager/

>
>
> I’m getting MM to use the Cinterion plugin for my modem, by adding
>
> ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1", ENV{ID_VENDOR_ID}="0x1e2d",
> ENV{ID_MODEL_ID}="0x0001”
>
> to the udev rule (the port is a tty); together with mods to the plugin code,
> to set its MM_PLUGIN_ALLOWED_DRIVERS to the modem’s driver name.
>
> However it’s also deciding to also try 3 other plugins (as well as Generic)
> – Via, Iridium, Nokia.  It’s not a major problem because it does try
> Cinterion first, and decide it’s the best one. But why the other candidates?

The plugin that has a VID:PID list and matches the VID:PID of your
modem will always be tested first. The additional plugins are plugins
that support RAW RS232 devices; i.e. plugins where in addition to a
VID:PID list we also do AT queries to load vendor and product strings,
and we match against them. Think of a RS232 modem behind a USB
adapter, there is no VID:PID match possible there, but the plugins
still query the modem to decide which is the best plugin.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion plugin (in)compatibilities

[matthew stanger]

Hi Colin,

I'm not a core maintainer but I've recently done some work on the Cinterion
plugin. I've been actually hoping to do some more but have been overwhelmed
the last 2 months with person life oblations. Anyways the next patch I'll
be submitting in fact is for Cinterions updated GPS commands. I'm not sure
if those modems you mentioned support the new ones (SGPSC vs. SGPSS). If
your interested in that though I'm hoping to have that patch submitted in 3
weekish, i.e. I'm still booked solid for the next 2.5. As far as your other
questions I don't think I know enough to answer them but I'm sure if you
post them here Aleksander & others will give you some guidance.

Cheers,
Matt

On Fri, Feb 10, 2017 at 7:40 AM,  wrote:

> For simplicity, I’d begun my exploration of MM using the Generic plugin.
> My design has a choice of two Cinterion modems (BGS2 and EHS5), though they
> don’t have much of the functionality supported by the Cinterion plugin such
> as GPS.
>
> But because of one command incompatibility (CMER) with the Generic, I
> decided to try the Cinterion plugin. This addresses the CMER issue, but
> throws up more incompatibilities due to differing versions of Cinterion
> commands sets.
>
> If Generic turns out to be the closest fit then I could just patch it as
> needed. But I also wondered if there’s a key Maintainer of the Cinterion
> plugin who might like to discuss what I’ve found with a view to
> incorporating the variations somehow? Or I could patch the plugin. Or I
> could generate *another* Cinterion plugin….
>
>
>
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[lspwaterproofing]

4 hours up using the usb powered hub.


Sent from my Sprint Samsung Galaxy Note5.
 Original message From: Aleksander Morgado 
 Date: 2/10/17  3:34 AM  (GMT-06:00) To: 
lspwaterproofing  Cc: Dan Williams 
, Sebastian Sjoholm , Mark 
Wahlert , ModemManager 
 Subject: Re: How to issue an "ifup 
broadband" when this is logged 
On Thu, Feb 9, 2017 at 10:55 PM, lspwaterproofing
 wrote:
> Also I'm using the same exact modem in the same location on Ubuntu 16.04
> using ModemManager with all the same settings and it stays up for hours with
> no interruptions.  So its not a network issue.

Ok, the network disconnection happen when using the modem on a router
running LEDE, right? Maybe the router doesn't provide enough power in
the USB port? Have you tried to use an external *powered* USB hub in
between the modem and the router?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Cinterion plugin (in)compatibilities

[colin.helliwell]

For simplicity, I'd begun my exploration of MM using the Generic plugin. My
design has a choice of two Cinterion modems (BGS2 and EHS5), though they
don't have much of the functionality supported by the Cinterion plugin such
as GPS. 

But because of one command incompatibility (CMER) with the Generic, I
decided to try the Cinterion plugin. This addresses the CMER issue, but
throws up more incompatibilities due to differing versions of Cinterion
commands sets.

If Generic turns out to be the closest fit then I could just patch it as
needed. But I also wondered if there's a key Maintainer of the Cinterion
plugin who might like to discuss what I've found with a view to
incorporating the variations somehow? Or I could patch the plugin. Or I
could generate *another* Cinterion plugin..

 

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Handling received SMS

[colin.helliwell]

I'm digging into SMS reception, and trying understand how MM deals with it. 

I can see that it/mmcli reads the messages when the modem is enabled. When a
new SMS is then received, I can see the modem sending a "+CIEV: message,1"
[but only the first time, if the first message isn't then read?]. 

I kind of expected/hoped MM would then fetch the message out and update its
internal list, but it doesn't seem to. Nor does mmcli have an option to
re-read SMS's from the modem?

Is there this facility in the library, if not in mmcli, and/or am I missing
something?

 

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Modem creation/startup order

[colin.helliwell]

I've got two ports whitelisted for use by MM. What determines which one of
them will be 'Modem/0' ?

Is there a way to get MM to create/initialise 0 first, then 1 - as opposed
to doing both in *parallel*?

 

I'm getting MM to use the Cinterion plugin for my modem, by adding 

ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1", ENV{ID_VENDOR_ID}="0x1e2d",
ENV{ID_MODEL_ID}="0x0001"

to the udev rule (the port is a tty); together with mods to the plugin code,
to set its MM_PLUGIN_ALLOWED_DRIVERS to the modem's driver name.

However it's also deciding to also try 3 other plugins (as well as Generic)
- Via, Iridium, Nokia.  It's not a major problem because it does try
Cinterion first, and decide it's the best one. But why the other candidates?

 

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Russ Westrem]

Yes.  Only when using lede on a router.  I just hooked it to a powered usb
hub.  I am testing now. I will keep everyone posted.

The mc7455 on Ubuntu 16.04 with modemmanager went 24 hours with not a
single packet dropped while playing 2 hd videos at the same time.

On Feb 10, 2017 3:34 AM, "Aleksander Morgado" 
wrote:

On Thu, Feb 9, 2017 at 10:55 PM, lspwaterproofing
 wrote:
> Also I'm using the same exact modem in the same location on Ubuntu 16.04
> using ModemManager with all the same settings and it stays up for hours
with
> no interruptions.  So its not a network issue.

Ok, the network disconnection happen when using the modem on a router
running LEDE, right? Maybe the router doesn't provide enough power in
the USB port? Have you tried to use an external *powered* USB hub in
between the modem and the router?

--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: How to issue an "ifup broadband" when this is logged

[Aleksander Morgado]

On Thu, Feb 9, 2017 at 10:55 PM, lspwaterproofing
 wrote:
> Also I'm using the same exact modem in the same location on Ubuntu 16.04
> using ModemManager with all the same settings and it stays up for hours with
> no interruptions.  So its not a network issue.

Ok, the network disconnection happen when using the modem on a router
running LEDE, right? Maybe the router doesn't provide enough power in
the USB port? Have you tried to use an external *powered* USB hub in
between the modem and the router?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] libmm-glib: set clear func by default in the MMModemPortInfo array

[Aleksander Morgado]

On Thu, Feb 9, 2017 at 3:54 PM, Piotr Figiel  wrote:
>  I tested your patch and the reported issue doesn't appear any longer.
>  It all looks good and certainly better (more glib-style) than my initial
> implementation. Although I wonder if this doesn't ever collide with
> mm_modem_port_info_array_free() in mm-helper-types.c? It seems that two ways
> of dealing with memory management are taken for the same data structure,
> though I didn't observe any double-free's on this part during runtime, so I
> guess this must be correct.

No, they won't collide. The mm_modem_port_info_array_free() frees a
plain array of MMModemPortInfo, and is meant to be used by users of
the API. The GArray and its clear_func are internal to libmm-glib.

Thanks for testing, pushed to git master, mm-1-6, mm-1-4 and mm-1-2.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel