RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* [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

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

I think this can be adopted now?

In the meantime OpenBSD has also removed the "hardware_queue" that was
conflicting with the bit number for the TX flags field, see
https://marc.info/?l=openbsd-cvs&m=160223361331358&w=2 This means the
following remark that the TX flags field clashes with OpenBSD does not
have to be included anymore:

On Fri, Oct 9, 2020 at 2:28 PM Mathy Vanhoef <vanhoefm@gmail.com> wrote:
> Used by NetBSD and Linux, clashes with ../hardware queue\_ as used in OpenBSD.

Best regards,
Mathy

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

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

On Sat, 2020-10-17 at 00:06 +0400, Mathy Vanhoef wrote:
> I think this can be adopted now?

Yes, looks like :-)

> In the meantime OpenBSD has also removed the "hardware_queue" that was
> conflicting with the bit number for the TX flags field, see
> https://marc.info/?l=openbsd-cvs&m=160223361331358&w=2 This means the
> following remark that the TX flags field clashes with OpenBSD does not
> have to be included anymore:
> 
> On Fri, Oct 9, 2020 at 2:28 PM Mathy Vanhoef <vanhoefm@gmail.com> wrote:
> > Used by NetBSD and Linux, clashes with ../hardware queue\_ as used in OpenBSD.

Nice :-)

I'm just about to go on vacation for a week, but if nobody else beats me
to it I'll make the appropriate changes when I return.

johannes


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

* Re: [RFA] TX Flags field
  2020-10-16 20:20   ` Johannes Berg
@ 2020-10-27  7:37     ` Johannes Berg
  0 siblings, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2020-10-27  7:37 UTC (permalink / raw)
  To: Mathy Vanhoef, radiotap

On Fri, 2020-10-16 at 22:20 +0200, Johannes Berg wrote:
> 
> I'm just about to go on vacation for a week, but if nobody else beats me
> to it I'll make the appropriate changes when I return.

Done, thanks Mathy!

johannes


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

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-09 10:28 [RFA] TX Flags field Mathy Vanhoef
2020-10-16 20:06 ` Mathy Vanhoef
2020-10-16 20:20   ` Johannes Berg
2020-10-27  7:37     ` 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 radiotap@archiver.kernel.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