Re: Differences between GSM modems

[Colin Helliwell <colin helliwell ln-systems com>]

> 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 com
> > > wrote:
> > >
> > > > NetworkManager[1398]: [1490292215.0368] (ttyMux1): modem
> > > > state
> > > > changed, 'connected' --> 'registered' (reason: user-requested)
> > > > NetworkManager[1398]: [1490292215.0371] device (ttyMux1):
> > > > state
> > > > change: activated -> failed (reason 'modem-no-carrier') [100 120
> > > > 25]
> > > > NetworkManager[1398]: [1490292215.0390]
> > > > active-connection[0x1f38140]: set state deactivated (was
> > > > activated)
> > > > 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 port.
> > > NM
> > > 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
> > disconnected.
> >
> > As Aleksander commented before (https://lists.freedesktop.org/archive
> > s/modemmanager-devel/2017-March/004042.html), it doesn't make sense
> > to have different PDP's across multiple TTYs. And indeed their EHS5
> > appears to behave sensibly i.e. indicates the port 1 PDP as active
> > even if queried over [Primary] port 2.
> >
> > However, on trawling through the BGS2 docs, I've found that that "PDP
> > 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 indeed
> > 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 need
> to special-case that device and stop ModemManager from polling
> bearer/connection status. We might also need to somehow suppress the
> MM disconnect behavior of sending CGACT=x,0 on the secondary port while
> 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?
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.

I guess the "model" string would identify it?