grab_port fails for AT/PPP port (stuck) in data mode

[Aleksander Morgado]

Hey Norbert,

> >> I'm creating a plugin for Sierra Wireless HL78xx LTE-M modem.
> >> Actually, it is already partly done.
> >>
> >> The HL78xx has its own TCP/TLS stack/interface. To use it as
> >> "generic linux network interface" though, PPP is used for the AT/PPP capable
> >> ttyACM1 port. ttyACM0 is the AT control port.
> >>
> >> Note: I'm talking about usb (cdc_acm) 'virtual' tty ports. The serial UART
> >>         port (UART1) can be used for PPP as well, but that is another use-case.
> >>
> >> The problem I currently have is that the plugin fails to grab
> >> the ttyACM1 port if this port is in data mode. It enters data mode
> >> after the ATD "dial-in" command ("ATD*99***<cid>#1").
> >>
> >> The same problem occurs when the ATD "dial-in" command itself, it times
> >> out when the ttyACM1 port is in data mode.
> >>
> >> Afaict, there are 2 possible solutions.
> >> -1- implement some proper switching between data and command mode
> >> -2- MM uses ttyACM0 only
> >>
> >> I wonder whether -1- is a good option since I don't see any code dealing with
> >> data<->command mode switching. Do you think this is needed in my case?
> >> if yes, How do I issue "+++" to enter AT command mode in (any custom) grab_port?
> >>
> >> about -2-, the ATD "dial-in" command probably isn't necessary (since MM
> >> already register with COPS and create/activates the PDP-context/bearer with
> >> CGDCONT/CGACT). Do you think this is a good option?
> >> We do use NetworkManager to start pppd with the right port (ttyACM1), will this still work?
> >>
> >
> > I think the question here would be why ttyACM1 is in data mode. MM
> > expects all ports in control mode, and then decides which one to
> > switch into data mode with an ATD call. MM does not expect the ports
> > to be already in data mode.
> >
>
>
> I'd expect MM to handle any case.
>

MM probes port for capabilities on boot. A port that is supposed to be
AT capable but isn't really, is ignored.

> What if the user disconnects and then reconnects?

If the user disconnects, NetworkManager would stop pppd. We then run
several different procedures in MM to attempt to bring the port back
to control mode, including flashing the port (baudrate set to 0 for
some time), or running CGACT on the secondary port and such.

> Currently this doesn't work because once ttyACM1 is in data mode the
> disconnect (CGACT=0/etc... on ttyACM0) doesn't make it switch to control mode
> and so the ATD call times out.
>
> So it looks like I need to go for option -2- or am I missing something?

You need a way to reliably run the user disconnect. Does the port
always get stuck in data mode when you manually run a user disconnect
via NetworkManager?

-- 
Aleksander
https://aleksander.es