Got a capture with a wrong sll header and wireshark fails to find the IP header. Any ideas on how to bypass this problem and be able to read the trace anyway? Thanks and regards Matthias asked 08 Nov '15, 01:50 mrEEde edited 08 Nov '15, 04:18 showing 5 of 12 show 7 more comments |
2 Answers:
You could use editcap to remove 4 bytes, starting at an offset of 6, from each packet:
or 4 bytes from some other offset if that's what's required to give it the right MAC address - as long as the 0x00 0x00 before the 0x08 0x00 aren't part of the MAC address (if they are, you'd have to have a program remove 6 bytes and add 2 padding bytes before the 0x08 0x00). answered 08 Nov '15, 04:05 Guy Harris ♦♦ editcap −C 6:4 linux_cooked.pcapng linux_cooked_fixed.pcapng editcap: Can't open −C: No such file or directory :-( (08 Nov '15, 04:24) mrEEde You'll need a newer version of Wireshark, then. The ability to chop data starting at a given offset was introduced in this change:
Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
|
Hm, that download location requires a login... you might want to put it up at http://www.cloudshark.org or any other location where anyone can access it without credentials.
How was that trace captured? That link-layer header does not match the tcpdump.org description of a Linux cooked capture header - according to that description, the link-layer address starts at the 6th byte of the header and runs for 8 bytes, possibly with padding, and the address length field has the value 6, so the MAC address is e8:e7:32:d0:51:19, with two padding bytes of 0x81 and 0x00 following it, and with the protocol type immediately following that.
That header appears to have 12 bytes of link-layer address or, at least, 12 bytes of something between the link-layer address length and protocol type fields.
I have no idea how this trace was taken - it's from an appliance with RedHat Linux ...
Perhaps the appliance vendor "improved" libpcap; report this to them as a bug.
Hm, looks like they may have fumbled a VLAN tag into the SLL header, at least 0x8100 (Ethertype for 802.1Q) and two more bytes seem familiar...
Yes, it's the default location to insert a VLAN header..... in an Ethernet frame. Unfortunately they used the same code to do that for an SLL frame. If they would have inserted it two octets further in the frame all would be fine.
Try importing this frame which has this change applied
Not as of libpcap 1.4.0 it doesn't. That bug was in releases up to 1.3.0, but Jakub Zawadzki submitted a patch for that and a fix was checked in 2012-08-18.
What version of Red Hat was the appliance running - and, if you can determine it, what version of libpcap was it running?
uname -a Linux 2.6.32-504.23.4.el6.x86_64 #1 (RHEL6)
SMP Fri May 29 10:16:43 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
libcap-2.16-5.5.el6.x86_64
libpcap, not libcap - they're different libraries. Some Web searches suggest that RHEL 6 might have libpcap 1.4.0, but perhaps the presumed RHEL 6 on the machine (inferred from the kernel information) has an older version, if RHEL 6 started with an older version and later updated to 1.4.x.
sorry,
libpcap-1.0.0-6.20091201git117cb5.el6.x86_64
Yeah, that's too old (1.0.0, and 2009-12-01 is almost 4 years before I checked Jakub's change in). You might want to tell the appliance vendor that they might want to update the RHEL 6 packages.