Modem disconnect - serial breaks etc.

[Tim Small]

On 24/07/17 18:24, Dan Williams wrote:
> On Mon, 2017-07-24 at 18:09 +0100, Tim Small wrote:
>> I'm seeing an issue where the ppp connection exits, but the modem
>> seems
>> to be left in connected state (I can verify that by sending mm
>> SIGSTOP,
>> then opening a serial terminal window - I'm able to then manually
>> hangup
>> the modem using the +++ escape sequence).
> 
> Interesting.
> 
>> Although it doesn't say so explicitly, I think "Flashing data port"
>> is
>> intended to reset the modem.
> 
> Yes, that's the intent.  Kernel serial drivers are supposed to
> interpret the baud rate of 0 and then drop DTR+RTS, which if the modem
> is configured correctly should then break out of data mode and
> disconnect the call.

Ah, OK I had misinterpreted "Flashing data port" as intending to send a
serial break (which is holding the data line to be logical 0 for a while
instead of the normal idle condition of logical 1).  If it's intended to
drop DTR and RTS, then it's quite possibly doing that, and
tcsendbreak() probably isn't what's actually wanted.

However the Telit driver doesn't appear to put the modem into a mode
whereby dropping DTR will break out of data mode and disconnect. AT&D2
probably is what's needed?

"2 - when the MODULE is connected , the High to Low transition of DTR
pin sets the device in command mode and the current connection is closed"


Unfortunately that's not going to help me much with this hardware, since
the DTR line isn't physically connected on this modem.

I can effectively use DTR signalling within CMUX mode, but I'm seeing
what I think is a firmware bug there currently which I'm still
investigating.

> Any chance you can put a log message in src/mm-port-
> serial.c::flash_do(), something like:
> 
>     GError *error = NULL;
> 
> +   mm_log("Done flashing");
> 
>    /* Recover context */
>     g_assert (self->priv->flash_ctx != NULL);
> 
> just so we can figure out how long the flash is actually taking, and
> whether the message a short time later is due to the port re-open, or
> some other part of the code.

Looks like ATE0<CR> is attempting to be sent whilst the baud rate is set
to 0.  Not sure what effect that'll have on the actual serial port.
I'll try and pick it up with the Bus Pirate:

<debug> [000100.352842] Flashing data port (ttyUSB0)...
<debug> [000100.352985] (ttyUSB0): port attributes not fully set
<debug> [000100.353004] (ttyUSB0): --> 'ATE0<CR>'
<debug> [000101.353760] Done flashing

On this serial port at least it seems that the ATE0<CR> does get sent
(I'm seeing the bytes rxed on the serial port tap), but I'm not able to
check the timing of that easily so I can't verify whether this actually
ends up on the wire at 100 seconds in the above example or 101 seconds.

I could probably lengthen the 0 baud time to verify if you like?

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