RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
@ 2017-12-14 21:06 Richard Sharpe
       [not found] ` <CACyXjPy9nUFhKmgzyVt6KBqHZW3oa0dgpkzQyGbtHHLOnC=f1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Sharpe @ 2017-12-14 21:06 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw

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
(何以解憂?唯有杜康。--曹操)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
       [not found] ` <CACyXjPy9nUFhKmgzyVt6KBqHZW3oa0dgpkzQyGbtHHLOnC=f1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-12-14 23:24   ` Guy Harris
       [not found]     ` <481F8A87-D5A1-440F-832F-7E433179A7F9-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Guy Harris @ 2017-12-14 23:24 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
       [not found]     ` <481F8A87-D5A1-440F-832F-7E433179A7F9-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2017-12-15  0:13       ` Richard Sharpe
       [not found]         ` <CACyXjPyh6H6-8BeUY-OPWAmdGEpzAQpYgMYy3rWGfNUxGY1xsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Sharpe @ 2017-12-15  0:13 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw

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
(何以解憂?唯有杜康。--曹操)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
       [not found]         ` <CACyXjPyh6H6-8BeUY-OPWAmdGEpzAQpYgMYy3rWGfNUxGY1xsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-12-15  1:52           ` Guy Harris
       [not found]             ` <7A209774-9919-455B-9E04-BDAF26BE99DA-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Guy Harris @ 2017-12-15  1:52 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
       [not found]             ` <7A209774-9919-455B-9E04-BDAF26BE99DA-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2017-12-15  8:24               ` Johannes Berg
  0 siblings, 0 replies; 5+ messages in thread
From: Johannes Berg @ 2017-12-15  8:24 UTC (permalink / raw)
  To: Guy Harris, Richard Sharpe; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-14 21:06 Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags? Richard Sharpe
     [not found] ` <CACyXjPy9nUFhKmgzyVt6KBqHZW3oa0dgpkzQyGbtHHLOnC=f1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 23:24   ` Guy Harris
     [not found]     ` <481F8A87-D5A1-440F-832F-7E433179A7F9-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2017-12-15  0:13       ` Richard Sharpe
     [not found]         ` <CACyXjPyh6H6-8BeUY-OPWAmdGEpzAQpYgMYy3rWGfNUxGY1xsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-15  1:52           ` Guy Harris
     [not found]             ` <7A209774-9919-455B-9E04-BDAF26BE99DA-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2017-12-15  8:24               ` Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git