Thanks Aleksander. Suppressing the failed signal quality message would be 'nicer'. It would also be helpful (on my system, at least!) to have an api to disable these periodic checks - as I said, my 'device' is actually a 3-channel mux driver, and I plan to use one tty for ppp and one or two of the others for SMS/status etc. So really, I only need signal quality to be fetched from one of them.
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? -----Original Message----- From: ModemManager-devel [mailto:modemmanager-devel-boun...@lists.freedesktop.org] On Behalf Of Aleksander Morgado Sent: 25 January 2017 19:40 To: colin.helliw...@ln-systems.com Cc: ModemManager (development) <modemmanager-devel@lists.freedesktop.org> Subject: Re: Fetching signal quality during data connection? On Wed, Jan 25, 2017 at 5:22 PM, <colin.helliw...@ln-systems.com> wrote: > I have MM essentially running on my hardware, but I’m puzzled by a > part of its behaviour: > > I can enable the modem with mmcli --enable, and in the debug output I > see the signal quality being periodically refreshed. I can also, more > or less, make a connection to the APN with –connect, and then bring up ppp. > > However: > > Once the ‘--connect' has been done, MM can no longer get the signal > quality – “signal_quality_check_ready(): Couldn't refresh signal > quality: 'No AT port available to run command'” > Yes, we don't support to run AT commands on a port flagged as 'connected'. We should just silence that warning if there's a single TTY and the TTY is connected. E.g. reloading signal quality would still work if we have some other control channel to use while being connected. > A more serious problem is that if MM tries to fetch the signal quality > after ‘--connect', but before ppp is started, then the ppp negotiation > subsequently fails (“LCP: timeout sending Config-Requests”). I *can* get > ppp connected as long as I start it before MM next tries to get signal > quality. > > > > In case it’s relevant, the modem is a Cinterion. I’m actually using it > via their ‘linmux’ multiplexor – just on a single virtual port though. > > > > I’m puzzled as to why MM keeps trying to get signal quality after the > data connection – my understanding was that you can’t use [most] AT > commands after this. I may be wrong there, but the info on my modem > says (for > ‘ATD*99#’) – “The V.250 'D' (Dial) command causes the MT to enter the > V.250 online data state and, with the TE, to start the specified layer 2 > protocol. > No further commands may follow on the AT command line” > > > > Can anyone advise? Thanks You say that if the signal quality reload happens before PPP is established, the PPP session fails, that looks like a race condition we can avoid. As soon as we run ATD we should be flagging the port as 'connected'. Looking at the code, it seems that the flagging is done a bit late; we run connect_3gpp() and that async operation runs ATD, but the operation finishes in an idle, which is when we then set the port as connected (looking at mm-broadband-bearer.c:connect_succeeded). This means that there may be a case where an AT command is scheduled to be run before the idle where the flagging is done. So, one thing we should do is to flag the port as connected exactly after ATD is run, being ATD the last command allowed before going into data mode. Opened a new bug to track this issue: https://bugs.freedesktop.org/show_bug.cgi?id=99541 -- Aleksander https://aleksander.es _______________________________________________ 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
