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

Question

I have two PCAP files, A and B

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

Running file on linux completes this, with the output of file A :

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

file B just gives:

 data 

It seems that everything that B wrote wrote it in a "swapped" (little-endian) format, but it wrote forst twp bytes with bits of the wrong path. Given that I would expect the big-endian system to write the whole int32 differently, rather than individual bytes, giving the magic number 1a 2b 3c 4d .

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

Answer 1

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

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

A pcap file with a magic number of 0xa1b2c3d4 or 0xd4c3b2a1 is a “regular” pcap file in which packet timestamps are in seconds and microseconds.

Where did you get file B? The only standard version of libpcap that writes files in the "nanosecond resolution" format is the version on the trunk of the libpcap Git tree, and this will only happen if the program using libpcap reads a different "nanosecond resolution" format or explicitly requests timestamps nanosecond resolution from the network adapter (currently only supported on Linux, and probably the latest kernel is enough). This is also the only version that can read them. Wireshark will not produce them by default, although recent versions of Wireshark can read them.