Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Dissecting RouterOS 802.11 capture files.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 19 Mar 2007 11:02:22 -0700
Sten Daniel Soersdal wrote:
Hi, i'm a new Wireshark user, old time Ethereal user.

Same program, just a different name.

I noticed Wireshark cannot read properly the capture files captured by
routeros (www.mikrotik.com).

Either that, or RouterOS isn't properly *writing* the capture files.

It is only the 'radiotap header' that
displays incorrectly.

The packets' radiotap header shows:

Header revision: 0
Header pad: 0
Header lenght: 14

The data fields are not padded for WORD aligned like Wireshark seems to
expect,

Wireshark expects it because that's how the radiotap header is *DEFINED* to work. To quote the NetBSD man page for radiotap (the emphasis in the quote is from the man page):

	http://netbsd.gw.com/cgi-bin/man-cgi?ieee80211_radiotap+9+NetBSD-current

Radiotap capture fields *must be naturally aligned*. That is, 16-, 32-, and 64-bit fields must begin on 16-, 32-, and 64-bit boundaries, respectively. In this way, drivers can avoid unaligned accesses to radiotap capture fields. radiotap-compliant drivers must insert padding before a capture field to ensure its natural alignment. radiotap-compliant packet dissectors, such as tcpdump(8), expect the padding.

The change to the Wireshark dissector to make it be radiotap-compliant, and expect the padding, was made because David Young, one of the (if not the) originator of the radiotap header, pointed out that it was required.

Is anyone perhaps interested in adding this support?

I have no interest in breaking the radiotap dissector by making it assume no padding. If there's a *reliable* mechanism for detecting RouterOS's broken radiotap header, I'd be willing to accept a patch from somebody for that, but I don't want to lose any ability to read correct radiotap files.

The right fix is to RouterOS, to have it pad the data fields correctly; complain to MikroTik.