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

[Norbert van Bolhuis]

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