Re: Differences between GSM modems

[Dan Williams <dcbw redhat com>]

On Mon, 2017-03-27 at 17:14 +0100, Colin Helliwell wrote:
> > 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-syste
> > > > > > ms.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.

Two ways to do it then; could use udev rules and match on anything udev
can match on (VID/PID, device, etc) and tag it, then read that tag in
ModemManager and disable polling.

Or special-case this device in the Cinterion plugin by grabbing
mm_iface_modem_get_model() and strcmp-ing it.  Given this is the only
modem we know of that does this, I'd go for this second option for now.

Dan