RadioTap Archive on
 help / color / Atom feed
From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/>
To: Richard Sharpe
Subject: Re: Would it be useful to have preferences for radiotap to allow handling of captures with conflicting presence flags?
Date: Thu, 14 Dec 2017 17:52:02 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Dec 14, 2017, at 4:13 PM, Richard Sharpe <> 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:

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


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.

  parent reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-14 21:06 Richard Sharpe
     [not found] ` <>
2017-12-14 23:24   ` Guy Harris
     [not found]     ` <481F8A87-D5A1-440F-832F-7E433179A7F9-FrUbXkNCsVf2fBVCVOL8/>
2017-12-15  0:13       ` Richard Sharpe
     [not found]         ` <>
2017-12-15  1:52           ` Guy Harris [this message]
     [not found]             ` <7A209774-9919-455B-9E04-BDAF26BE99DA-FrUbXkNCsVf2fBVCVOL8/>
2017-12-15  8:24               ` Johannes Berg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \
    --to=guy-frubxkncsvf2fbvcvol8/ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone