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

[Tim Small]

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.

> 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).

> 
> 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?

Cheers,

Tim.

-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309