[PATCH] broadband-bearer: run init sequence after flashing in disconnection

[Aleksander Morgado]

On Thu, Jul 27, 2017 at 11:15 AM, Tim Small <tim at seoss.co.uk> wrote:
> On 26/07/17 18:02, Aleksander Morgado wrote:
>
>>> ENV{ID_MM_TTY_DTR_BROKEN}="1"
>>>
>>> ENV{ID_MM_TTY_RTSCTS_BROKEN}="1"
>>>
>>> is the right thing to do?
>>>
>>
>> I'm assuming you're thinking in users providing these udev tags for
>> custom setups, right?
>
> Yep.
>

If these are useful enough, we could add them. Although from my point
of view, if the only drawback of not specifying these is that we e.g.
run additional steps trying to disconnect and it takes a bit longer,
maybe it isn't much of an improvement?

>> Out of curiosity; are you testing the connection/disconnection of the
>> TTYs in MM with a running pppd when it gets connected? Or just doing
>> --simple-connect and then --simple-disconnect for example via mmcli?
>> When pppd is in place, most of the modems get disconnected right away
>> when the daemon exits, and our disconnection logic afterwards doesn't
>> really do much (is pppd maybe doing DTR on->off itself on
>> disconnection?). That's what I recall anyway, it really is a long time
>> ago since I played with PPP based modems.
>
> I'm doing a pppd connection.  The modem isn't hanging up when pppd
> exits, but I've not looked at why (or whether pppd is trying DTR, but
> then the telit modem is configured to ignore this by default so that
> wouldn't help even on modems which do have the DTR line connected and
> available).
>

BTW, which Telit modem is this again? I recently worked with a Telit
LE866 modem, with a single TTY for control and data, and didn't see
any issue during disconnections.

>>
>> The generic broadband bearer, the one that is used to setup PPP over
>> TTY, should really be an object that implements as many procedures as
>> possible to successfully disconnect a call; whether plugins then end
>> up disabling some of those steps is something that can be done later
>> on. So if we add additional disconnect methods, I'm personally fine,
>> assuming they don't interfere with other modems that use other methods
>> successfully.
>
> How about as the default behaviour:
>
> 1. Try DTR drop.
>
> 2. Confirm by sending "AT<CR>" (or maybe "ATH<CR>" to check that the
> data connection has been ended if this is sufficiently standard?), if we
> get "OK" as a response then stop because the modem is disconnected,
> otherwise...
>
> 3. Try sending the escape sequence followed by "ATH<CR>".  If we get
> "OK", as a response then stop because the modem is disconnected,
> otherwise...
>
> 4. Try sending a serial break followed by "ATH<CR>".  If we get "OK", as
> a response then stop because the modem is disconnected, otherwise mark
> the port as bad and log?
>
> If that looks OK then any hints on how to implement that?
>

Could we try to add these new steps *in addition* to the ones we
already have during disconnection? Maybe we could do some AT checks
also in between the steps that we currently do (mm-broadband-bearer.c
disconnect_3gpp() and disconnect_cdma()).

Regarding using ATH or not; we currently use +CGACT=0 to disable the
PDP context that was connected during the connection instead. We send
that through the primary or secondary TTY port, if we have multiple
ports (that is most of the times enough to disconnect correctly when
we have multiple TTYs). If we only have a single TTY, we go through
the steps of fully closing the TTY for 1s and reopening it again
(maybe that's even dropping DTR by the kernel already), and then
serial port "flashing" (baudrate set to 0 for 1s).

-- 
Aleksander
https://aleksander.es