[RFA] TX Flags field

* [RFA] TX Flags field
@ 2020-10-09 10:28 Mathy Vanhoef
  2020-10-16 20:06 ` Mathy Vanhoef
  0 siblings, 1 reply; 4+ messages in thread
From: Mathy Vanhoef @ 2020-10-09 10:28 UTC (permalink / raw)
  To: radiotap

Hi all,

This is a request for adoption of the TX flags field (including a
DONT_REORDER bit) as a follow-up to the previous RFC mail. The TX
flags field is currently a suggested but not officially adopted field.
It's already used by Linux and NetBSD.

The bit number for the TX flags field (15) clashes with the 'hardware
queue' field in OpenBSD. Although some OpenBSD drivers fill in this
hardware queue field, I didn't find any OpenBSD programs that seem to
use it. So I think that OpenBSD can update their radiotap definition
to use the TX flags field with little negative impact (correct me if
I'm wrong!).

Below is the concrete proposal. This corresponds to the previously
suggested but not yet adopted TX flags field, along with a DONT_REODER
bit. When the DONT_REORDER bit is set, injected frames shouldn't be
reordered relative to other frames that also have this flag set (even
when these frames have different QoS TID values). This for example
allows userspace to inject frames that have different QoS TID fields
while assuring that they are transmitted in the order as they were
injected. In practice, this is useful to perform certain experiments
where the order of transmitted frames is important.

Linux is already using the TX flags field apart from the DONT_REORDER bit.

Proposed patches for the DONT_REORDER bit and some Linux drivers can
be found here:
https://lore.kernel.org/linux-wireless/20200724054724.105520-1-Mathy.Vanhoef@kuleuven.be/T/

Already adopted change for wireshark which parses the Tx flags,
including the new don't order flag, is here:
https://code.wireshark.org/review/#/c/37944/

And a proposed update to scapy to recognize the don't order flag:
https://github.com/secdev/scapy/pull/2734

Best regards,
Mathy

---
title: TX flags
categories: [suggested]
---
Bit Number
: 15

Structure
: u16 flags

Required Alignment
: 2

Unit
: bitmap

Properties of transmitted frames.

|**mask** |**meaning** |
|`0x0001` |Transmission failed due to excessive retries |
|`0x0002` |Transmission used CTS-to-self protection |
|`0x0004` |Transmission used RTS/CTS handshake |
|`0x0008` |Transmission shall not expect an ACK frame and not retry
when no ACK is received |
|`0x0010` |Transmission includes a pre-configured sequence number that
should not be changed by the driver's TX handlers |
|`0x0020` |Transmission should not be reordered relative to other
frames that have this flag set |

Discussion
==========

Used by NetBSD and Linux, clashes with ../hardware queue\_ as used in OpenBSD.

The no-ack bit (0x0008) is used for uses of radiotap when frames are
sent. Similarly, the no-seq bit (0x0010) is used to allow userspace to
send frames with a specific sequence number (e.g. when transmitting
fragments of a single frame one-by-one). When it is set, the frame
should be transmitted with the sequence number included in the 802.11
MAC header of the frame as received from userspace, regardless of the
state of the sequence counters in driver/hardware. When the
DONT_REORDER bit (0x0020) is set, injected frames aren't reordered
relative to other frames that also have this bit set (even when these
frames have different QoS TID values).

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