RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* [ADOPTION] TLV fields for radiotap
@ 2019-05-28  8:28 Johannes Berg
       [not found] ` <491eda86d6950994614d3ef095fcf91037f88aa3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2019-05-28  8:28 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

Oops, completely forgot that I still have to finish this!

Anyway, since there were no objections in much longer time, I guess we
can consider this adopted now. I'll work at least to get it into
wireshark, I think Richard had already polished my initial patch a bit
more.

--
title: TLV fields in radiotap
categories: [suggested]
--
Bit Number:
: 28

Structure:
: list of TLVs detailed below

Required alignment
: 4

Unit(s)
: unspecified

If this bit is set higher bits may not be set (as they cannot be
parsed, given the variable length of this field) and the data of this
field fills the remaining radiotap data (as indicated by the length
field in the header); the data is understood as a type-length-value item
list with the following item structure:

 * u16 type
 * u16 length
 * data ("length" bytes)
 * 0-3 padding bytes
   The whole item is padded to a multiple of 4 bytes length, but that
   padding is not taken into account in the 'length' field.

The type is taken from the regular radiotap type (bit) allocation, but
the special values 29 and 31 are not valid.

The vendor namespace type (30) may be used as a TLV field, but has the
following modified format as a TLV:
 - u16 type (30)
 - u16 length (length of data, as usual)
 - data containing
   - u8 OUI[3]
   - u8 subtype
   - u16 presence type (index of the bit previously used in the
                        presence bitmap, e.g. 0 for BIT(0))
   - u16 reserved (padding for 4-byte alignment of vendor data)
   - vendor data
 - padding (if needed)
As a consequence, multiple TLV fields are needed for multiple vendor
data items.


If field alignment is necessary beyond the 4-byte alignment, type 28
(i.e. this field value) shall be used as padding with an appropriate
length (which would likely often be 0 for 8-byte alignment). This
ensures parser simplicity, it doesn't need to be aware of alignment
rules.


Generators should generate data in fields with type < 28 in regular non-
TLV fields, this ensures backward compatibility.

Generators shall use TLV fields for all fields with type >= 32.

Parsers shall be able to parse TLV fields with partial data present as
indicated by the length of the data, i.e. producers can omit bytes they
don't fill at the end of the data. Such bytes are assumed to be 0.

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

* Re: [ADOPTION] TLV fields for radiotap
       [not found] ` <491eda86d6950994614d3ef095fcf91037f88aa3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2019-05-28 17:03   ` Richard Sharpe
  2019-06-27 19:04   ` Johannes Berg
  1 sibling, 0 replies; 3+ messages in thread
From: Richard Sharpe @ 2019-05-28 17:03 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Tue, May 28, 2019 at 1:28 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Oops, completely forgot that I still have to finish this!
>
> Anyway, since there were no objections in much longer time, I guess we
> can consider this adopted now. I'll work at least to get it into
> wireshark, I think Richard had already polished my initial patch a bit
> more.

Yes, I do have a slightly improved version.

I will try to extract it and make it available.

I also have an example program that can generate such captures if that
is useful.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)

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

* Re: [ADOPTION] TLV fields for radiotap
       [not found] ` <491eda86d6950994614d3ef095fcf91037f88aa3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  2019-05-28 17:03   ` Richard Sharpe
@ 2019-06-27 19:04   ` Johannes Berg
  1 sibling, 0 replies; 3+ messages in thread
From: Johannes Berg @ 2019-06-27 19:04 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

On Tue, 2019-05-28 at 10:28 +0200, Johannes Berg wrote:
> Oops, completely forgot that I still have to finish this!

And I forgot again, but now I'm marking it as a supported field in the
website.

johannes

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

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-28  8:28 [ADOPTION] TLV fields for radiotap Johannes Berg
     [not found] ` <491eda86d6950994614d3ef095fcf91037f88aa3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-05-28 17:03   ` Richard Sharpe
2019-06-27 19:04   ` 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