在Telstra的NEXTG移动networking的下行文件传输期间，我们看到这些数据包被注入FTP-DTP通道。 我们不确定这些是networking级别的数据包，我们的3G调制解调器（基于HC25）还是我们的防火墙注入stream中的问题。
使用工具，我们注意到，PPP成帧失败，协议长度错误，所以他们大多是可能的移动networking数据包。
我希望这里有人可以识别数据包的签名，以便我可以跟适当的供应商追赶。
这些数据包肯定有一个格式：
包1：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00
分组2：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ff ff a3 79 00 00
数据包3：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ff ff e2 5d 00 00
分组4：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ff ff 20 91 00 00
分组5：00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ff ff e 9 88 00 00
它看起来像一系列的TCP ACK到端口1030和1032.重新格式化转储成text2pcap可以处理的格式，例如
0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................ 0010 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 ................ 0020 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ................ 0030 ff ff 58 b9 00 00 ................ 0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................ 0010 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 ................ 0020 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ................ 0030 ff ff a3 79 00 00 ................ 0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................ 0010 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 ................ 0020 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ................ 0030 ff ff e2 5d 00 00 ................ 0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................ 0010 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 ................ 0020 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ................ 0030 ff ff 20 91 00 00 ................ 0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................ 0010 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 ................ 0020 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ................ 0030 ff ff e9 88 00 00 ................ 您可以将hex转储转换为pcap文件。 第一帧在Tshark中是这样的：
Frame 1: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Arrival Time: Dec 1, 2009 08:24:53.000000000 Epoch Time: 1259684693.000000000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 54 bytes (432 bits) Capture Length: 54 bytes (432 bits) [Frame is marked: False] [Protocols in frame: eth:ip:tcp] Ethernet II, Src: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1), Dst: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a) Destination: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a) Address: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1) Address: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 203.122.157.233 (203.122.157.233), Dst: 123.208.113.82 (123.208.113.82) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 272 Identification: 0xf44e (62542) Flags: 0x00 0.. = Reserved bit: Not set .0. = Don't fragment: Not set ..0 = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0x2f13 [validation disabled] [Good: False] [Bad: False] Source: 203.122.157.233 (203.122.157.233) Destination: 123.208.113.82 (123.208.113.82) [Source GeoIP: Australia, Kingston, 04, -27.666700, 153.116699] [Source GeoIP Country: Australia] [Source GeoIP City: Kingston, 04] [Source GeoIP Latitude: -27.666700] [Source GeoIP Longitude: 153.116699] [Destination GeoIP: Australia, Terrigal, 02, -33.450001, 151.449997] [Destination GeoIP Country: Australia] [Destination GeoIP City: Terrigal, 02] [Destination GeoIP Latitude: -33.450001] [Destination GeoIP Longitude: 151.449997] Transmission Control Protocol, Src Port: 31469 (31469), Dst Port: iad1 (1030), Seq: 1, Ack: 1, Len: 0 Source port: 31469 (31469) Destination port: iad1 (1030) [Stream index: 0] Sequence number: 1 (relative sequence number) Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x10 (ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgement: Set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 65535 Checksum: 0x58b9 [validation disabled] [Good Checksum: False] [Bad Checksum: False]
没有一个框架携带有效载荷，因此很难确切地说出发生了什么事情。 由于您提到FTP，这些可能只是数据连接确认。
我的猜测是他们是某种封装的IP数据包。
0x0800 == the Ethernet type for IP 0x45 == IPv4 with 5*4=20 byte header 0x00 == Type of Service 0x00d0 == length 0x4d58 == ID 0x0000 == offset 0x40 == TTL (64) 0x06 == protocol (TCP)
有趣的链接：
顺便说一句，我不假设00：24：c4：b8：7b：1a或00：90：7f：43：0f：a1恰好是您的本地设备的地址，而另一个远程端？
你有没有试图在Wireshark中查看这些数据包？ 它包含了很多解码器的各种协议 – 你确定这个stream量不包括在内？