tx_status reporting of RTS/CTS frames
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
Hi,
Quoted 6 lines
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
Quoted 9 lines · Johannes Berg
Hi,
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 1 line
So, I'd think they shouldn't be reported at all.
Ok, I'll prepare a patch for rt2x00.
Mattias
Quoted 4 lines
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
Quoted 6 lines · Johannes Berg
Quoted 3 lines
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
Quoted 7 lines
The bits you're interested in are
ENTRY_TXD_ACKandENTRY_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). TheTXD_ACKbit 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
Quoted 17 lines · Mattias Nissler
Quoted 6 lines · Johannes Berg
Quoted 3 lines
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_descstructure (seert2x00lib_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). Seert61pci_write_tx_desc()for an example of how the information is stored into the actual tx descriptor, but that's rather boring.
Quoted 6 lines
The bits you're interested in are
ENTRY_TXD_ACKandENTRY_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). TheTXD_ACKbit 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
Quoted 7 lines · Johannes Berg
Quoted 6 lines
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.
Quoted 7 lines
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 6 lines
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.
Quoted 6 lines
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
Hi,
Quoted 7 lines
Quoted 6 lines
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.
Quoted 7 lines
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
Quoted 6 lines
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
Hi,
Quoted 11 lines
Quoted 5 lines
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
Hi Ivo,
Quoted 2 lines
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.
Quoted 4 lines
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
:)
Quoted 2 lines
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