PPP 및 셀룰러 연결을 사용하여 임베디드 Linux 장치에서 임의 통신 손실 디버깅

PPP 및 셀룰러 연결을 사용하여 임베디드 Linux 장치에서 임의 통신 손실 디버깅

셀룰러 연결을 통해 백엔드 서버에 연결할 수 있도록 임베디드 Linux 장치를 설정하고 있습니다. 저는 PPP 버전 2.4.2와 Sequans CellChip을 사용하고 있습니다. 장치가 작동하고 백엔드와 통신하도록 했습니다.

성능을 테스트하기 위해 백엔드는 5분마다 메시지를 보내고 장치는 응답해야 합니다. 무작위 간격으로 내 장치의 연결이 끊어졌다가 무작위로 다시 연결되는 것 같습니다. 단위 칩은 연결이 끊어지지 않으며 ppp도 중단되지 않습니다. 내 응용 프로그램 로그에는 모든 것이 괜찮아 보입니다.

이 문제를 디버깅하기 위해 나는 ppp를 사용하고 있습니다.기록 파일 이름내 ppp 인터페이스의 옵션과 tcpdump. 나는 통신이 끊긴 기간 동안 tcpdump가 ppp 인터페이스에 들어가고 나가는 것을 아무것도 보여주지 않는다는 것을 발견했습니다. ppp 레코드 파일 표시무엇ppp에서 무슨 일이 일어났나요? 이 기간 동안 ppp에서 무슨 일이 일어났는지 아는 사람 있나요? 아래 코드 조각은 파일에서 가져온 것입니다(pppdump -h를 사용하여 열었습니다).파일 이름). 전송되는 내용이 이상한 보내기/받기 루프에 들어가면 시작 부분에 c0이 추가되는 것처럼 보입니다. 어떤 경우에는 통신이 저절로 계속됩니다. 다른 경우에는 장치가 백엔드에 모뎀 ping을 보냅니다. 그러면 장치가 백엔드에서 놓친 모든 메시지를 수신하고 모든 메시지에 응답하게 됩니다.

이 코드 조각은 정상적인 통신, 보내기/받기 루프, 마지막으로 전송되는 메시지를 보여줍니다. IP 주소에 XX를 입력했습니다.

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) 에코 요청 및 에코 응답 메시지가 있는 것으로 보입니다. 이상하게도 원격 측에서는 재협상 없이 주소/제어 압축을 일방적으로 비활성화하는 것 같습니다.

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명백히 불안정한 상황을 피함으로써 링크의 신뢰성을 향상시킬 수 있을 것입니다.주소/제어 압축원격 기능?

인용하다:

Wikipedia의 PPP 패킷 구조

RFC 1661, PPP 프로토콜 사양의 최신 버전

IANA가 PPP 프로토콜에 할당한 번호

관련 정보