Wireshark-bugs: [Wireshark-bugs] [Bug 11165] mergecap output wrong 'magic number'
Guy Harris
changed
bug 11165
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
RESOLVED
|
| Resolution |
---
|
NOTABUG
|
Comment # 1
on bug 11165
from Guy Harris
(In reply to Jeevaka from comment #0)
> After command:
> mergecap -F pcap -w 1617_17.pcap 20150417160000.pcap 20150417170000.pcap
>
> I had some trouble with the output file and checked the headers.
> It seems that for the first two bytes of the header the nibbles get swapped
> around in the output. I.e. 'd4 c3' instead of '4d 3c' making the 'endian
> detection' to fail for pcap readers.
Actually, both a1 b2 c3 d4/d4 c3 b2 a1 *AND* a1 b2 3c 4d/4d 3c b2 a1 are valid
magic numbers.
a1 b2 c3 d4/d4 c3 b2 a1 is the original pcap magic number for the original pcap
format. In that format, packet time stamps are represented as seconds since
January 1, 1970, 00:00:00 UTC, plus microseconds since the beginning of the
second, so it has microsecond resolution for time stamps. Any code that can't
read *that* is extremely broken.
a1 b2 3c 4d/4d 3c b2 a1 is the magic number for "nanosecond resolution" pcap
files. That's a relatively recent addition. In *that* format, packet time
stamps are represented as seconds since January 1, 1970, 00:00:00 UTC, plus
*nano*seconds since the beginning of the second, so it has nanosecond
resolution for time stamps. Libpcap has been able to read those since libpcap
0.9, and Wireshark has been able to read them for a while as well.
Mergecap probably should have chosen nanosecond resolution pcap - "nseclibpcap"
- format to write the file out, rather than original pcap - "libpcap" - format,
as both of the input files are nanosecond resolution pcap files. However,
that's a separate issue (which I'll address when I find time to do my big
mergecap cleanup).
If you know of code that, when reading pcap files, can't handle a1 b2 c3 d4 or
d4 c3 b2 a1, please file a bug against it, as it's not going to be able to read
the pcap files that have been written over the past 22 years or so.
If you know of code that, when reading pcap files, can't handle a1 b2 3c 4d or
4d 3c b2 a1, file an enhancement request against it, to get it to read
nanosecond resolution pcap files.
Note, however, that if the code in question is a program that uses libpcap to
read capture files, the problem is not in the program, the problem is that the
program is, for whatever reason, using an old version of libpcap.
> Two input files have big endian pcap headers
No, they don't. If they had big-endian pcap headers, they'd begin with a1 b2
c3 d4 or a1 b2 3c 4d.
You are receiving this mail because:
- You are watching all bug changes.
