Fetching signal quality during data connection?

[colin.helliwell at ln-systems.com]

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?

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)' <modemmanager-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.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