From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org Subject: [ADOPTION] TLV fields for radiotap Date: Tue, 28 May 2019 10:28:01 +0200 Message-ID: <email@example.com> (raw) 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 - 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.
next reply index Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-28 8:28 Johannes Berg [this message] [not found] ` <491eda86d6950994614d3ef095fcf91037f88aa3.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> 2019-05-28 17:03 ` Richard Sharpe 2019-06-27 19:04 ` 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 \ --firstname.lastname@example.org \ --email@example.com \ --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 \ firstname.lastname@example.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