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?
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.