Assigning a new DLT_ value for "standardized" radiotap?

Assigning a new DLT_ value for "standardized" radiotap?

[Guy Harris]

The presence-bit-number collisions mentioned on the radiotap Web site appear to be due to OpenBSD doing its own thing:

	14: FCS in OpenBSD, RX Flags in the standard and assigned for that in NetBSD and Linux
	15: hardware queue in OpenBSD, proposed for TX flags in the standard and assigned for that in NetBSD and Linux
	16: RSSI in OpenBSD, proposed for RTS Retries in the standard and assigned for that in NetBSD and Linux

(There was also a brief period of time, between 2007-06-11 and 2007-07-01, where FreeBSD used 14 for the extended channel information, but it got moved to 18; it appears that was done before FreeBSD 7.0 got released, so it doesn't appear that any *released* version used 14 for the extended channel information.)

I've filed an bug against this:

	http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5691

but nothing has been done for it; I've also asked Reyk Floeter about it, and heard nothing.  I forget whether I've asked Damien Bergamini about it or not.

Unfortunately, there are probably both OpenBSD and NetBSD/Linux captures out there with a network type value of 127, so we can't easily make tcpdump or Wireshark or... handle both automatically (a command-line flag for tcpdump and a preference for Wireshark could be used).  If we were to introduce a new DLT_ value for "standard radiotap", tcpdump and Wireshark could unconditionally interpret those presence bit values as having the NetBSD/Linux meaning, and use a flag/preference or whatever for the existing value (or just blow off OpenBSD).

Would that be useful?

Re: Assigning a new DLT_ value for "standardized" radiotap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Tue, 2010-02-16 at 18:08 -0800, Guy Harris wrote:
> The presence-bit-number collisions mentioned on the radiotap Web site
> appear to be due to OpenBSD doing its own thing:
> 
> 	14: FCS in OpenBSD, RX Flags in the standard and assigned for that in
> NetBSD and Linux

Didn't I go and add a preferences setting to wireshark for this
collision?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Assigning a new DLT_ value for "standardized" radiotap?

[Gábor Stefanik]

On Wed, Feb 17, 2010 at 9:27 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Tue, 2010-02-16 at 18:08 -0800, Guy Harris wrote:
>> The presence-bit-number collisions mentioned on the radiotap Web site
>> appear to be due to OpenBSD doing its own thing:
>>
>>       14: FCS in OpenBSD, RX Flags in the standard and assigned for that in
>> NetBSD and Linux
>
> Didn't I go and add a preferences setting to wireshark for this
> collision?
>
> johannes
>

Yes, but Guy is talking about auto-detection.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: Assigning a new DLT_ value for "standardized" radiotap?

[Guy Harris]

On Feb 17, 2010, at 12:38 AM, Gábor Stefanik wrote:

> Yes, but Guy is talking about auto-detection.

Or, at least, semi-automatic - the preference would be ignored for the new DLT_ value, as those captures always use the standard presence bit values; it would be needed only for the old DLT_ value.