Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

[Richard Sharpe]

I notice on this page

  http://www.radiotap.org/fields/suggested

it mentions that there are some conflicting usages of flag bits for radiotap.

Currently, Wireshark knows about bit 14 in the presence flags, but
hard-codes it for rx-Flags. It also doesn't know about tx-Flags (or
hardware-queue).

Would it be useful to allow the user to specify they want to be able
to switch between usages or are we trying to stamp out such
conflicting uses?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

[Guy Harris]

On Dec 14, 2017, at 1:06 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I notice on this page
> 
>  http://www.radiotap.org/fields/suggested
> 
> it mentions that there are some conflicting usages of flag bits for radiotap.
> 
> Currently, Wireshark knows about bit 14 in the presence flags, but
> hard-codes it for rx-Flags.

No, it has a preference for that, defaulting to rx-flags.  Tcpdump has no preference for it, hardwiring it to rx-flags.

> It also doesn't know about tx-Flags (or
> hardware-queue).
> 
> Would it be useful to allow the user to specify they want to be able
> to switch between usages or are we trying to stamp out such
> conflicting uses?

The conflicts are historical; I think the intent for radiotap is that further conflicts be at least *very strongly* discouraged, if not simply forbidden.  I vote for "forbidden".  As the page you cite says:

	Note that some fields currently have numbers assigned already, this is due to different OSes defining different bits unilaterally. *Such mistakes should not be repeated in the future.*

(emphasis mine).

The radiotap spec doesn't control what code that processes radiotap headers does; it neither requires nor forbids preferences.  I don't think it should require or forbid them as a way of dealing with existing conflicts, but it should (and does) say that no requirement for a preference should be introduced in the future.

Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

[Richard Sharpe]

On Thu, Dec 14, 2017 at 3:24 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
> On Dec 14, 2017, at 1:06 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I notice on this page
>>
>>  http://www.radiotap.org/fields/suggested
>>
>> it mentions that there are some conflicting usages of flag bits for radiotap.
>>
>> Currently, Wireshark knows about bit 14 in the presence flags, but
>> hard-codes it for rx-Flags.
>
> No, it has a preference for that, defaulting to rx-flags.  Tcpdump has no preference for it, hardwiring it to rx-flags.

Ahhh, I see you are correct. I looked for the radiotap protocol at
first and didn't see it. After you responded I looked in the code and
then discovered it was called 802.11 Radiotap. That's possibly a bit
onerous for users but that is a separate issue.

>> It also doesn't know about tx-Flags (or
>> hardware-queue).
>>
>> Would it be useful to allow the user to specify they want to be able
>> to switch between usages or are we trying to stamp out such
>> conflicting uses?
>
> The conflicts are historical; I think the intent for radiotap is that further conflicts be at least *very strongly* discouraged, if not simply forbidden.  I vote for "forbidden".  As the page you cite says:
>
>         Note that some fields currently have numbers assigned already, this is due to different OSes defining different bits unilaterally. *Such mistakes should not be repeated in the future.*
>
> (emphasis mine).
>
> The radiotap spec doesn't control what code that processes radiotap headers does; it neither requires nor forbids preferences.  I don't think it should require or forbid them as a way of dealing with existing conflicts, but it should (and does) say that no requirement for a preference should be introduced in the future.

Great. I will get to work adding some of the missing bits and maybe a
preference around the tx_flags and hardward_queue.

BTW, why is there what looks like 6-bytes of un-interpreted data
between the rx-flags and timestamp info?

I can send a capture if you would like to look.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)

Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

[Guy Harris]

On Dec 14, 2017, at 4:13 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Great. I will get to work adding some of the missing bits and maybe a
> preference around the tx_flags and hardward_queue.

My inclination is 1) not to add the presence bits for suggested fields to any code that processes radiotap headers unless there are capture files or devices that use them and 2) not to add preferences unless there are capture files or devices that one interpretation of the presence bit in question *and* capture files or devices that use the other interpretation.

If you're doing this because you're working on something that *generates* radiotap headers, I would suggest that you use only defined fields if possible and, if you need to add information that's *not* supported by any defined field, try to get a field defined - preferably with its own presence bit assigned.

> BTW, why is there what looks like 6-bytes of un-interpreted data
> between the rx-flags and timestamp info?

As the top-level radiotap page says:

	Radiotap requires that all fields in the radiotap header are aligned to natural boundaries. For radiotap, that means all 8-, 16-, 32-, and 64-bit fields must begin on 8-, 16-, 32-, and 64-bit boundaries, respectively. In this way, generators and parsers can avoid unaligned accesses to radiotap capture fields. Radiotap-compliant generators must insert padding before a capture field to ensure its natural alignment. Radiotap-compliant packet parsers, such as tcpdump(8), expect and skip the padding.

RX flags:

	http://www.radiotap.org/fields/RX%20flags.html

is a 2-byte field, requiring 2-byte alignment.

Timestamp:

	http://www.radiotap.org/fields/timestamp.html

requires 8-byte alignment, as it includes an 8-byte numerical value.

So if you have an RX flags field that happens to be aligned on an 8-byte boundary, followed immediately by a timestamp field, there needs to be 6 bytes of padding after the RX flags field to align the timestamp field on an 8-byte boundary.

Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?

[Johannes Berg]

On Thu, 2017-12-14 at 17:52 -0800, Guy Harris wrote:

> My inclination is 1) not to add the presence bits for suggested
> fields to any code that processes radiotap headers unless there are
> capture files or devices that use them and 

Absolutely - that's why we got this mailing list and process started in
the first place :-)

> 2) not to add preferences unless there are capture files or devices
> that one interpretation of the presence bit in question *and* capture
> files or devices that use the other interpretation.

Agree with this. We do have conflicts now because the spec historically
evolved in the header files in various *BSD & Linux trees, but that
should be a thing of the past now. At least, if anyone still does that
I'd hope we don't actually encourage it and add preferences for it.

> If you're doing this because you're working on something that
> *generates* radiotap headers, I would suggest that you use only
> defined fields if possible and, if you need to add information that's
> *not* supported by any defined field, try to get a field defined -
> preferably with its own presence bit assigned.

You could also use vendor fields if you really think it's not something
that benefits from proper definition/assignment.

johannes