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

[Tim Small]

On 27/07/17 11:16, Aleksander Morgado wrote:

>>>> ENV{ID_MM_TTY_DTR_BROKEN}="1"
>>>>
>>>> ENV{ID_MM_TTY_RTSCTS_BROKEN}="1"

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

That's true for DTR, but not for RTS/CTS - if RTS/CTS flow control lines
aren't connected between the host and the modem, then the data
connections may just hang on opening (if the RTS input looks deasserted)
and/or hang later because of dropped data (modem deasserts CTS, but the
host doesn't get the message) this isn't easily detectable in software I
believe, so must be indicated and worked around by just using software
flow control instead.

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

This is a GE910-QUAD, the only connection I have available is via a
UART, and the only UART control lines which are wired up are RTS/CTS.
DTR is disconnected at the modem.  The Telit hardware implementers guide
just says "you must connect RX/TX at a minimum", so this is what some
implementations do.

When I'm testing by connecting the modem to a PC (instead of a
Beaglebone - which is what it'll be used for in production) I don't have
RTS/CTS either (although I will have RTS/CTS when I receive the new
USB/UART adaptor which I ordered last week).

Also the stay-in-data-mode problem only seems to happen with some times
of failures, I haven't narrowed down the exact cause yet but pppd gives
up on the connection but the modem keeps it open.  Presumably under
normal call termination pppd sends something in-band which causes the
modem to leave data mode and re-enter command mode as usual...

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

Yes, I think that's reasonable.  I think doing an AT check after the DTR
drop is the best policy since that will detect DTR hand-up not working,
and only try the other methods in this case - it's possible that the
other methods will mess up some other modems which are currently working
fine - so probably best not to employ them unless necessary.


> Regarding using ATH or not; we currently use +CGACT=0 to disable the
> PDP context that was connected during the connection instead.

OK.  I'll look at that and check the Telit docs.

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

That drops DTR (but not RTS).

> and then serial port "flashing" (baudrate set to 0 for 1s).

This will deassert DTR and RTS - from termios(3) - "The zero baud rate,
B0, is used to terminate the connection.  If  B0  is  specified, the
modem control lines shall no longer be asserted".

As far as I know it doesn't do anything else (apart from effectively
disable reception and sending of data - because both the input and
output baud rate is changed in the code - however the only thing that
the modem can be "aware of" during this 1 second is that the DTR and RTS
drop) - so if you're closing and reopenning the tty already, then unless
you have a reason to drop RTS as well as DTR (I don't think this is
needed) then one of these two steps can be removed.

To elaborate, when the baud rate is set to 0, TX will just be left
continuously asserted - this is also the normal condition when no data
is being sent, so the modem has no way to detect this - it looks exactly
the same as no data being sent to it at whatever baud rate its
expecting.  Deasserting the tx line requires using tcsendbreak().

RTS drop on baud rate set to 0, and also DTR drop on close tty were both
verified with an LED and a resistor :-).

No detectable change to TX line when baud rate set to zero verified with
a bus pirate in UART mode, and an LED.

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