Re: Differences between GSM modems

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

> On 27 March 2017 at 17:02 Dan Williams <dcbw redhat com> wrote:
>
> 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
> > > > > om
> > > > > 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/arc
> > > > hive
> > > > 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?
>
> 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...

The way Cinterion/Gemalto seem - who knows....!  But hey, I'm working thru them - with you guys' help ;)

> > I guess the "model" string would identify it?
>
> Is it serially connected? Or USB?

They're PCB-mounted modules, so is (and would be) typically serial. They do do an 'Eval Board' with USB 
connection, but I'd be surprised if anyone took that route except for development/evaluation.