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

[Aleksander Morgado]

>
> Incidentally, a similar thing goes for RTS/CTS, these aren't always
> connected up, but the flow control setup logic currently says "if the
> host supports RTS/CTS and the modem supports RTS/CTS, then turn it on",
> which might not be the right thing to do since they might not actually
> be connected to each other.  Maybe a udev set of rules like:
>
> 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?

>> Or if the modem doesn't, we could send the breaks.  If the modem
>> doesn't actually drop to command mode (&D1) then we could also send
>> breaks.
>
> The whole break thing might be a red herring, since although some modems
> will respond to this, I don't think its widespread any more (a quick
> google shows that it would need to be configured AT\K.
>
> I think probably the debug comment should be changed to "attempting to
> hang up the modem by dropping serial port DTR signal" or similar, since
> "flashing the serial port" is a bit of a strange usage (and I'd guess
> that if people get anything from that description it might be a serial
> break, especially since setting the baud rate to zero is how you do a
> serial break on some platforms).
>
> The two reasonable/reliable ways of ending a call are DTR on->off
> transition (if enabled via AT&D2 - enter command mode and also end
> current data call), and also sending the escape sequence followed by ATH
> "hang up".  I think.
>

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.

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.

-- 
Aleksander
https://aleksander.es