tx_status reporting of RTS/CTS frames

tx_status reporting of RTS/CTS frames

[Mattias Nissler]

Hi,

rt2x00 devices can't generate rts/cts frames themselves, but rely on the
driver to generate them. Also, the hardware reports tx status back for
those frames. Now the question is whether these frames should be
reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
this has some subtle effects, e.g. they won't show up on monitor
interfaces if we don't report them.

I'd like to know the official policy. Cause if they are supposed to
reported, I need to filter them in the rate control algorithm. This is
to make sure the failed frames percentage count isn't biased for drivers
that report them compared to drivers that cannot.

Mattias

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi,

> rt2x00 devices can't generate rts/cts frames themselves, but rely on the
> driver to generate them. Also, the hardware reports tx status back for
> those frames. Now the question is whether these frames should be
> reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
> this has some subtle effects, e.g. they won't show up on monitor
> interfaces if we don't report them.

They never show up on monitor interfaces for all other hardware because
there the hardware handles them. How is it that rt2x00 cannot handle
rts? It has to at least know that an RTS was sent and to send the frame
only after the CTS, and that needs to be a MAC function and cannot be
implemented in host software.

So, I'd think they shouldn't be reported at all.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: tx_status reporting of RTS/CTS frames

[Mattias Nissler]

On Wed, 2007-12-12 at 18:15 +0100, Johannes Berg wrote:
> Hi,
> 
> > rt2x00 devices can't generate rts/cts frames themselves, but rely on the
> > driver to generate them. Also, the hardware reports tx status back for
> > those frames. Now the question is whether these frames should be
> > reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
> > this has some subtle effects, e.g. they won't show up on monitor
> > interfaces if we don't report them.
> 
> They never show up on monitor interfaces for all other hardware because
> there the hardware handles them. How is it that rt2x00 cannot handle
> rts? It has to at least know that an RTS was sent and to send the frame
> only after the CTS, and that needs to be a MAC function and cannot be
> implemented in host software.

rt2x00 devices have some flags in the TX descriptor that basically tell
the device to send a burst of frames, optionally requesting to wait for
an ack (i.e. CTS in the case of an RTS frame) for any of them.

> So, I'd think they shouldn't be reported at all.

Ok, I'll prepare a patch for rt2x00.

Mattias

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]


> rt2x00 devices have some flags in the TX descriptor that basically tell
> the device to send a burst of frames, optionally requesting to wait for
> an ack (i.e. CTS in the case of an RTS frame) for any of them.

Interesting. I can't the place where that is set though, can you point
me to it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: tx_status reporting of RTS/CTS frames

[Mattias Nissler]

On Thu, 2007-12-13 at 12:34 +0100, Johannes Berg wrote:
> > rt2x00 devices have some flags in the TX descriptor that basically tell
> > the device to send a burst of frames, optionally requesting to wait for
> > an ack (i.e. CTS in the case of an RTS frame) for any of them.
> 
> Interesting. I can't the place where that is set though, can you point
> me to it?

For each frame, rt2x00 creates a txdata_entry_desc structure (see
rt2x00lib_write_tx_desc()), which holds all the information that is
written to the actual tx descriptors (format of these varies among the
different devices we support, but the information in the tx descriptors
is roughly the same). See rt61pci_write_tx_desc() for an example of how
the information is stored into the actual tx descriptor, but that's
rather boring.

The bits you're interested in are ENTRY_TXD_ACK and ENTRY_TXD_BURST.
BURST tells the device the next frame is part of the same burst (also
note that we have to set the correct IFS), i.e. the next frame goes out
directly after the current one (respecting the IFS of course). The
TXD_ACK bit means the hardware should wait for an ack of some kind (e.g.
CTS for RTS frames).

Mattas

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]


> The bits you're interested in are ENTRY_TXD_ACK and ENTRY_TXD_BURST.
> BURST tells the device the next frame is part of the same burst (also
> note that we have to set the correct IFS), i.e. the next frame goes out
> directly after the current one (respecting the IFS of course). The
> TXD_ACK bit means the hardware should wait for an ack of some kind (e.g.
> CTS for RTS frames).

Ah, I see. I was grepping for the TXCTL flags for RTS/CTS and couldn't
find anything. Thanks.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: tx_status reporting of RTS/CTS frames

[Jouni Malinen]

On Wed, Dec 12, 2007 at 06:15:02PM +0100, Johannes Berg wrote:

> > rt2x00 devices can't generate rts/cts frames themselves, but rely on the
> > driver to generate them. Also, the hardware reports tx status back for
> > those frames. Now the question is whether these frames should be
> > reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
> > this has some subtle effects, e.g. they won't show up on monitor
> > interfaces if we don't report them.
> 
> They never show up on monitor interfaces for all other hardware because
> there the hardware handles them. How is it that rt2x00 cannot handle
> rts? It has to at least know that an RTS was sent and to send the frame
> only after the CTS, and that needs to be a MAC function and cannot be
> implemented in host software.
> 
> So, I'd think they shouldn't be reported at all.

I'm not sure I understood the comment about monitor interface correctly.
If the driver is configured in monitor mode (or whatever you would call
a mode where it receives all frames), I do expect to see ACK and RTS/CTS
frames in mac80211 (and in the monitor interface in user space for that
matter). I hope that this won't be changed.

It sounds perfectly reasonable to not indicate these control frame
subtypes when in normal (non-monitor) mode since they are most likely
processed in hardware/microcode/firmware. However, if they provide
additional information (say, signal strength), it could be useful to
send them to mac80211 anyway to provide more information for TX rate
control.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]


> I'm not sure I understood the comment about monitor interface correctly.
> If the driver is configured in monitor mode (or whatever you would call
> a mode where it receives all frames), I do expect to see ACK and RTS/CTS
> frames in mac80211 (and in the monitor interface in user space for that
> matter). I hope that this won't be changed.

We're talking about a virtual monitor interface that is in use while
we're also operating on another virtual interface.

> It sounds perfectly reasonable to not indicate these control frame
> subtypes when in normal (non-monitor) mode since they are most likely
> processed in hardware/microcode/firmware. However, if they provide
> additional information (say, signal strength), it could be useful to
> send them to mac80211 anyway to provide more information for TX rate
> control.

Again, we're only talking about frames we *sent*. There's a flag whether
to pass up control frames or not though which can be set in monitor
mode.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: tx_status reporting of RTS/CTS frames

[Ivo van Doorn]

Hi,

> > rt2x00 devices can't generate rts/cts frames themselves, but rely on the
> > driver to generate them. Also, the hardware reports tx status back for
> > those frames. Now the question is whether these frames should be
> > reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
> > this has some subtle effects, e.g. they won't show up on monitor
> > interfaces if we don't report them.
> 
> They never show up on monitor interfaces for all other hardware because
> there the hardware handles them. How is it that rt2x00 cannot handle
> rts? It has to at least know that an RTS was sent and to send the frame
> only after the CTS, and that needs to be a MAC function and cannot be
> implemented in host software.
> 
> So, I'd think they shouldn't be reported at all.

Than this is a problem in multiple mac80211 drivers, since rt2x00 previously
did filter out rts and cts frames when reporting txdone events to mac80211
and upon request on the linux-wireless list that filter was disabled, because
the other drivers didn't filter the RTS/CTS frames so for consistent behavior
the filter was removed from rt2x00.

Ivo

Re: tx_status reporting of RTS/CTS frames

[Ivo van Doorn]

On Thursday 13 December 2007, Mattias Nissler wrote:
> 
> On Thu, 2007-12-13 at 12:34 +0100, Johannes Berg wrote:
> > > rt2x00 devices have some flags in the TX descriptor that basically tell
> > > the device to send a burst of frames, optionally requesting to wait for
> > > an ack (i.e. CTS in the case of an RTS frame) for any of them.
> > 
> > Interesting. I can't the place where that is set though, can you point
> > me to it?
> 
> For each frame, rt2x00 creates a txdata_entry_desc structure (see
> rt2x00lib_write_tx_desc()), which holds all the information that is
> written to the actual tx descriptors (format of these varies among the
> different devices we support, but the information in the tx descriptors
> is roughly the same). See rt61pci_write_tx_desc() for an example of how
> the information is stored into the actual tx descriptor, but that's
> rather boring.
> 
> The bits you're interested in are ENTRY_TXD_ACK and ENTRY_TXD_BURST.
> BURST tells the device the next frame is part of the same burst (also
> note that we have to set the correct IFS), i.e. the next frame goes out
> directly after the current one (respecting the IFS of course). The
> TXD_ACK bit means the hardware should wait for an ack of some kind (e.g.
> CTS for RTS frames).

Additionally there is the ENTRY_TXD_RTS_FRAME flag to indicate the frame
is a rts frame. This is something that at least rt2400pci and rt2500pci required
for rts frames in the TX queue.

Ivo

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]


> Than this is a problem in multiple mac80211 drivers, since rt2x00 previously
> did filter out rts and cts frames when reporting txdone events to mac80211
> and upon request on the linux-wireless list that filter was disabled, because
> the other drivers didn't filter the RTS/CTS frames so for consistent behavior
> the filter was removed from rt2x00.

Huh? Seriously? I can't remember any such thing. It doesn't really make
sense because most hw will handle rts/cts fully transparently and not
give you status notification for it. As for showing received rts/cts on
monitor, sure, but txdone for sent rts/cts isn't done by any driver I'm
aware of.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: tx_status reporting of RTS/CTS frames

[Ivo van Doorn]

Hi,

> > Than this is a problem in multiple mac80211 drivers, since rt2x00 previously
> > did filter out rts and cts frames when reporting txdone events to mac80211
> > and upon request on the linux-wireless list that filter was disabled, because
> > the other drivers didn't filter the RTS/CTS frames so for consistent behavior
> > the filter was removed from rt2x00.
> 
> Huh? Seriously? I can't remember any such thing. It doesn't really make
> sense because most hw will handle rts/cts fully transparently and not
> give you status notification for it. As for showing received rts/cts on
> monitor, sure, but txdone for sent rts/cts isn't done by any driver I'm
> aware of.

I just checked, only rt2x00 and b43 call the rts/cts functions for ieee80211.
For b43 seems to report the tx status for the rts/cts frames as well.

I have found the 2 emails that introduced and later reverted the behavior from rt2x00:
[PATCH 16/26] rt2x00: Correctly handle RTS frames
[PATCH 7/24] RT2x00: Add RTS frame creation
They are dated from July 2006, so they were quite old actually :S

Anyway, I have no objects against not report those frames to mac80211,
so if mac80211 doesn't want those frames reported rt2x00 can filter them out. :)

Ivo

Re: tx_status reporting of RTS/CTS frames

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Hi Ivo,

> I just checked, only rt2x00 and b43 call the rts/cts functions for ieee80211.
> For b43 seems to report the tx status for the rts/cts frames as well.

b43 definitely doesn't, it embeds the rts/cts frame in the TX descriptor
of the data packet and only gets a tx status notification for the data
packet from the hardware.

> I have found the 2 emails that introduced and later reverted the behavior from rt2x00:
> [PATCH 16/26] rt2x00: Correctly handle RTS frames
> [PATCH 7/24] RT2x00: Add RTS frame creation
> They are dated from July 2006, so they were quite old actually :S

:)

> Anyway, I have no objects against not report those frames to mac80211,
> so if mac80211 doesn't want those frames reported rt2x00 can filter them out. :)

I think it'd be best since most hw is not even capable of doing it, rate
control algorithms don't care and we don't really want to have them
anyway.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]