Wireshark-users: Re: [Wireshark-users] Dissecting RouterOS 802.11 capture files.
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.
