How to read perfectly a .pcap file

Question

Using tcpdump im trying to sniff some packets. The result is this:

reading from file /tmp/prueba.pcap, link-type LINUX_SLL (Linux cooked v1)
13:35:51.767194 IP6 fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a.47193 > fdc1:41d:9c3:dbef:0:ff:fe00:8c00.47193: UDP, length 63
        0x0000:  6000 0000 0047 1140 fdc1 041d 09c3 dbef  `....G.@........
        0x0010:  a6e9 69f0 59aa b70a fdc1 041d 09c3 dbef  ..i.Y...........
        0x0020:  0000 00ff fe00 8c00 b859 b859 0047 d42e  .........Y.Y.G..
        0x0030:  3f0c 0000 0dc2 50f1 0d7b 2254 696d 6522  ?.....P..{"Time"
        0x0040:  3a5b 3136 3632 3033 3933 3531 2c22 225d  :[1662039351,""]
        0x0050:  2c22 4d6f 6417 0012 320f 00f0 0352 6f6c  ,"Mod...2....Rol
        0x0060:  6c22 3a5b 3533 302c 2264 c2ba 225d 7d    l":[530,"d.."]}

The point is in the line with address 0x0050 we can read "Mod...2". That "Mod" means "Mode" but I don't understand why is not the whole word "Mode". ¿Where is the "e"? I need to read that message perfectly for automate a program reading values from there.

I discarded a puntual problem transmiting the message because every time I sniff a packet that contain that info, the format is exactly the same.

Regards,

*Where is the "e"?* - it's not there. Most likely it is simply be not transmitted by the system in the way you expected. Possible but more unlikely is that something is fiddling with the network traffic and modifying it. In any case it is not the fault of the pcap and very unlikely of the process you've used to sniff the data. So no help possible here. — Steffen Ullrich, Sep 01 '22 at 15:25
What was the full tcpdump command line you used to print that file? — user16139739, Sep 08 '22 at 23:57

score 0 · Answer 1 · answered Sep 04 '22 at 00:20

There are indications that the packet is not correct in other ways than a missing e. For example, the ether type is 0x09c3 and not 0x86dd (IPv6).

Maybe this code to create a PCAP file can help. Using the raw packet you provided as input the output file is bad.pcap and you could use a tool like Wireshark to examine the packet in more detail, see here

import codecs
from scapy.all import wrpcap, Ether, IP, IPv6, UDP, Raw

data = ( 
    '60 00 00 00 00 47 11 40 fd c1 04 1d 09 c3 db ef '
    'a6 e9 69 f0 59 aa b7 0a fd c1 04 1d 09 c3 db ef '
    '00 00 00 ff fe 00 8c 00 b8 59 b8 59 00 47 d4 2e '
    '3f 0c 00 00 0d c2 50 f1 0d 7b 22 54 69 6d 65 22 '
    '3a 5b 31 36 36 32 30 33 39 33 35 31 2c 22 22 5d '
    '2c 22 4d 6f 64 17 00 12 32 0f 00 f0 03 52 6f 6c '
    '6c 22 3a 5b 35 33 30 2c 22 64 c2 ba 22 5d 7d' )

data_list = data.split( " " )
data_s = codecs.decode(''.join(data_list), 'hex')

packet = Raw(load=data_s)
wrpcap('bad.pcap', [packet])

data = (
    '3f 0c 00 00 0d c2 50 f1 0d 7b 22 54 69 6d 65 22 '
    '3a 5b 31 36 36 32 30 33 39 33 35 31 2c 22 22 5d '
    '2c 22 4d 6f 64 17 00 12 32 0f 00 f0 03 52 6f 6c '
    '6c 22 3a 5b 35 33 30 2c 22 64 c2 ba 22 5d 7d' )

data_list = data.split( " " )
data_s = codecs.decode(''.join(data_list), 'hex')

packet = Ether(dst="60:00:00:00:00:47", src="11:40:fd:c1:04:1d") / IPv6(dst="fdc1:41d:9c3:dbef:0:ff:fe00:8c00", src="fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a" ) / UDP(sport=47193, dport=47193, len=0x0047 ) / Raw(load=data_s)
wrpcap('better.pcap', [packet])

score 0 · Answer 2 · answered Sep 11 '22 at 00:23

The hex dump begins with the IPv6 header; the link-layer header is not being dumped, so the Ethertype that would appear in the LINKTYPE_SLL_LINUX link-layer header isn't shown.

So the header is:

6000 0000: version (6), traffic class (0), flow label (0)
0047: payload length (0x47 = 71)
1140: next header (0x11 = 17 = UDP), hop limit (0x40 = 64)
fdc1 041d 09c3 dbef a6e9 69f0 59aa b70a: source IPv6 address (fdc1:41d:9c3:dbef:a6e9:69f0:59aa:b70a)
fdc1 041d 09c3 dbef 0000 00ff fe00 8c00: destination IPv6 address (fdc1:41d:9c3:dbef:0:ff:fe00:8c00)

The next header field is 17, so what follows that is a UDP header:

b859: source port (0x5859 = 47193)
b859: destination port (0x5859 = 47193)
0047: length (0x47 = 71)
d42e: checksum

Those 71 bytes are the UDP header (8 bytes) plus the UDP payload (71 - 8 = 63 bytes).

Port 47193 is a in the "registered" port range; however, it does not appear in the current list of well-known and registered ports.

It does, however, appear, from some web searches, to be the default gateway port for MQTT-SN. MQTT "is a lightweight, publish-subscribe, machine to machine network protocol", and MQTT-SN, according to that page, "is a variation of the main protocol aimed at battery-powered embedded devices on non-TCP/IP networks".

If this is MQTT-SN, then, according to the protocol specification for MQTT-SN, the payload would be:

3f0c: length (0x3f = 63), message type (0c = PUBLISH)
00: flags (0x0000)
000d: TopicId
c250: MsgId
f1 0d7b 2254 696d 6522 3a5b 3136 3632 3033 3933 3531 2c22 225d 2c22 4d6f 6417 0012 320f 00f0 0352 6f6c 6c22 3a5b 3533 302c 2264 c2ba 225d 7d: Data

So that data is:

0xf1 0x0d {"Time":[1662039351,""],"Mod 0x17 0x00 0x12 2 0x0f 0x00 0xf0 0x03 Roll":[530,"d 0xc2 0xba "]}

If the published data is intended to be ASCII text, it appears to have been damaged; if this is from a wireless low-power network, perhaps there was radio interference.

score 0 · Accepted Answer · answered Sep 12 '22 at 15:12

0

The answer is easy... The content of the pcap packet was compressed with lz4...

answered Sep 12 '22 at 15:12

Johnny

1
3

Presumably meaning either that the payload of the UDP datagram or the Data part of what appears to be an MQTT-SN message is lz4 compressed. – user16139739 Sep 13 '22 at 06:14

How to read perfectly a .pcap file

3 Answers3