Hi Aleksander,
On 8/31/21 11:08 AM, Aleksander Morgado wrote:
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?
This turned out to be a modem/port problem triggered by an incorrect network
attachment
(because of using the wrong APN and/or wrong IP type).
Thanks for your (prompt) answers .. and sorry for the noise.
Regards,
Norbert
