This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Ignoring the first X bytes of a packet

2
1

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's gravatar image

Ewgenijkkg
668915
accept rate: 60%

edited 29 Oct '12, 15:05

grahamb's gravatar image

grahamb ♦
19.8k330206

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.

(29 Oct '12, 14:22) Guy Harris ♦♦

Hello. The capture was performed with tcpdump. Wireshark reads the dump file then.

If Wireshark's only reading the file, what format is it?

It was captured with the -w option of tcpdump, thus I suppose its the pcap-savefile format.

what's the link-layer header type

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

(30 Oct '12, 01:20) Ewgenijkkg

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

(30 Oct '12, 03:48) Jasper ♦♦

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.

(30 Oct '12, 08:38) Ewgenijkkg

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 :(

(30 Oct '12, 08:40) Ewgenijkkg

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?

(30 Oct '12, 09:33) Jasper ♦♦

The packets were captured on a wireless interface.

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?

(30 Oct '12, 13:29) Kurt Knochner ♦
showing 5 of 7 show 2 more comments

2 Answers:

7

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:

a1 b2 c3 d4

OK, that's a pcap file magic number, so I'm guessing this is a dump of the full pcap file. That means that:

00 02

Major pcap file format version number 2

00 04

Minor pcap file format version number 4

00 00 00 00

Time zone offset (which nobody ever actually sets, so it's always zero in practice)

00 00 00 00

Time stamp accuracy (which nobody ever actually sets, so it's always zero in practice)

00 00 00 44

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)

00 00 00 71

Link-layer header type (113, which is LINKTYPE_LINUX_SLL, used on Linux for the "any" device, some interfaces known to supply bogus headers such as PPP interfaces, and interfaces for which the ARPHRD_ value returned by the OS isn't one libpcap knows about; this is probably tcpdump on Linux with an unknown ARPHRD_ value)

50 8a 5e 87

Time stamp, seconds part

00 05 be e0

TIme stamp, microseconds part

00 00 00 44

Captured data length (68 bytes)

00 00 00 87

Actual packet length on the network (135 bytes, so the packet data was cut short to 68 bytes)

And the packet data, with a LINKTYPE_LINUX_SLL/DLT_LINUX_SLL header, which is described on the page linked to from the entry in the tcpdump.org link-layer header types page, is:

00 04

Packet type - "sent by us"

ff fe

ARPHRD_ type (ARPHRD_NONE, which claims to be "zero header length" in the comment for the entry in Linux's if_arp.h; is this going through a tuntap device from some user-land capture program?)

00 06

Link-layer address length - 6 octets (not surprising, if this is really 802.11 or even 802.16)

00 00 00 00 00 00 00 00

Link-layer address (as noted in the document, padded to 8 bytes)

00 00

Protocol type - 0x0000 is NOT a value listed in the Linux 3.0.4 if_ether.h, so that's either bogus, an undocumented value, or something in a later kernel version

ff ff ff ff ff ff 04 e5 48 01 d7 02 ff ff ff ff ff ff 00 00 00 00

A bunch of stuff that looks like MAC addresses plus 00 00 00 00

aa aa 03 00 00 00 07 07

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 ETH_P_ value in Linux.

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%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

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

"at this point my brain's wired to recognize aa aa 03 :-)"... You Sir are scary... :-D

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 ARPHRD_IEEE80211 or ARPHRD_IEEE80211_RADIOTAP as the ARPHRD_ type, and to supply the appropriate link-layer headers (802.11 or 802.11+radiotap).

(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 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 ETH_P_ value in Linux.

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

0

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%20Boyd's gravatar image

Jason Boyd
1
accept rate: 0%

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 ARPHRD_IEEE80211, they need to fix it. For that matter, unless there's some compelling reason why either ARPHRD_IEEE80211 or ARPHRD_IEEE80211_RADIOTAP shouldn't be the only mode, they should make it so - maybe ARPHRD_ETHER should be an alternative, and possibly the default alternative, but ARPHRD_NONE is completely bogus. (If they make it a mac80211 driver, perhaps that'll handle all that for them.)

(31 Oct '12, 09:59) Guy Harris ♦♦

They provide both a wireshark plugin to dissect their proprietary headers

Are you sure? I could not find anything about the plugin on their website...

(02 Nov '12, 03:19) Ewgenijkkg