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

Tim Small tim at seoss.co.uk
Wed Jul 26 12:53:44 UTC 2017


On 25/07/17 16:46, Dan Williams wrote:
> There's a couple more things we could do with the disconnect code too.
> 
> As you suggest, we could set AT&D<something> by default and if the
> modem allows that, hope that dropping DTR does the right thing.

A potential problem here is badly implemented hardware where the DTR
line is disconnected and left floating, you might get spurious random
transitions on that line.

An alternative (which should at least be an option I think and will work
even when the DTR line isn't in use) is to use the +++ escape sequence:

1. <wait minimum configured time whilst sending no characters>
2. send "+++"
3. <wait minimum configured time whilst sending no characters>

The modem then re-enters command mode.  Any ongoing data call can then
be ended with:

ATH

or returned to using:

ATO

incidentally, all queued unsolicited status updates will be sent to the
host as soon as the command mode is entered.  The guard interval can be
set with ATS12=xxx - where xxx is the time interval in 50ths of a
second.  The usual escape character is '+', but this can be set/changed
with ATS2=xxx, where the number is an ASCII character.

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?

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

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


More information about the ModemManager-devel mailing list