What's the difference between a PCAP file with a magic number of "0x4d3cb2a1" and "0xd4c3b2a1"?

8
votes

I've got two PCAP files, A and B.

A has a 'magic number' in the header of d4 c3 b2 a1, B has a 'magic number' in the header of 4d 3c b2 a1. According to the wireshark documentation (http://wiki.wireshark.org/Development/LibpcapFileFormat), only 0xd4c3b2a1 and 0xa1b2c3d4 are valid magic numbers, which leads me to think that B is not a valid magic number.

Running file on linux backs this up, with the output of file A being:

tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

file B simply gives:

data

It looks like that whatever wrote B wrote it in a 'swapped' (little-endian) format, but wrote the forst twp bytes with the nibbles the wrong way round. Given that I'd expect a big-endian system to write the whole int32 the other way around and not the individual bytes, giving a magic number of 1a 2b 3c 4d.

Is B a valid file? If so, why? Can different systems write both 32-bit ints and the individual nibbles in a byte in an arbitrary order?

1
endiannesspcap

1 Answers

12
votes

What's the difference between a PCAP file with a magic number of “0x4d3cb2a1” and “0xd4c3b2a1”?

A pcap file with a magic number of 0xa1b23c4d or 0x4d3cb2a1 is a pcap file in which the packet time stamps are in seconds and nanoseconds.

A pcap file with a magic number of 0xa1b2c3d4 or 0xd4c3b2a1 is a "regular" pcap file in which the packet time stamps are in seconds and microseconds.

Where did you get file B? The only standard version of libpcap that writes files in "nanosecond-resolution" format is the version on the trunk of the libpcap Git tree, and that would only happen if the program using libpcap were reading another "nanosecond-resolution" format or explicitly requesting nanosecond-resolution time stamps from the network adapter (currently supported only on Linux, and probably requires a sufficiently recent kernel). That's also the only version that can read them. Wireshark won't produce them by default, although recent versions of Wireshark can read them.