RE: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-05-01 Thread Matthew Starr 
> -Original Message-
> From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> Sent: Monday, April 30, 2018 6:50 PM
> 
> On Mon, Apr 30, 2018 at 10:45 PM, Dan Williams  wrote:
> > On Mon, 2018-04-30 at 20:09 +, Matthew Starr wrote:
> >> > -Original Message-
> >> > From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> >> >
> >> > >
> >> > > I don't understand why there is a 20 second timeout.  Couldn't
> >> > > you just test
> >> >
> >> > the AT interface right away with 'AT' instead of waiting a timeout
> >> > and then
> >> > trying it.  Also 20 seconds is a long time.  Couldn't a much
> >> > shorter timeout be
> >> > put in with some message sent to the modem to get it to respond
> >> > (like 'AT')
> >> > and do that several times to add up to 20 seconds.  This seems like
> >> > it would
> >> > be much quicker in cases where the modem did not respond
> >> > immediately
> >> > and might resolve this issue.
> >> > >
> >> >
> >> > That 20s timeout is really an artifact added for the TOBY-L4, to
> >> > wait
> >> > for the +READY URC it sends if the port is detected via hotplug
> >> > events. It's actually just to make it quicker the probing in the
> >> > TOBY-L4. This should be therefore something specific for the TOBY-
> >> > L4
> >> > and not something generic for all u-blox modems... sorry for that
> >> > :/
> >> >
> >> > I'll gladly accept a patch that makes this 20s timeout something
> >> > specific for the TOBY-L4 ;)
> >>
> >> I changed that timeout to 2 seconds and it resolved the 20 second
> >> timeout I was seeing.  Now as you said it needs to be something
> >> specific for the TOBY-L4.  At this early of a point in registration
> >> you haven't read the model number yet since communication hasn't been
> >> established.  The only way I can think of detecting the TOBY-L4 is
> >> using the USB product ID.
> >>
> >> Is there a function that allows obtaining the USB product ID that can
> >> be used in the context of the wait_for_ready() function in the
> >> plugins/ublox/mm-plugin-ublox.c file?  I tried the
> >> mm_port_probe_get_product() function called within the
> >> wait_for_ready() function, but just got (null) returned.
> >>
> >> Do you know if the TOBY-L4 has a unique USB product ID?  If so, do
> >> you know what it is?
> >
> > Could do it through udev tags too; eg tag TOBY-L4 in the udev rules as
> > needing a larger timeout, but all the rest get a shorter one.
> >
> 
> Yes, I was thinking in udev tags as well. For the TOBY-L4:
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="1010"

I took a slightly different approach in a patch set I just submitted.  I made a 
global way to set a ready delay through a new udev tag.  I figured that there 
are other modems that don't respond correctly during a certain amount of time 
after they are reset and this configurable delay through udev flags could be 
added to other plugins.

I then re-implemented the 20 second delay for the TOBY-L4 using this new udev 
method.

I didn't submit a patch for the TOBY-R2, but at boot I can get the modem to 
come up faster if I use a ready delay of 35 seconds on my device.  The reason 
this helps is the device has time to auto register with the cell network before 
MM probes the modem resulting in about one second between probing finish and a 
full simple connect.  This is faster than the 60-70 seconds it takes to do a 
simple connect when MM probes the modem before the modem has registered with 
the network.  This is really more of a workaround for the issue of MM not 
letting the TOBY-R2 modem auto register on its own instead of forcing a full 
re-register.  This is also why I did not include the TOBY-R2 timeout in the 
patch set.

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

Re: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-30 Thread Aleksander Morgado 
On Mon, Apr 30, 2018 at 10:45 PM, Dan Williams  wrote:
> On Mon, 2018-04-30 at 20:09 +, Matthew Starr wrote:
>> > -Original Message-
>> > From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
>> >
>> > >
>> > > I don't understand why there is a 20 second timeout.  Couldn't
>> > > you just test
>> >
>> > the AT interface right away with 'AT' instead of waiting a timeout
>> > and then
>> > trying it.  Also 20 seconds is a long time.  Couldn't a much
>> > shorter timeout be
>> > put in with some message sent to the modem to get it to respond
>> > (like 'AT')
>> > and do that several times to add up to 20 seconds.  This seems like
>> > it would
>> > be much quicker in cases where the modem did not respond
>> > immediately
>> > and might resolve this issue.
>> > >
>> >
>> > That 20s timeout is really an artifact added for the TOBY-L4, to
>> > wait
>> > for the +READY URC it sends if the port is detected via hotplug
>> > events. It's actually just to make it quicker the probing in the
>> > TOBY-L4. This should be therefore something specific for the TOBY-
>> > L4
>> > and not something generic for all u-blox modems... sorry for that
>> > :/
>> >
>> > I'll gladly accept a patch that makes this 20s timeout something
>> > specific for the TOBY-L4 ;)
>>
>> I changed that timeout to 2 seconds and it resolved the 20 second
>> timeout I was seeing.  Now as you said it needs to be something
>> specific for the TOBY-L4.  At this early of a point in registration
>> you haven't read the model number yet since communication hasn't been
>> established.  The only way I can think of detecting the TOBY-L4 is
>> using the USB product ID.
>>
>> Is there a function that allows obtaining the USB product ID that can
>> be used in the context of the wait_for_ready() function in the
>> plugins/ublox/mm-plugin-ublox.c file?  I tried the
>> mm_port_probe_get_product() function called within the
>> wait_for_ready() function, but just got (null) returned.
>>
>> Do you know if the TOBY-L4 has a unique USB product ID?  If so, do
>> you know what it is?
>
> Could do it through udev tags too; eg tag TOBY-L4 in the udev rules as
> needing a larger timeout, but all the rest get a shorter one.
>

Yes, I was thinking in udev tags as well. For the TOBY-L4:
ATTRS{idVendor}=="1546", ATTRS{idProduct}=="1010"

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

Re: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-30 Thread Dan Williams 
On Mon, 2018-04-30 at 20:09 +, Matthew Starr wrote:
> > -Original Message-
> > From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> > 
> > > 
> > > I don't understand why there is a 20 second timeout.  Couldn't
> > > you just test
> > 
> > the AT interface right away with 'AT' instead of waiting a timeout
> > and then
> > trying it.  Also 20 seconds is a long time.  Couldn't a much
> > shorter timeout be
> > put in with some message sent to the modem to get it to respond
> > (like 'AT')
> > and do that several times to add up to 20 seconds.  This seems like
> > it would
> > be much quicker in cases where the modem did not respond
> > immediately
> > and might resolve this issue.
> > > 
> > 
> > That 20s timeout is really an artifact added for the TOBY-L4, to
> > wait
> > for the +READY URC it sends if the port is detected via hotplug
> > events. It's actually just to make it quicker the probing in the
> > TOBY-L4. This should be therefore something specific for the TOBY-
> > L4
> > and not something generic for all u-blox modems... sorry for that
> > :/
> > 
> > I'll gladly accept a patch that makes this 20s timeout something
> > specific for the TOBY-L4 ;)
> 
> I changed that timeout to 2 seconds and it resolved the 20 second
> timeout I was seeing.  Now as you said it needs to be something
> specific for the TOBY-L4.  At this early of a point in registration
> you haven't read the model number yet since communication hasn't been
> established.  The only way I can think of detecting the TOBY-L4 is
> using the USB product ID.
> 
> Is there a function that allows obtaining the USB product ID that can
> be used in the context of the wait_for_ready() function in the
> plugins/ublox/mm-plugin-ublox.c file?  I tried the
> mm_port_probe_get_product() function called within the
> wait_for_ready() function, but just got (null) returned.
> 
> Do you know if the TOBY-L4 has a unique USB product ID?  If so, do
> you know what it is?

Could do it through udev tags too; eg tag TOBY-L4 in the udev rules as
needing a larger timeout, but all the rest get a shorter one.

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

RE: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-30 Thread Matthew Starr 

> -Original Message-
> From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> 
> >
> > I don't understand why there is a 20 second timeout.  Couldn't you just test
> the AT interface right away with 'AT' instead of waiting a timeout and then
> trying it.  Also 20 seconds is a long time.  Couldn't a much shorter timeout 
> be
> put in with some message sent to the modem to get it to respond (like 'AT')
> and do that several times to add up to 20 seconds.  This seems like it would
> be much quicker in cases where the modem did not respond immediately
> and might resolve this issue.
> >
> 
> That 20s timeout is really an artifact added for the TOBY-L4, to wait
> for the +READY URC it sends if the port is detected via hotplug
> events. It's actually just to make it quicker the probing in the
> TOBY-L4. This should be therefore something specific for the TOBY-L4
> and not something generic for all u-blox modems... sorry for that :/
> 
> I'll gladly accept a patch that makes this 20s timeout something
> specific for the TOBY-L4 ;)

I changed that timeout to 2 seconds and it resolved the 20 second timeout I was 
seeing.  Now as you said it needs to be something specific for the TOBY-L4.  At 
this early of a point in registration you haven't read the model number yet 
since communication hasn't been established.  The only way I can think of 
detecting the TOBY-L4 is using the USB product ID.

Is there a function that allows obtaining the USB product ID that can be used 
in the context of the wait_for_ready() function in the 
plugins/ublox/mm-plugin-ublox.c file?  I tried the mm_port_probe_get_product() 
function called within the wait_for_ready() function, but just got (null) 
returned.

Do you know if the TOBY-L4 has a unique USB product ID?  If so, do you know 
what it is?

Regards,
Matthew Starr

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

Re: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-30 Thread Aleksander Morgado 
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408139] [plugin manager] task 4,ttyACM0: found '7' plugins to try
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408278] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'u-blox'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408414] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Telit'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408538] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Via CBP7'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408662] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Iridium'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408789] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Nokia'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.408907] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Cinterion'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.409032] [plugin manager] task 4,ttyACM0: will try with plugin 
> 'Generic'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.409184] [plugin manager) task 4,ttyACM0: started
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.409322] [plugin manager] task 4,ttyACM0: checking with plugin 
> 'u-blox'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.409547] (u-blox) [ttyACM0] probe required: 'at'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.409740] (tty/ttyACM0) launching port probing: 'at'
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.411520] [plugin manager] task 4,ttyACM0: got suggested plugin 
> (u-blox)
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.414868] [plugin Manager] task 4: still 1 running probes (1 
> active): ttyACM0
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.428515] (ttyACM0) opening serial port...
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.430200] (ttyACM0): setting up baudrate: 57600
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.431460] (ttyACM0) device open count is 1 (open)
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.432402] (ttyACM0): port attributes not fully set
> Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
> [1523286640.533980] (tty/ttyACM0) waiting for READY unsolicited message...
> Apr  9 15:10:41 canect2 daemon.debug ModemManager[252]:  
> [1523286641.372499] [plugin manager] task 4: min probing time elapsed
> Apr  9 15:10:41 canect2 daemon.debug ModemManager[252]:  
> [1523286641.372683] [plugin Manager] task 4: still 1 running probes (1 
> active): ttyACM0
> Apr  9 15:10:41 canect2 daemon.debug ModemManager[252]:  
> [1523286641.697020] (ttyACM0): <-- '+PACSP0'
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.874992] (tty/ttyACM0) timed out waiting for READY unsolicited 
> message
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.875680] (ttyACM0): --> 'AT'
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.879180] (ttyACM0): <-- 'ATOK'
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.879990] (tty/ttyACM0) port is AT-capable
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.880393] [plugin manager] task 4,ttyACM0: found best plugin for 
> port (u-blox)
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.880603] [plugin manager] task 4,ttyACM0: finished in '22.009174' 
> seconds
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.880830] [plugin manager] task 4,ttyACM0: best plugin matches 
> device reported one: u-blox
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.880996] [plugin manager] task 4: no more ports to probe
> Apr  9 15:11:00 canect2 daemon.debug ModemManager[252]:  
> [1523286660.881226] [plugin manager] task 4: finished in '22.010629' seconds
>
> The above issue where the 20 second timeout occurs is only if MM starts 
> before the ttyACM interfaces are initialized.  In that case the registration 
> issue does not seem to occur (after testing several times).
>
> If I put in a 7 second sleep in the MM init script right before MM is 
> lauched, I do not see the 20 second timeout. In this case I instead get the 
> longer registration where the "Simple connect state (5/8): Register" step 
> reports "Launching automatic network registration..." and takes 60 seconds to 
> register with the network before moving on to the next simple connect state.  
> The interesting thing is that the ttyACM0 interface takes 60 seconds to 
> receive the +CEREG and other messages, but the ttyACM1 interface is receiving 
> those message

RE: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-09 Thread Matthew Starr 
> -Original Message-
> From: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> Sent: Friday, April 06, 2018 3:37 AM
> To: Matthew Starr
> Cc: Dan Williams; modemmanager-devel@lists.freedesktop.org
> Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on Simple
> Connect
> 
> Hey!
> 
> > I looked a little more into what was going on and found that this TOBY-R200
> modem takes much longer than other u-blox modems I have used to
> initialize the virtual USB serial ports on startup.  It appears with the USB 
> serial
> ports appear after ModemManager has already started, the longer
> registration occurs.  When I put a delay before ModemManager is started
> until after the USB serial ports appear, then I always get the fast 
> registration.
> This is without the "mmcli -m 0 -e" command being run at all.
> >
> 
> So you mean that if MM tries to poke the ports *while* the TOBY is still
> booting, it makes it timeout in the registration?
> I have seen myself that in a different u-blox device the TTYs are
> *not* ready as soon as they're exposed by the kernel, it may take up to 10s-
> 15s since they are exposed to be ready for AT commands (although it usually
> is something like 5s-8s). But I haven't seen a case where poking the TTYs
> early would end up triggering registration failures or delays.

I blacklisted all the ports except the primary AT port (ttyACM0) following the 
example file you gave below.  That helped speed up things a little bit since MM 
isn't waiting on a timeout from a non-AT interface.  Unfortunately I am seeing 
exactly what you said where the ttyACM0 interface comes up, immediately it 
probed by MM, and then eventually MM times out after 20 seconds.  After the 
timeout MM continues with probing the device successfully.  It looks like MM is 
waiting for a READY message that never comes and eventually times out after 20 
seconds.  The interesting thing is that the modem appears to send the message 
'+PACSP0' within the first second of the 20 second timeout 
period, but MM seems to do nothing with it.  I also tried this with all other 
valid AT interfaces (ttyACM1 and ttyACM2) not blacklisted at the same time, and 
they also encountered the same 20 second timeout with the same '+PACSP0' 
message.  See the following for the case with just ttyACM0 not blacklisted:

Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408139] [plugin manager] task 4,ttyACM0: found '7' plugins to try
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408278] [plugin manager] task 4,ttyACM0: will try with plugin 
'u-blox'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408414] [plugin manager] task 4,ttyACM0: will try with plugin 
'Telit'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408538] [plugin manager] task 4,ttyACM0: will try with plugin 'Via 
CBP7'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408662] [plugin manager] task 4,ttyACM0: will try with plugin 
'Iridium'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408789] [plugin manager] task 4,ttyACM0: will try with plugin 
'Nokia'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.408907] [plugin manager] task 4,ttyACM0: will try with plugin 
'Cinterion'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.409032] [plugin manager] task 4,ttyACM0: will try with plugin 
'Generic'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.409184] [plugin manager) task 4,ttyACM0: started
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.409322] [plugin manager] task 4,ttyACM0: checking with plugin 
'u-blox'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.409547] (u-blox) [ttyACM0] probe required: 'at'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.409740] (tty/ttyACM0) launching port probing: 'at'
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.411520] [plugin manager] task 4,ttyACM0: got suggested plugin 
(u-blox)
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.414868] [plugin Manager] task 4: still 1 running probes (1 active): 
ttyACM0
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.428515] (ttyACM0) opening serial port...
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.430200] (ttyACM0): setting up baudrate: 57600
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.431460] (ttyACM0) device open count is 1 (open)
Apr  9 15:10:40 canect2 daemon.debug ModemManager[252]:  
[1523286640.432402] (ttyACM0): port attributes not fully set
Apr  9 15:10:40 canect2 d

Re: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-06 Thread Aleksander Morgado 
Hey!

> I added the "mmcli -m 0 -e" right after starting ModemManager, but in this 
> case I got the message:
> error: couldn't find the ModemManager process in the bus
>

Like directly after starting MM? MM needs time to boot and expose
interfaces in DBus, you shouldn't be trying to enable a modem
immediately after MM is started.

Actually, there should not be any issue with starting MM right when
the system starts, and you can start both NM and MM in parallel if
needed. Then, only once the modem is probed and exposed in DBus, NM
would start the autoconnection process. There shouldn't be any need
for any other logic to be added, it's a bit surprising that you get
these errors I think.

> Then I added a "sleep 1" before the "mmcli -m 0 -e", but still got an error 
> message:
> error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0'
>

Well, MM needs time to probe the modem. You can monitor the
availability of the modem with "mmcli -L" or "mmcli -M", or using your
own custom program to do so via libmm-glib (e.g. even in Python). See
the modem watcher example:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem-watcher-python

ModemManager will only expose the modem in DBus (i.e. expose it to NM
and other clients) once the modem is ready and fully probed, and that
may take a while.

> I looked a little more into what was going on and found that this TOBY-R200 
> modem takes much longer than other u-blox modems I have used to initialize 
> the virtual USB serial ports on startup.  It appears with the USB serial 
> ports appear after ModemManager has already started, the longer registration 
> occurs.  When I put a delay before ModemManager is started until after the 
> USB serial ports appear, then I always get the fast registration.  This is 
> without the "mmcli -m 0 -e" command being run at all.
>

So you mean that if MM tries to poke the ports *while* the TOBY is
still booting, it makes it timeout in the registration?
I have seen myself that in a different u-blox device the TTYs are
*not* ready as soon as they're exposed by the kernel, it may take up
to 10s-15s since they are exposed to be ready for AT commands
(although it usually is something like 5s-8s). But I haven't seen a
case where poking the TTYs early would end up triggering registration
failures or delays.

> I am not sure what in ModemManager is causing the registration issue based on 
> this ordering of which appears/starts first.
>

I've asked u-blox about this and hopefully they'll have an idea of
what's happening here.

>
> Additionally it seems to take a really long time during a fast registration 
> for ModemManager to actually startup, probe the modem, and attempt to 
> connect.  It looks like the time between when ModemManager starts and when a 
> simple connect can start because enough probing of the modem was finished is 
> 34 seconds.  Much of this is waiting for 20 seconds for the /dev/ttyACM3, 
> /dev/ttyACM4, and /dev/ttyACM5 interfaces to timeout to probing and then 
> another 5 seconds as the same interfaces have AT commands sent to it and 
> timed out again.  These are not AT command interfaces so it would be nice if 
> this could be optimized for this modem.  I am not sure if this can be done or 
> how to do it with ModemManager.
>

That is easily solvable if the modem has predefined interfaces for
different purposes, which is very probable in this case. See e.g. the
TOBY-L4 port type rules defined here:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/ublox/77-mm-ublox-port-types.rules

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

RE: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-05 Thread Matthew Starr 
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Thursday, April 05, 2018 3:50 PM
> To: Matthew Starr; modemmanager-devel@lists.freedesktop.org
> Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on Simple
> Connect
> 
> On Thu, 2018-04-05 at 18:32 +, Matthew Starr wrote:
> > > -Original Message-
> > > From: Dan Williams [mailto:d...@redhat.com]
> > > Sent: Thursday, April 05, 2018 1:22 PM
> > > To: Matthew Starr; modemmanager-devel@lists.freedesktop.org
> > > Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on
> > > Simple Connect
> > >
> > > On Tue, 2018-04-03 at 21:19 +, Matthew Starr wrote:
> > > > I have a u-blox TOBY-R200 running on an embedded Linux device with
> > > > the ModemManager 1.8-rc2 build, plus the patch for "ublox: fix
> > > > 'any'
> > > > mode building".  On this device there seems to be an issue between
> > > > the automatic registration of the TOBY-R200 modem and
> ModemManager
> > > > reaching the Simple Connect State (5/8) Register.
> > > >
> > > > Between reboots I can get ModemManager to have a quick
> > > > registration and then have a slow (40 or more seconds)
> > > > registration, where ModemManager seems to have caught the modem
> > > > right before it finished auto registration or for some reason a
> > > > denied state occurs and restarts the entire registration over.
> > > > The issue seems to happen right before simple connect state (5/8)
> > > > Register is run.
> > > >
> > > > Here is what is reported during a quick registration step:
> > > > Simple connect state (5/8): Register Already registered in network
> > > > 'XX', automatic registration not launched...
> > > >
> > > > Here is what is reported during a slow registration step:
> > > > Simple connect state (5/8): Register Launching automatic network
> > > > registration...
> > > >
> > > > See attached files for logs of the fast and slow registration from
> > > > the start of a simple connect to step (6/8) Bearer
> > >
> > > In the quick case, the modem is already registered long before
> > > SimpleConnect gets to it's registration check.
> > >
> > > In the slow case, the modem isn't yet registered.  It first reports
> > > GPRS=denied, UMTS=denied, LTE=idle.  MM then starts automatic
> > > registration on ACM0 and two seconds later gets GPRS=registered on
> > > ACM1.
> > > But ACM0 is still blocked running the AT+COPS=0 registration command
> > > which doesn't complete until 30 seconds later.  Only then can MM
> > > continue with the connection attempt, even though the modem was
> > > registered
> > > 28
> > > seconds before.
> > >
> > > So yeah, it's (1) a race with modem firmware between the two cases,
> > > and
> > >  (2) the modem not returning from the AT+COPS=0 automatic
> > > registration request even when it has already registered.  (though
> > > there is perhaps another small race where if the modem has just
> > > registered the instant before MM sends AT+COPS=0 and hasn't yet
> > > notified MM, it will then do a full network scan and registration
> > > cycle when the +COPS=0 comes in)
> > >
> > > How long has the modem been +CFUN=1 before you send the
> > > SimpleConnect() request?  Can you test whether waiting a couple
> > > seconds after the modem is fully enabled, before sending
> > > SimpleConnect(), makes a difference?
> > > We could also test-patch MM do that.  This isn't a real fix
> > > though...
> > >
> > > Dan
> > >
> >
> > Dan,
> >
> > I am using SystemV init scripts  for my init this device and I already
> > tested putting in various sleeps right after starting ModemManager
> > before I start NetworkManager which is setup to autoconnect to the
> > cellular connection.  I put in a sleep as long as
> > 30 seconds before NetworkManager is started and the rest of the boot
> > continues and it made no difference.  I was still getting random
> > results with sometimes MM seeing auto registration had already
> > completed and other times it forcing a full registration.
> 
> Are you enabling the modem from the scripts, or leaving that to
> NetworkManager?  If you're leaving it to NM, you might try &q

Re: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-05 Thread Dan Williams 
On Thu, 2018-04-05 at 18:32 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, April 05, 2018 1:22 PM
> > To: Matthew Starr; modemmanager-devel@lists.freedesktop.org
> > Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on
> > Simple
> > Connect
> > 
> > On Tue, 2018-04-03 at 21:19 +, Matthew Starr wrote:
> > > I have a u-blox TOBY-R200 running on an embedded Linux device
> > > with the
> > > ModemManager 1.8-rc2 build, plus the patch for "ublox: fix 'any'
> > > mode building".  On this device there seems to be an issue
> > > between the
> > > automatic registration of the TOBY-R200 modem and ModemManager
> > > reaching the Simple Connect State (5/8) Register.
> > > 
> > > Between reboots I can get ModemManager to have a quick
> > > registration
> > > and then have a slow (40 or more seconds) registration, where
> > > ModemManager seems to have caught the modem right before it
> > > finished
> > > auto registration or for some reason a denied state occurs and
> > > restarts the entire registration over.  The issue seems to happen
> > > right before simple connect state (5/8) Register is run.
> > > 
> > > Here is what is reported during a quick registration step:
> > > Simple connect state (5/8): Register
> > > Already registered in network 'XX', automatic registration
> > > not
> > > launched...
> > > 
> > > Here is what is reported during a slow registration step:
> > > Simple connect state (5/8): Register
> > > Launching automatic network registration...
> > > 
> > > See attached files for logs of the fast and slow registration
> > > from the
> > > start of a simple connect to step (6/8) Bearer
> > 
> > In the quick case, the modem is already registered long before
> > SimpleConnect gets to it's registration check.
> > 
> > In the slow case, the modem isn't yet registered.  It first reports
> > GPRS=denied, UMTS=denied, LTE=idle.  MM then starts automatic
> > registration on ACM0 and two seconds later gets GPRS=registered on
> > ACM1.
> > But ACM0 is still blocked running the AT+COPS=0 registration
> > command
> > which doesn't complete until 30 seconds later.  Only then can MM
> > continue
> > with the connection attempt, even though the modem was registered
> > 28
> > seconds before.
> > 
> > So yeah, it's (1) a race with modem firmware between the two cases,
> > and
> >  (2) the modem not returning from the AT+COPS=0 automatic
> > registration
> > request even when it has already registered.  (though there is
> > perhaps
> > another small race where if the modem has just registered the
> > instant
> > before MM sends AT+COPS=0 and hasn't yet notified MM, it will then
> > do a
> > full network scan and registration cycle when the +COPS=0 comes in)
> > 
> > How long has the modem been +CFUN=1 before you send the
> > SimpleConnect() request?  Can you test whether waiting a couple
> > seconds
> > after the modem is fully enabled, before sending SimpleConnect(),
> > makes a
> > difference?
> > We could also test-patch MM do that.  This isn't a real fix
> > though...
> > 
> > Dan
> > 
> 
> Dan,
> 
> I am using SystemV init scripts  for my init this device and I
> already tested putting in various sleeps right after starting
> ModemManager before I start NetworkManager which is setup to
> autoconnect to the cellular connection.  I put in a sleep as long as
> 30 seconds before NetworkManager is started and the rest of the boot
> continues and it made no difference.  I was still getting random
> results with sometimes MM seeing auto registration had already
> completed and other times it forcing a full registration.

Are you enabling the modem from the scripts, or leaving that to
NetworkManager?  If you're leaving it to NM, you might try "mmcli -m 0
-e" before doing the sleep.

Dan

> Matt
> 
> > > Any idea on what the difference is between the fast and slow
> > > registration and what might be causing it?  Any ideas how to fix
> > > it?
> > > 
> > > Best regards,
> > > Matthew Starr
> > > 
> > > 
> > > ___
> > > 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: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-05 Thread Matthew Starr 
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Thursday, April 05, 2018 1:22 PM
> To: Matthew Starr; modemmanager-devel@lists.freedesktop.org
> Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on Simple
> Connect
> 
> On Tue, 2018-04-03 at 21:19 +, Matthew Starr wrote:
> > I have a u-blox TOBY-R200 running on an embedded Linux device with the
> > ModemManager 1.8-rc2 build, plus the patch for "ublox: fix 'any'
> > mode building".  On this device there seems to be an issue between the
> > automatic registration of the TOBY-R200 modem and ModemManager
> > reaching the Simple Connect State (5/8) Register.
> >
> > Between reboots I can get ModemManager to have a quick registration
> > and then have a slow (40 or more seconds) registration, where
> > ModemManager seems to have caught the modem right before it finished
> > auto registration or for some reason a denied state occurs and
> > restarts the entire registration over.  The issue seems to happen
> > right before simple connect state (5/8) Register is run.
> >
> > Here is what is reported during a quick registration step:
> > Simple connect state (5/8): Register
> > Already registered in network 'XX', automatic registration not
> > launched...
> >
> > Here is what is reported during a slow registration step:
> > Simple connect state (5/8): Register
> > Launching automatic network registration...
> >
> > See attached files for logs of the fast and slow registration from the
> > start of a simple connect to step (6/8) Bearer
> 
> In the quick case, the modem is already registered long before
> SimpleConnect gets to it's registration check.
> 
> In the slow case, the modem isn't yet registered.  It first reports
> GPRS=denied, UMTS=denied, LTE=idle.  MM then starts automatic
> registration on ACM0 and two seconds later gets GPRS=registered on ACM1.
> But ACM0 is still blocked running the AT+COPS=0 registration command
> which doesn't complete until 30 seconds later.  Only then can MM continue
> with the connection attempt, even though the modem was registered 28
> seconds before.
> 
> So yeah, it's (1) a race with modem firmware between the two cases, and
>  (2) the modem not returning from the AT+COPS=0 automatic registration
> request even when it has already registered.  (though there is perhaps
> another small race where if the modem has just registered the instant
> before MM sends AT+COPS=0 and hasn't yet notified MM, it will then do a
> full network scan and registration cycle when the +COPS=0 comes in)
> 
> How long has the modem been +CFUN=1 before you send the
> SimpleConnect() request?  Can you test whether waiting a couple seconds
> after the modem is fully enabled, before sending SimpleConnect(), makes a
> difference?
> We could also test-patch MM do that.  This isn't a real fix though...
> 
> Dan
> 

Dan,

I am using SystemV init scripts  for my init this device and I already tested 
putting in various sleeps right after starting ModemManager before I start 
NetworkManager which is setup to autoconnect to the cellular connection.  I put 
in a sleep as long as 30 seconds before NetworkManager is started and the rest 
of the boot continues and it made no difference.  I was still getting random 
results with sometimes MM seeing auto registration had already completed and 
other times it forcing a full registration.

Matt

> > Any idea on what the difference is between the fast and slow
> > registration and what might be causing it?  Any ideas how to fix it?
> >
> > Best regards,
> > Matthew Starr
> >
> >
> > ___
> > 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: u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

2018-04-05 Thread Dan Williams 
On Tue, 2018-04-03 at 21:19 +, Matthew Starr wrote:
> I have a u-blox TOBY-R200 running on an embedded Linux device with
> the ModemManager 1.8-rc2 build, plus the patch for "ublox: fix 'any'
> mode building".  On this device there seems to be an issue between
> the automatic registration of the TOBY-R200 modem and ModemManager
> reaching the Simple Connect State (5/8) Register.
> 
> Between reboots I can get ModemManager to have a quick registration
> and then have a slow (40 or more seconds) registration, where
> ModemManager seems to have caught the modem right before it finished
> auto registration or for some reason a denied state occurs and
> restarts the entire registration over.  The issue seems to happen
> right before simple connect state (5/8) Register is run.
> 
> Here is what is reported during a quick registration step:
> Simple connect state (5/8): Register
> Already registered in network 'XX', automatic registration not
> launched...
> 
> Here is what is reported during a slow registration step:
> Simple connect state (5/8): Register
> Launching automatic network registration...
> 
> See attached files for logs of the fast and slow registration from
> the start of a simple connect to step (6/8) Bearer

In the quick case, the modem is already registered long before
SimpleConnect gets to it's registration check.

In the slow case, the modem isn't yet registered.  It first reports
GPRS=denied, UMTS=denied, LTE=idle.  MM then starts automatic
registration on ACM0 and two seconds later gets GPRS=registered on
ACM1.  But ACM0 is still blocked running the AT+COPS=0 registration
command which doesn't complete until 30 seconds later.  Only then can
MM continue with the connection attempt, even though the modem was
registered 28 seconds before.

So yeah, it's (1) a race with modem firmware between the two cases, and
 (2) the modem not returning from the AT+COPS=0 automatic registration
request even when it has already registered.  (though there is perhaps
another small race where if the modem has just registered the instant
before MM sends AT+COPS=0 and hasn't yet notified MM, it will then do a
full network scan and registration cycle when the +COPS=0 comes in)

How long has the modem been +CFUN=1 before you send the SimpleConnect()
request?  Can you test whether waiting a couple seconds after the modem
is fully enabled, before sending SimpleConnect(), makes a difference? 
We could also test-patch MM do that.  This isn't a real fix though...

Dan

> Any idea on what the difference is between the fast and slow
> registration and what might be causing it?  Any ideas how to fix it?
> 
> Best regards,
> Matthew Starr
> 
> 
> ___
> 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