Hello, community. I'm capturing packets where the first X bytes (a special header) are not covered by any dissector available. Therefore, the rest of the package is not dissected anymore. Is it possible to instruct Wireshark to ignore the first X bytes and proceed further? Or is the only feasible option to write an own dissector for the first part of the package - the first X bytes? BR Ewgenij asked 29 Oct '12, 07:27  Ewgenijkkg edited 29 Oct '12, 15:05  grahamb ♦ showing 5 of 7 show 2 more comments |
2 Answers:
Actually, no, the 12 bytes before 07 07 are NOT destination source and MAC addresses. aa aa 03 is an IEEE 802.2 header with a DSAP and SSAP of aa, meaning SNAP (at this point my brain's wired to recognize aa aa 03 :-)); the 00 00 00 07 07 is a SNAP header with an OUI of 00 00 00, meaning "the protocol ID is an Ethernet type", and a protocol ID of 07 07, which is not a publicly registered Ethernet type and not listed in the official IEEE registry of Ethertypes as of 2012-10-30. However, Googling for "ethertype 0707" found ETSI CTI Plugtests Guide Stable Draft V0.0.9 (2011-11) "Cooperative Mobility Services Plugtests; Helmond, Netherlands; 14 - 18 November 2011", which says "The ether type 0x0707 shall be used to indicate a GeoNetworking packet." It also says "The PHY layer of the communication system is based on IEEE802.11p-2010." The ff ff ff ff ff ff 04 e5 48 01 d7 02 ff ff ff ff ff ff preceding it looks as if it might be three MAC addresses - two broadcast and one unicast. Digging around looking for specifications for the protocols being used (and avoiding any references to ISO standards, as I'm a cheap bastard and would rather not pay, for example, CHF 140 or so for one of the standards I found) found ETSI EN 302 665 V1.1.1 (2010-09) "Intelligent Transport Systems (ITS); Communications Architecture". That appeared to suggest that one link layer for this was Final draft ETSI ES 202 663 V1.1.0 (2009-11) "Intelligent Transport Systems (ITS); European profile standard for the physical and medium access control layer of Intelligent Transport Systems operating in the 5 GHz frequency band", which is Good Old Wi-Fi. Another one to which it refers is ISO/IEC IS 21215 "Intelligent Transport Systems - Communications access for land mobiles (CALM) - M5 medium"; I'm too cheap (as noted earlier) to buy that document, but the Wikipedia page for CALM lists a bunch of link layers, including 802.11 (Wi-Fi), 802.16 (WiMAX), Bluetooth, and GSM/UMTS, and there's a link for "M5" that goes to a Wikipedia page for CALM M5, and that page says "CALM M5 is the ISO 21215 standard that incorporates WAVE (WAVE PHY/MAC is IEEE 802.11p standard) and adds the following features:..." So there might be an 802.11 header somewhere in there - or it might be WiMAX, or it might be something else. My guess is that it's probably either 802.11 or 802.16, given the 802.2+SNAP header. So, looking at the hex dump:
OK, that's a pcap file magic number, so I'm guessing this is a dump of the full pcap file. That means that:
Major pcap file format version number 2
Minor pcap file format version number 4
Time zone offset (which nobody ever actually sets, so it's always zero in practice)
Time stamp accuracy (which nobody ever actually sets, so it's always zero in practice)
Snapshot length (68, which was, until recently, the tcpdump default for non-IPv6-enabled tcpdump; the default is now 65535 so you get full packets by default)
Link-layer header type (113, which is
Time stamp, seconds part
TIme stamp, microseconds part
Captured data length (68 bytes)
Actual packet length on the network (135 bytes, so the packet data was cut short to 68 bytes) And the packet data, with a
Packet type - "sent by us"
Link-layer address length - 6 octets (not surprising, if this is really 802.11 or even 802.16)
Link-layer address (as noted in the document, padded to 8 bytes)
Protocol type - 0x0000 is NOT a value listed in the Linux 3.0.4
A bunch of stuff that looks like MAC addresses plus 00 00 00 00
802.2 and SNAP header So Wireshark should be dissecting this as "Linux cooked-mode capture", and should be showing the payload as raw data, given that 0x0000 is not a known So either Wireshark needs to be made to handle 0x0000 in that case, whatever the right thing to do there is, or the code in Linux (network layer or driver) or whatever's supplying the packets to the system needs to be fixed to set the protocol type correctly. answered 30 Oct '12, 11:51  Guy Harris ♦♦ edited 30 Oct '12, 12:29 1 "at this point my brain's wired to recognize aa aa 03 :-)"... You Sir are scary... :-D (30 Oct '12, 11:54) Jasper ♦♦ 1
That's what 14 years of hacking Wireshark and 12 years of hacking libpcap/tcpdump will do to your brain.... (30 Oct '12, 12:25) Guy Harris ♦♦ 1 And if the Cohda device is a MK2 WAVE-DSRC Radio, then it's definitely 802.11p. If tcpdump was running on the embedded processor - the pcap file is big-endian, which makes it more likely that it was, as a typical Linux box is x86 and thus little-endian - you might want to ask the fine folks at Cohda Wireless to fix their driver, or whatever, to use (30 Oct '12, 15:02) Guy Harris ♦♦ OK, guys, thank you very much for your in-depth answers. I will investigate then :) Greetings from Germany Ewgenij (02 Nov '12, 02:07) Ewgenijkkg
So, if 0x0000 would be a valid protocol value, the header would not be linux-cooked capture but ethernet, for example. Do I understand it right? And independent from that, if bytes after the link-layer would fit into higher level protocols, Wireshark would dissect them correctly? It would not present them as raw bytes, if I got it right. Did I? :) (02 Nov '12, 02:39) Ewgenijkkg |
Hi Ewgenij, I strongly suggest you get in contact with the folks at Cohda: http://www.cohdawireless.com/contact/default.html They provide both a wireshark plugin to dissect their proprietary headers and a mechanism to switch the monitoring interface to ARPHRD_IEEE80211. answered 31 Oct '12, 01:59  Jason Boyd If they provide that dissector to their commercial customers, I think they have to disclose the source code of the dissector, due to GPL licensing ;-) (31 Oct '12, 02:39) Kurt Knochner ♦ And if their documentation doesn't explain that you want to switch the monitoring interface to (31 Oct '12, 09:59) Guy Harris ♦♦
Are you sure? I could not find anything about the plugin on their website... (02 Nov '12, 03:19) Ewgenijkkg |
Capturing with Wireshark (or tcpdump or some other libpcap/WinPcap-based tool), or with some other special software (possibly piping to Wireshark/TShark over a named pipe, or possibly capturing to a file and having Wireshark read the file)? If Wireshark's only reading the file, what format is it? If it's a pcap or pcap-ng file, or a live capture, what's the link-layer header type? Perhaps a new link-layer header type needs to be assigned to it.
Hello. The capture was performed with tcpdump. Wireshark reads the dump file then.
It was captured with the -w option of tcpdump, thus I suppose its the pcap-savefile format.
The packets were captured on a wireless interface. The wireless communication is running over special wirelss modules of Cohda http://www.cohdawireless.com/ The Cohda headers are unknown to Wireshark, therefore no processing is possible. Thus, the idea was to remove these additional bytes from the capture file.
Regards Ewgenij Sokolovski
[I converted your comment from an Answer to a comment to keep things structured]
Can you provide a sample trace to take a look at? If that is not possible, how many bytes do you need to remove from the start of each packet?
Hello, it's not a secret :) Here is the example
a1 b2 c3 d4 00 02 00 04 00 00 00 00 00 00 00 00 00 00 00 44 00 00 00 71 50 8a 5e 87 00 05 be e0 00 00 00 44 00 00 00 87 00 04 ff fe 00 06 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 04 e5 48 01 d7 02 ff ff ff ff ff ff 00 00 00 00 aa aa 03 00 00 00 07 07
The last two bytes 07 07 are the protocal type and the 12 bytes before them are destination and source MAC addresses.
The sequence
00 05 be e0 00 00 00 44 00 00 00 87 00 04 ff fe 00 06 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff 04 e5 48 01 d7 02 ff ff ff ff
is then the special Cohda stuff, which wireshark apparently can't deal with.
BR Ewgenij
P.S. Isn't it possible to place more signs in one single comment? I got to split the text in two comments :(
Yeah, the length limitation of comments is a constant problem... no idea if the admins could increase the limit.
Can you upload the sample to www.cloudshark.org and post the link? That would make it easier to look at things in a binary way. If I get this correctly from what you've posted the Destination MAC is ff:ff:00:00:00:00, the Source MAC is aa:aa:03:00:00:00, and the ether type 0x0707. Correct?
What is the stuff that comes before the Cohda stuff, starting with a1 b2 c3 ... up to 50 8a 5e 87?
Cohda offers a wireless board with a CAN bus and USB 2.0 host interface. So, how and where did you capture the data?
Is it an embedded linux running on the board itself or through a driver that offers some kind of (wireless) interface to a standard linux?