Re: Differences between GSM modems

On Sat, 2017-03-25 at 13:29 +0000, Colin Helliwell wrote:
On 25 March 2017 at 06:31 Dan Williams <dcbw redhat com> wrote:

On Fri, 2017-03-24 at 13:53 +0000, Colin Helliwell wrote:

On 23 March 2017 at 19:43 Dan Williams <dcbw redhat com> wrote:

On Thu, 2017-03-23 at 18:26 +0000, colin.helliwell@ln-systems.c

NetworkManager[1398]: [1490292215.0368] (ttyMux1): modem
changed, 'connected' --> 'registered' (reason: user-
NetworkManager[1398]: [1490292215.0371] device (ttyMux1):
change: activated -> failed (reason 'modem-no-carrier') [100
NetworkManager[1398]: [1490292215.0390]
active-connection[0x1f38140]: set state deactivated (was
NetworkManager[1398]: [1490292215.0395]

We'll need ModemManager logs here; MM is saying the modem state
changed, possibly due to status changes on the secondary AT
hears that and terminates the connection.

Log including MM below.

But I think I've spotted the cause - the AT+CGACT? is getting a
'deactivated' response (@ 09:28:54). Hence MM seeing it as being

As Aleksander commented before (
s/modemmanager-devel/2017-March/004042.html), it doesn't make
to have different PDP's across multiple TTYs. And indeed their
appears to behave sensibly i.e. indicates the port 1 PDP as
even if queried over [Primary] port 2.

However, on trawling through the BGS2 docs, I've found that that
contexts can be defined on any [mux] channel, but are visible and
usable only on the channel on which they are defined".
And doing some manual tests seems to confirm that - they can
be set up independantly on different ports. Nice 'feature'.... :S
(I'm wondering if that's also behind some of the other weird sh^t
I've been grappling with).

That is... interesting. And unlike anything I've ever encountered
before :) If there's a way to detect that it's a BGS2, then we'll
to special-case that device and stop ModemManager from polling
bearer/connection status. We might also need to somehow suppress
MM disconnect behavior of sending CGACT=x,0 on the secondary port
trying to ensure that PPP terminates and the data port returns to
command mode.

I wondered about altering the MM behaviour for it too - wasn't sure
if it would be sane/possible to mess with with its 'view of the
world' though. (Or, especially, worried about the likelihood of me
doing it badly ;) ). Would it and/or NM lose some of its consequent
abilities by no longer polling the connection status?

If the connection drops, but pppd is unable to figure that out (because
the firmware doesn't send the LCP TermReq or something), then you'll
have to have an external script manually do health checking and kill
the connection when it times out.

MM's connection polling is an attempt to see whether this has happened
through actual modem commands (as opposed to an IP 'ping' or something)
and handle termination.  You don't get that if you're using PPP and
can't reference the PDP context on a secondary port.

In part I'm tempted to drop the BGS2 as a 'bad job' and just use
EHS5. Trouble is that many of our applications don't need the 3G
capability of the latter, and there's quite a significant difference
in BOM cost between the two.

Eh, it doesn't sound *that* bad, we can make it work.  As long as there
aren't too many more oddities...

I guess the "model" string would identify it?

Is it serially connected?  Or USB?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]