Connect Cinterion modem with SWWAN fails with unknown error

[matthew stanger]

>
> Anyway, the only thing I can think of is a timing issue with the modem
> firwmare and network registration or initial bearer setup or something
> like that. Perhaps MM isn't querying some ready state well enough, or
> the modem isn't fully set up when we're querying because MM isn't
> asking the right question. NOt sure what else it could be.

Wonderful observation there. Just realized this modem's boot ready URC is
'+PBREADY'. There's nothing in MM to support(minus ublox plugin) this cmd,
which would imply that MM would be sending cmd's before the module is ready.

 I made sure that the modem was freshly booted in both cases.

That'd be the main difference, you waited.

To test this theory out all you need to do is stop MM, plugin/start your
modem give it ~20 sec's to be sure. Then start MM and see if the connection
now works. Let me know if that work and then we can go from there.

On Fri, Mar 15, 2019 at 8:20 AM Dan Williams <dcbw at redhat.com> wrote:

> On Fri, 2019-03-15 at 14:20 +0100, Sven Schwermer wrote:
> > Hi again,
> >
> > I did some more work and now I am able to connect manually (without
> > ModemManager). All that’s required is the AT^SWWAN=1,1 command if the
> > APN is already correctly configured. I checked this via AT+CGDCONT?.
> > Note, that this only works for CID=1. After changing the APN for
> > CID=1, the modem must be forced to re-attach since the modem auto-
> > attaches after power-up. More on this can be found in the chapter
> > “Attaching to LTE Networks” in AT manual. Another interesting fact is
> > that the modem appends a string to the APN after it has attached, in
> > my case “.mnc009.mcc242.gprs”. I’m not sure if this is common.
> >
> > In order to debug the command sequence issued by ModemManager, I
> > extracted all commands sent by the ModemManager from the debug logs
> > incl. their timing. I then replayed them with the same (similar)
> > timing manually from a script, i.e. without ModemManager running. I
> > made sure that the modem was freshly booted in both cases. Curiously,
> > when replaying the commands, the AT^SWWAN commands succeeds. This
> > leaves me a little puzzled.
>
> Great debugging strategy actually :)  This is something I had wanted to
> do for MM testing too, record the commands, responses, and timing to a
> file so we could use them later for unit tests.
>
> Anyway, the only thing I can think of is a timing issue with the modem
> firwmare and network registration or initial bearer setup or something
> like that. Perhaps MM isn't querying some ready state well enough, or
> the modem isn't fully set up when we're querying because MM isn't
> asking the right question. NOt sure what else it could be.
>
> > Does ModemManager issue commands concurrently? I saw in the logs both
> > “device open count is 2 (open)” and “device open count is 3 (open)”.
> > Could that mean that sometimes two AT commands are sent at the same
> > time?
>
> MM serializes commands on the same port using an internal queue to hold
> pending commands, and will not issue the next command until the
> response to the first has either arrived or timed out.
>
> While connected on a serial port with PPP MM will try to send commands
> (signal strength, access tech, etc) on a secondary AT port while the
> main one is occupied with PPP.
>
> Dan
>
> > Best regards,
> > Sven
> > _______________________________________________
> > ModemManager-devel mailing list
> > ModemManager-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20190315/6784adfc/attachment.html>