RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: [RFA] TLV fields for radiotap
Date: Mon, 09 Jul 2018 10:47:14 +0200
Message-ID: <1531126034.3298.18.camel@sipsolutions.net> (raw)

Since there were no comments, let's make this more formal. Any
objections now?


--
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 following it is to
be understand as a type-length-value format, with this structure:

 * u16 type
 * u16 length
 * data ("length" bytes)
 * 0-3 padding bytes
   The whole thing 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, vendor namespaces (type
30) may be used as TLV fields.

If field alignment is necessary beyond the 4-byte alignment, type 28
(i.e. this extension) 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,
i.e. allow parsing optional values at the end of a field.

             reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09  8:47 Johannes Berg [this message]
     [not found] ` <1531126034.3298.18.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-09-04 12:14   ` Johannes Berg
     [not found]     ` <1536063298.3940.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-11-20 20:09       ` Johannes Berg
     [not found]         ` <81658b7a400e6189c55587c8276d5555b6fe37f0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-12-18  2:05           ` David Young
     [not found]             ` <20181218020526.GH27633-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2018-12-18 13:45               ` Johannes Berg
     [not found]                 ` <2c771c875d88d51d1cd98023686f084a5b6486bc.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-09  8:38                   ` Johannes Berg
2019-04-09  8:51 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1531126034.3298.18.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

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