Fetching signal quality during data connection?

[Aleksander Morgado]

On Wed, Jan 25, 2017 at 5:22 PM,  <colin.helliwell at 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