Connect Cinterion modem with SWWAN fails with unknown error

Dan Williams dcbw at redhat.com
Fri Mar 15 14:20:35 UTC 2019


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



More information about the ModemManager-devel mailing list