On Thu, 2017-01-26 at 15:58 +0000, colin.helliw...@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-boun...@lists.fre > edesktop.org] On Behalf Of colin.helliw...@ln-systems.com > Sent: 26 January 2017 15:22 > To: 'Aleksander Morgado' <aleksan...@aleksander.es> > Cc: 'ModemManager (development)' <modemmanager-devel@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
