使用 PPP 和蜂窝连接调试嵌入式 Linux 设备中的随机通信丢失

使用 PPP 和蜂窝连接调试嵌入式 Linux 设备中的随机通信丢失

我正在设置一个嵌入式 Linux 设备,以便它可以通过蜂窝连接连接到后端服务器。我使用的是 PPP 版本 2.4.2 和 Sequans 细胞芯片。我让设备正常工作并与后端通信。

为了测试其性能,后端将每 5 分钟发送一条消息,设备应该做出响应。在随机时间间隔内,我的设备似乎会失去连接,然后会随机恢复。单元芯片不会失去连接,并且 ppp 不会中断。我的应用程序日志中一切看起来都很好。

为了调试这个问题,我一直在使用 ppp记录 文件名我的 ppp 接口上的选项和 tcpdump。我发现在通信丢失期间,tcpdump 显示没有任何内容进出 ppp 接口。 ppp记录文件显示某物在 ppp 中发生了什么。有人知道这段时间 ppp 中发生了什么吗?下面的代码片段来自文件(我使用 pppdump -h 打开文件名)。当发送出去的内容进入这个奇怪的发送/接收循环时,似乎在开头添加了一个 c0 。在某些情况下,沟通会自行继续。在其他情况下,设备将向后端发送调制解调器 ping,然后这将导致设备从后端接收它错过的所有消息并对所有这些消息做出响应。

该代码片段显示了正常的通信,然后是发送/接收循环,最后是发送的消息。我已将 XX 放在本来是 IP 地址的部分上。

rcvd   7e 21 45 00 00 23 72 91 00 00 7c 11 36 d5 XX XX  ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 5a d2 7d 5d   _.,`..d.z..Z.}]
rcvd   04 00 50 06 66 c0 15 c2 7e                       ..P.f...~
time  8.0s
sent   7e 21 45 00 00 30 b1 0a 40 00 40 11 f4 4e XX XX  ~!E..0..@[email protected].,
       XX XX XX XX XX XX c7 7a 04 64 00 1c d1 3c 7d 5d  `..( _.z.d...<}]
       11 a0 67 2c 11 f5 38 dd 45 34 bb 21 b8 88 bc 9e  ..g,..8.E4.!....
       f5 33 08 b0 a3 7e                                .3...~
time  4.5s
rcvd   7e 21 45 00 00 23 72 92 00 00 7c 11 36 d4 XX XX  ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 59 d1 7d 5d   _.,`..d.z..Y.}]
rcvd   04 00 50 06 67 c1 c2 ac 7e                       ..P.g...~
time  0.1s
sent   7e 21 45 00 00 30 b2 aa 40 00 40 11 f2 ae XX XX ~!E..0..@.@....,
       XX XX XX XX XX XX c7 7a 04 64 00 1c 8f 99 7d 5d  `..( _.z.d....}]
       11 a0 68 c5 60 17 31 07 2d 07 56 ff 14 63 3c bf  ..h.`.1.-.V..c<.
       6b e4 8d cc 58 7e                                k...X~
time  0.2s
rcvd   7e 21 45 00 00 23 72 93 00 00 7c 11 36 d3 XX XX ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 58 d0 7d 5d   _.,`..d.z..X.}]
rcvd   04 00 50 06 68 c2 ed 79 7e                       ..P.h..y~
time  4.3s
sent   7e c0 21 09 59 00 08 83 0d 23 8a 31 3a 7e        ~.!.Y....#.1:~
rcvd   7e ff 03 c0 21 0a 59 00 08 2b b6 cb 61 cd 98 7e  ~...!.Y..+..a..~
time  30.1s
sent   7e c0 21 09 5a 00 08 83 0d 23 8a 5f 92 7e        ~.!.Z....#._.~
rcvd   7e ff 03 c0 21 0a 5a 00 08 2b b6 cb 61 a3 30 7e  ~...!.Z..+..a.0~
time  30.0s
sent   7e c0 21 09 5b 00 08 83 0d 23 8a 8a 0d 7e        ~.!.[....#...~
rcvd   7e ff 03 c0 21 0a 5b 00 08 2b b6 cb 61 76 af 7e  ~...!.[..+..av.~
time  30.0s
sent   7e c0 21 09 5c 00 08 83 0d 23 8a 92 ca 7e        ~.!.\....#...~
rcvd   7e ff 03 c0 21 0a 5c 00 08 2b b6 cb 61 6e 68 7e  ~...!.\..+..anh~
time  30.0s
sent   7e c0 21 09 5d 00 08 83 0d 23 8a 47 55 7e        ~.!.]....#.GU~
rcvd   7e ff 03 c0 21 0a 5d 00 08 2b b6 cb 61 bb f7 7e  ~...!.]..+..a..~
time  30.1s
sent   7e c0 21 09 5e 00 08 83 0d 23 8a 29 fd 7e        ~.!.^....#.).~
rcvd   7e ff 03 c0 21 0a 5e 00 08 2b b6 cb 61 d5 5f 7e  ~...!.^..+..a._~
time  30.0s
sent   7e c0 21 09 5f 00 08 83 0d 23 8a fc 62 7e        ~.!._....#..b~
rcvd   7e ff 03 c0 21 0a 5f 00 08 2b b6 cb 61 00 c0 7e  ~...!._..+..a..~
time  30.0s
sent   7e c0 21 09 60 00 08 83 0d 23 8a 42 ad 7e        ~.!.`....#.B.~
rcvd   7e ff 03 c0 21 0a 60 00 08 2b b6 cb 61 be 0f 7e  ~...!.`..+..a..~
time  30.0s
sent   7e c0 21 09 61 00 08 83 0d 23 8a 97 32 7e        ~.!.a....#..2~
rcvd   7e ff 03 c0 21 0a 61 00 08 2b b6 cb 61 6b 90 7e  ~...!.a..+..ak.~
time  30.1s
sent   7e c0 21 09 62 00 08 83 0d 23 8a f9 9a 7e        ~.!.b....#...~
rcvd   7e ff 03 c0 21 0a 62 00 08 2b b6 cb 61 05 38 7e  ~...!.b..+..a.8~
time  30.0s
sent   7e c0 21 09 63 00 08 83 0d 23 8a 2c 05 7e        ~.!.c....#.,.~
rcvd   7e ff 03 c0 21 0a 63 00 08 2b b6 cb 61 d0 a7 7e  ~...!.c..+..a..~
time  30.0s
sent   7e c0 21 09 64 00 08 83 0d 23 8a 34 c2 7e        ~.!.d....#.4.~
rcvd   7e ff 03 c0 21 0a 64 00 08 2b b6 cb 61 c8 60 7e  ~...!.d..+..a.`~
time  30.1s
sent   7e c0 21 09 65 00 08 83 0d 23 8a e1 5d 7e        ~.!.e....#..]~
rcvd   7e ff 03 c0 21 0a 65 00 08 2b b6 cb 61 1d ff 7e  ~...!.e..+..a..~
time  30.0s
sent   7e c0 21 09 66 00 08 83 0d 23 8a 8f f5 7e        ~.!.f....#...~
rcvd   7e ff 03 c0 21 0a 66 00 08 2b b6 cb 61 73 57 7e  ~...!.f..+..asW~
time  30.0s
sent   7e c0 21 09 67 00 08 83 0d 23 8a 5a 6a 7e        ~.!.g....#.Zj~
rcvd   7e ff 03 c0 21 0a 67 00 08 2b b6 cb 61 a6 c8 7e  ~...!.g..+..a..~
time  30.0s
sent   7e c0 21 09 68 00 08 83 0d 23 8a ae 73 7e        ~.!.h....#..s~
rcvd   7e ff 03 c0 21 0a 68 00 08 2b b6 cb 61 52 d1 7e  ~...!.h..+..aR.~
time  30.1s
sent   7e c0 21 09 69 00 08 83 0d 23 8a 7b ec 7e        ~.!.i....#.{.~
rcvd   7e ff 03 c0 21 0a 69 00 08 2b b6 cb 61 87 4e 7e  ~...!.i..+..a.N~
time  28.8s
sent   7e 21 45 00 00 3b 10 38 40 00 40 11 95 16 XX XX ~!E..;.8@.@....,
       XX XX XX XX XX XX c7 7a 04 64 00 27 ed 37 7d 5d  `..( _.z.d.'.7}]
       1c 00 55 03 fe 01 30 31 35 37 37 30 30 30 31 38  ..U...0157700018
       32 32 33 38 37 f7 8e 68 c0 df 78 5b 53 28 5c 74  22387..h..x[S(\t
       7e                                               ~
sent   21 45 00 00 30 10 39 40 00 40 11 95 20 XX XX XX !E..0.9@.@.. .,`
       XX XX XX XX XX c7 7a 04 64 00 1c b0 64 7d 5d 11  ..( _.z.d...d}].
       a0 69 04 ee 90 77 36 49 41 d0 ce 5f 9b 2f 88 4f  .i...w6IA.._./.O
       d1 35 c1 11 7e                                   .5..~
time  1.2s
sent   7e c0 21 09 6a 00 08 83 0d 23 8a 15 44 7e        ~.!.j....#..D~
rcvd   7e ff 03 c0 21 0a 6a 00 08 2b b6 cb 61 e9 e6 7e  ~...!.j..+..a..~
time  3.8s
sent   7e 21 45 00 00 30 11 f7 40 00 40 11 93 62 XX XX ~!E..0..@[email protected].,
       XX XX XX XX XX XX c7 7a 04 64 00 1c b5 e8 7d 5d  `..( _.z.d....}]
       11 a0 69 f1 79 85 ad e8 d8 66 04 71 7d 5e 29 6d  ..i.y....f.q}^)m
       94 4e d5 d0 05 ef 7e                             .N....~
time  2.9s

答案1

当连接工作时,远程端似乎两者都有地址/控制压缩协议压缩pppdPPP 协议选项处于活动状态(即,选项noaccomp和的等效项nopcomp不是实际上,并且压缩选项已成功协商)。

rcvd   7e               flag = start of PPP frame
        <address & control omitted = Address/Control compression active>
        21              compressed protocol ID 0021 = IPv4
        45              IP version 4, header length 20 octets
        00              IP DSCP & ECN
        00 23           IP total length
        72 91           IP identification (fragment id)
        00 00           IP flags & fragment offset
        7c              IP TTL
        11              IP protocol = UDP
        36 d5           IP header checksum
        XX XX XX XX     IP source address
        XX XX XX XX     IP destination address
        04 64           IP UDP source port 1124
        c7 7a           IP UDP destination port 51066
        00 0f           IP UDP length
        5a d2           IP UDP checksum
        7d 5d 04 00 50 06 66 IP UDP data
        c0              padding
        15 c2           PPP frame checksum
        7e              flag = end of PPP frame

短数据包某物中间似乎是 PPP 链路控制协议 (LCP) Echo-Request 和 Echo-Reply 消息。奇怪的是,远程端似乎在没有重新协商的情况下单方面禁用了地址/控制压缩:

sent    7e              flag = start of PPP frame
        <address & control omitted = Address/Control compression active>
        c0 21           protocol = LCP
        09              LCP Code 09 = Echo-Request
        59              LCP identifier
        00 08           LCP length
        83 0d 23 8a     LCP Echo-Request magic number
        31 3a           PPP frame checksum
        7e              flag = end of PPP frame

rcvd    7e              flag = start of PPP frame
        ff              address = standard broadcast (previously omitted?!)
        03              control = unnumbered data (previously omitted?!)
        c0 21           protocol = LCP
        0a              LCP Code 10 = Echo-Reply
        59              LCP identifier (matches the Echo-Request)
        00 08           LCP length
        2b b6 cb 61     LCP Echo-Reply magic number
        cd 98           PPP frame checksum
        7e              flag = end of PPP frame

我想知道是否实施地址/控制压缩远程端的 PPP 协议选项出现某种错误,导致在某些情况下禁用压缩?

也许在配置中添加该noaccomp选项pppd可以通过避免明显不稳定的情况来提高链路的可靠性地址/控制压缩远端的功能?

参考:

维基百科中的 PPP 数据包结构

RFC 1661,PPP 协议规范的当前版本

IANA 为 PPP 协议分配的号码

相关内容