Fetching signal quality during data connection?

Dan Williams dcbw at redhat.com
Tue Jan 31 19:02:58 UTC 2017


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.fre
> 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.freedeskto
> 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


More information about the ModemManager-devel mailing list