Fetching signal quality during data connection?

Wed Feb 1 19:09:42 UTC 2017

On Wed, 2017-02-01 at 07:17 +0000, colin.helliwell at ln-systems.com
wrote:
> Thanks Dan.
> I'm targeting one of two (on-board) modems, so maybe I'll look at
> patching for my case - iirc the modems can act on handshaking signals
> for the termination; I'll have to dig further.
> What's the first-line approach MM takes to terminate (to help me
> navigate the sequence of operations), for the case of a 'good' modem?

The sequence depends on whether it's a 3GPP (GSM/UMTS/LTE or LTE/CDMA)
or 3GPP2 (eg CDMA1x or EVDO-only) device.  In any case, we'll assume
you have a 3GPP one.

MM currently does the following:

1) sends AT+CGACT=0 for the active PDP context to terminate the data
connection.  If the primary port is used for PPP, it attempts to send
the CGACT on a secondary port (if available).

2) "flashes" the data port for 1 second, which means setting the baud
rate to zero (B0), which is supposed to mean "hang up!" and cause the
modem to return to command mode.  In serial kernel drivers, this should
cause the machine to de-assert DTR.  Unfortunately, that seems somewhat
inconsistently done in the drives, and sometimes the drivers change B0
to B9600.

Furthermore, since baud rate and all the serial signals are really just
pointless with USB-based devices, not all drivers and devices actually
allow setting the baud rate at all, so this is prone to failure.

3) closes the serial port, in the hopes that if the baud setting
doesn't work or is ignored by the modem, that closing the port will
cause the modem to hang up because the kernel driver de-asserts
whatever signals are required to cause the modem to drop the data
connection.

4) re-opens the serial port and sends another CGACT on the data/primary
port because some dumb devices stop responding on the primary port when
a CGACT is sent on a secondary port.

So if your device (and its kernel driver!) is well-behaved, the "flash"
procedure should set B0 and de-assert DTR, and that should terminate
the data session and cause the port to re-enter command mode.  MM of
course then closes/reopens the port, which may not be useful for your
device.

So there are two options, perhaps:

1) Change ModemManager to recognized your device (via ATI/GMM/GMR info)
or USB VID/PID to skip the close/reopen step

2) change the MUX driver to wait a short period of time (3 - 5 seconds)
when all ports are closed before it powers the modem down.  Which might
be a good idea anyway?

Dan

> I put the power control into the mux driver because I wasn’t sure how
> many userspace apps might be using the virtual ports - i.e. only the
> mux would therefore know when all ports were unused. (I also felt it
> 'cleaner' to do the gpio control in kernel space rather than faffing
> with sysfs paths in user-space).
> If we end up using MM then that perhaps gives the 'centralization'
> for all the functions (PPP, SMS, Status) and hence would have that
> knowledge of open ports; but I'd also considered other routes such as
> ofono [seems ok on the face of it, but documentation appalling!]. So
> putting in the mux driver kept those parts of code re-usable & non-
> replicated while we settle on what apps to use/write. It's ultimately
> changeable though, depending which ends up being best.
> 
> -----Original Message-----
> From: Dan Williams [mailto:dcbw at redhat.com] 
> Sent: 31 January 2017 19:03
> To: colin.helliwell at ln-systems.com; 'ModemManager (development)' <mod
> emmanager-devel at lists.freedesktop.org>
> Subject: Re: Fetching signal quality during data connection?
> 
> On Thu, 2017-01-26 at 15:58 +0000, colin.helliwell at ln-systems.com
> wrote:
> > Odd though that the signal quality doesn't work again until I '
> > --disconnect'. Testing from a terminal app it seemed to re-respond
> > to 
> > this as soon as the timeout/'NO CARRIER' occurs. It may be that MM
> > is 
> > sending some other config commands that I hadn't done in my simple 
> > experiment?
> > 
> > (Another thing I've noticed: the '--disconnect' appears to close
> > the 
> > tty before re-opening and carrying on. I expected that only a '
> > --disable' would do this. I can detect this because my mux driver, 
> > when no ports are open anymore, powers down the modem. Hence any 
> > volatile config MM thinks it has done might actually have been
> > lost?
> > Not sure whether this might cause other problems later...)
> 
> Disconnect is tough to handle correctly when using the same serial
> port for PPP and AT commands.  Yes there are "standards" on how to do
> it, but it is highly dependent on the specific modem and the serial
> control signals and whether the firmware actually cares about those
> signals.
> 
> So ModemManager tries a few ways to actually disconnect the PPP
> session, including "flashing" the port (setting the serial speed to 0
> baud for a short period of time), closing the port and re-
> initializing, disconnecting the data session on the primary port (if
> there is one) in the hopes that will terminate PPP and return the
> secondary port to command mode, and some other stuff.
> 
> But in the end, we haven't found a way to get some devices to break
> out of PPP mode at all, even long after the PPP LCP negotiation
> should have failed and the device should return NO CARRIER.
> 
> This is all to accommodate bad modems; if there are devices we know
> work well or have a reliable disconnect sequence, we could change MM
> to  do the right thing for those devices.
> 
> Anyway, I'm not quite sure why the MUX driver should control power,
> wouldn't that be the function of the userspace program that's
> controlling the modem, since that program is the thing that knows
> when its using the modem or not?  Trying to be too clever in driver-
> land often runs into expectation mismatches like this, I've found.
> 
> Dan
> 
> > -----Original Message-----
> > From: ModemManager-devel [mailto:modemmanager-devel-bounces at lists.f
> > re
> > edesktop.org] On Behalf Of colin.helliwell at ln-systems.com
> > Sent: 26 January 2017 15:22
> > To: 'Aleksander Morgado' <aleksander at aleksander.es>
> > Cc: 'ModemManager (development)' <modemmanager-devel at lists.freedesk
> > to
> > p.org>
> > Subject: RE: Fetching signal quality during data connection?
> > 
> > Log as follows (--debug --log-level=DEBUG). '--connect' done many 
> > minutes after the '--enable' and '--create-bearer'
> > 
> > 
> > _______________________________________________
> > ModemManager-devel mailing list
> > ModemManager-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
> 
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel