PPP: error decoding frame during IPCP configuration

[olalonde]

I am trying write a driver for SIMCOM A7672SA modem. It always fails during the PPP setup:

[00:00:37.986,145] <dbg> net_l2_ppp: ppp_fsm_timeout: (0x20004af8): [IPCP/0x20002700] Current state REQUEST_SENT (6)
[00:00:37.986,328] <dbg> net_l2_ppp: fsm_send_configure_req: (0x20004af8): [IPCP/0x20002700] Sending Configure-Req (1) id 1 to peer while in REQUEST_SENT (6)
[00:00:37.986,358] <dbg> net_l2_ppp: ppp_send_pkt: (0x20004af8): [IPCP/0x20002700] Sending 24 bytes pkt 0x2002246c (options len 18)
[00:00:37.986,419] <dbg> net_l2_ppp: net_pkt_hexdump: send L2
[00:00:37.986,511] <dbg> net_l2_ppp: net_pkt_hexdump: 0x2002246c
                                     80 21 01 01 00 16                                |.!....           
[00:00:37.986,541] <dbg> net_l2_ppp: net_pkt_hexdump: 0x2002246c
                                     03 06 00 00 00 00 81 06  00 00 00 00 83 06 00 00 |........ ........
                                     00 00                                            |..               
[00:00:37.986,877] <dbg> modem_cmux: modem_cmux_log_frame: tx ch:1 cr:1 pf:0 type:UIH dlen:31
[00:00:37.986,907] <dbg> modem_cmux: modem_cmux_log_frame: data:
                                     7e ff 7d 23 80 21 7d 21  7d 21 7d 20 7d 36 7d 23 |~.}#.!}! }!} }6}#
                                     7d 26 7d 20 7d 20 7d 20  7d 20 81 7d 26 7d 20    |}&} } }  } .}&}  
[00:00:37.986,999] <dbg> modem_cmux: modem_cmux_log_frame: tx ch:1 cr:1 pf:0 type:UIH dlen:20
[00:00:37.986,999] <dbg> modem_cmux: modem_cmux_log_frame: data:
                                     7d 20 7d 20 7d 20 83 7d  26 7d 20 7d 20 7d 20 7d |} } } .} &} } } }
                                     20 6e db 7e                                      | n.~             
[00:00:38.024,108] <dbg> modem_cmux: modem_cmux_log_frame: rcvd ch:1 cr:0 pf:0 type:UIH dlen:12
[00:00:38.024,139] <dbg> modem_cmux: modem_cmux_log_frame: data:
                                     7e ff 03 80 21 01 05 00  04 61 d4 7e             |~...!... .a.~    
[00:00:38.024,230] <dbg> modem_cmux: modem_cmux_log_frame: rcvd ch:1 cr:0 pf:0 type:UIH dlen:30
[00:00:38.024,261] <dbg> modem_cmux: modem_cmux_log_frame: data:
                                     7e ff 03 80 21 03 01 00  16 03 06 64 71 08 ea 81 |~...!... ...dq...
                                     06 c8 58 7f 17 83 06 c4  03 51 05 53 1d 7e       |..X..... .Q.S.~  
[00:00:38.024,322] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x03 because 0x7d was expected.
[00:00:38.024,353] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x80 because 0x7e was expected.
[00:00:38.024,353] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x21 because 0x7e was expected.
[00:00:38.024,383] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x01 because 0x7e was expected.
[00:00:38.024,383] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x05 because 0x7e was expected.
[00:00:38.024,414] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x00 because 0x7e was expected.
[00:00:38.024,414] <dbg> modem_ppp: modem_ppp_is_byte_expected: Dropping byte 0x04 because 0x7e was expected.

The modem is sending the following frame, but the PPP driver fails to parse it, at byte 0x03 where it expects 0x7d instead:

7e ff 03 80 21 01 05 00  04 61 d4 7e

As far as I can tell this seems to be a valid PPP frame, 0x03 identifies the frame as an HDLC UI (Unnumbered Information) frame).

Is this just because the driver wants to ignore the frame? And the issue is somewhere else?

The problem is that the driver afterwards keeps trying to send the Configure-Req but the modem never replies with a frame that starts with 7e ff 7d, always with 7e ff 03.. so this loops keep going on forever.

I had Gemini decode the 2 PPP frames sent by modem and they seem valid: https://g.co/gemini/share/f4cd605dac13

[olalonde]

Continued researching the issue and my best guess is that the modem PPP is probably expecting the "escaped" version of 0x23:

PPP uses byte stuffing to handle control characters within the data. The escape character is 7d. When 7d is encountered, the next byte is XORed with 0x20 to get the original byte.

7d 23: 0x23 XOR 0x20 = 0x03

[olalonde]

If I understand correctly, the modem PPP driver is incorrectly expecting an escaped byte. This is probably related to LCP ACCM settings that were negotiated.

[olalonde]

Oops, there is an identical issue here: #78269