Fetching signal quality during data connection?

Fri Feb 3 13:35:41 UTC 2017

Aside from the questions over disconnect and/or powering off the hardware in my mux driver, I want to step back a bit and dig into what's happening when the modem is timing out of Data Mode but MM is apparently not realising. I want to try to see the NO CARRIER that I see when playing with a terminal app. After all, unless I can't get things to behave right in a failure condition then there's no point in [for a robust solution] fixing the 'good' condition!
I've not yet been able to establish how the modem really behaves, but it may be a complication of the mux driver that I'm using MM on. So I'll try removing that and talking direct to the real serial port. Trouble is..... I can't get the udev rules right to get it 'whitlisted'... 
Can someone walk me through this please?
udev is showing ttymxc2's DEVPATH as    /devices/soc0/soc/2100000.aips-bus/21ec000.serial/tty/ttymxc2
In the rules I have 
KERNEL=="ttymxc2", ENV{SYSTEMD_WANTS}="ModemManager.service" ENV{ID_MM_CANDIDATE}="1"                                                                           
ACTION=="add" KERNEL=="21ec000.serial", ENV{SYSTEMD_WANTS}="ModemManager.service" ENV{ID_MM_CANDIDATE}="1" ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"

I've reloaded the rules, and restart MM, but no joy with it being seen as whitelisted.

-----Original Message-----
From: ModemManager-devel [mailto:modemmanager-devel-bounces at lists.freedesktop.org] On Behalf Of Aleksander Morgado
Sent: 26 January 2017 13:54
To: colin.helliwell at ln-systems.com
Cc: ModemManager (development) <modemmanager-devel at lists.freedesktop.org>
Subject: Re: Fetching signal quality during data connection?

> Regarding the failing PPP:
> Your enhancement probably to prevent a race is still a good idea in general. However I've now experimented manually (with a terminal app), and I don't think it is the Sig Quality which is breaking PPP. What I was actually doing was waiting so long before starting PPP that the *modem* is timing out - after the ATD it sends back 'hex' messages (presumably some sort of LCP request) a number of times, and then eventually times out and sends 'NO CARRIER'. This timeout also happens to be 30secs.
> I haven't found any 'ETSI' spec which defines a timeout from data mode, and nor is one mentioned in my modem's docs. However I did find a uBlox manual which states different negotiation/timeout sequences for their different modems (https://www.u-blox.com/sites/default/files/u-blox-ATCommands_Manual_(UBX-13002752).pdf , para 18.2). So maybe this behaviour is always manufacturer-specific.
> It would though be better if MM caught the 'NO CARRIER' and set the state back to disconnected?

MM should already be catching the NO CARRIER errors; could you gather debug logs while reproducing this to see why it didn't catch it?

--
Aleksander
https://aleksander.es
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel