Re: use of radiotap bit 14? [mostly 11n]

[Sam Leffler <sam-zZXckVAlHaQAvxtiuMwx3w@public.gmane.org>]

Guy Harris wrote:
> David Young wrote:
>> On Thu, Jun 19, 2008 at 09:10:33PM +0200, Johannes Berg wrote:
>>> Problem is, wireshark actually takes bit 14 to mean "FCS in header".
>>
>> I'd forgotten about that, but I think that we still have some 
>> flexibility.
>
> As per my mail, we can just take that out; OpenBSD defines it as "FCS 
> in header", but doesn't appear to use it, and I don't know of any 
> other system that uses it as "FCS in header".

Right, as I told you that mechanism was only ever defined by netbsd. 
Pulling the FCS out of band is not a good idea.  Presumably obsd just 
brought it over.

>
> Gerald, should we just remove the code that dissects 
> IEEE80211_RADIOTAP_FCS from the 1.0.1 Wireshark release, in 
> preparation for later releases interpreting presence bit 14 as RX flags?

As Guy mentioned I worked with him to resolve at least one conflict 
between various systems.  The definitions in freebsd have been in use 
for a while and have shipped in released versions of the os so there are 
many data files "in the field" and unless there's some way to maintain 
backwards compatibility it's unlikely they'll change.

As to shortgi et al, I've had simple 11n sniffing support for ~2 years 
and sent Gerald+Guy my mods to provide the most basic support in 
wireshark (haven't pushed tcpdump mods upstream year but they are in 
freebsd cvs).  Since then I've done more involved changes for wireshark 
but haven't pushed them back because I first wanted to leverage the PPI 
dissector's support for reconstructing AMPDU aggregates.  However my 
other changes build on the earlier work and that work addresses issues 
more general than 11n so I believe they are worth keeping.

>
> The collision problem with 15 and 16 is worse - OpenBSD defines 15 as 
> IEEE80211_RADIOTAP_HWQUEUE, and defines 16 as IEEE80211_RADIOTAP_RSSI, 
> and several of their drivers use one or the other or both.  Wireshark 
> currently doesn't dissect them; it should dissect them according to 
> the standard.

I gave up trying to deal w/ obsd and tell anyone that comes to me w/ 
data files from them that they need to convert formats if they want to 
inspect the data.  I know that doesn't help but given the way radiotap 
is designed (ATM) I don't see a better solution.

    Sam