RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Proposed Tx flag: don't reorder frames
@ 2020-07-24  5:58 Mathy Vanhoef
  2020-07-24 11:13 ` Johannes Berg
  0 siblings, 1 reply; 5+ messages in thread
From: Mathy Vanhoef @ 2020-07-24  5:58 UTC (permalink / raw)
  To: radiotap

Hello all,

I propose to add a DONT_REORDER bit to the existing TX flags field.
When this flag 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.

Concretely the proposal is to add the following Tx flag:

 |`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 |

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

Proposed 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

Note that on the radiotap website the TX flags field is still listed
under the "suggested fields" page, but I'm assuming that by now this
field is approved (since it's used in Linux)?

Best regards,
Mathy



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

* Re: Proposed Tx flag: don't reorder frames
  2020-07-24  5:58 Proposed Tx flag: don't reorder frames Mathy Vanhoef
@ 2020-07-24 11:13 ` Johannes Berg
  2020-08-30  0:05   ` Mathy Vanhoef
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Berg @ 2020-07-24 11:13 UTC (permalink / raw)
  To: Mathy Vanhoef, radiotap

On Fri, 2020-07-24 at 09:58 +0400, Mathy Vanhoef wrote:

> I propose to add a DONT_REORDER bit to the existing TX flags field.
> When this flag 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.

Interesting.

> Note that on the radiotap website the TX flags field is still listed
> under the "suggested fields" page, but I'm assuming that by now this
> field is approved (since it's used in Linux)?

No, it never was. I made an attempt at some point, but abandoned it for
some reason.

I see no reason why it couldn't be done though, and I guess this new
flag could be included from the start.

johannes




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

* Re: Proposed Tx flag: don't reorder frames
  2020-07-24 11:13 ` Johannes Berg
@ 2020-08-30  0:05   ` Mathy Vanhoef
  2020-09-17  9:57     ` Johannes Berg
  0 siblings, 1 reply; 5+ messages in thread
From: Mathy Vanhoef @ 2020-08-30  0:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap

To follow up on this: the only downside is that OpenBSD is using the
TX flags identifier to report the hardware queue on which a frame was
received.

Since Linux and NetBSD are using TX flags, and Wireshark decided to
already accept the patch to support TX flags as well, it seems to make
sense to let this identifier represent TX flags. Then only one
implementation (OpenBSD) would have to be updated to match this. I'm
assuming nobody would be against this, since there have been more than
three weeks to discuss this, and nobody brought this up.

What's the next step? Adopt the proposal in one week if there are no
further objections?

Best regards,
Mathy

PS: Is the archive on https://lore.kernel.org/radiotap/ being updated?


On Fri, Jul 24, 2020 at 3:13 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2020-07-24 at 09:58 +0400, Mathy Vanhoef wrote:
>
> > I propose to add a DONT_REORDER bit to the existing TX flags field.
> > When this flag 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.
>
> Interesting.
>
> > Note that on the radiotap website the TX flags field is still listed
> > under the "suggested fields" page, but I'm assuming that by now this
> > field is approved (since it's used in Linux)?
>
> No, it never was. I made an attempt at some point, but abandoned it for
> some reason.
>
> I see no reason why it couldn't be done though, and I guess this new
> flag could be included from the start.
>
> johannes
>



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

* Re: Proposed Tx flag: don't reorder frames
  2020-08-30  0:05   ` Mathy Vanhoef
@ 2020-09-17  9:57     ` Johannes Berg
  2020-10-01  5:59       ` Mathy Vanhoef
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Berg @ 2020-09-17  9:57 UTC (permalink / raw)
  To: Mathy Vanhoef; +Cc: radiotap

On Sun, 2020-08-30 at 04:05 +0400, Mathy Vanhoef wrote:
> To follow up on this: the only downside is that OpenBSD is using the
> TX flags identifier to report the hardware queue on which a frame was
> received.
> 
> Since Linux and NetBSD are using TX flags, and Wireshark decided to
> already accept the patch to support TX flags as well, it seems to make
> sense to let this identifier represent TX flags. Then only one
> implementation (OpenBSD) would have to be updated to match this. I'm
> assuming nobody would be against this, since there have been more than
> three weeks to discuss this, and nobody brought this up.
> 
> What's the next step? Adopt the proposal in one week if there are no
> further objections?

Sorry this took so long.

I think we need to make a proper proposal again for the whole TX flags
field, since that was never officially adopted?


> PS: Is the archive on https://lore.kernel.org/radiotap/ being updated?

Looks like no, I have asked the admins there, but didn't hear back yet.

johannes




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

* Re: Proposed Tx flag: don't reorder frames
  2020-09-17  9:57     ` Johannes Berg
@ 2020-10-01  5:59       ` Mathy Vanhoef
  0 siblings, 0 replies; 5+ messages in thread
From: Mathy Vanhoef @ 2020-10-01  5:59 UTC (permalink / raw)
  To: Johannes Berg; +Cc: radiotap

> I think we need to make a proper proposal again for the whole TX flags
> field, since that was never officially adopted?

That makes sense, I'll send a new mail for that in the next day(s).

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

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-24  5:58 Proposed Tx flag: don't reorder frames Mathy Vanhoef
2020-07-24 11:13 ` Johannes Berg
2020-08-30  0:05   ` Mathy Vanhoef
2020-09-17  9:57     ` Johannes Berg
2020-10-01  5:59       ` Mathy Vanhoef

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