IEEE80211 Acknowledgement
Hi,
I'm trying to catch Acknowlegement frames in the mac80211, but I don't managed to. Thus I'm wondering if they follow another path than the frames that aren't control ones? First I grab the header from the skb:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
then I run tests on the frame control. I can see frames like probe request or association request (ieee80211_is_probe_req, ieee80211_is_assoc_req,...) but there are never any ack ones. I did this in functions __ieee80211_rx and ieee80211_rx_irqsafe in rx.c
I'm doing this with a ralink chip (rt73usb) on the wireless-testing kernel.
Alexandre Becholey
Hi,
Just as side information for other readers:
Alexandre is looking into the problem of rt2500usb/rt73usb and possibly other USB drivers, that they cannot report the ACK status of frames to mac80211 which is problematic for hostapd.
Quoted 3 lines
I'm trying to catch Acknowlegement frames in the mac80211, but I don't managed to. Thus I'm wondering if they follow another path than the frames that aren't control ones?
Have you made sure that mac80211 has called the configure_filter() callback function with the FIF_CONTROL flag enabled?
Ivo
Quoted 7 lines · Ivo van Doorn
Hi,
Just as side information for other readers:
Alexandre is looking into the problem of rt2500usb/rt73usb and possibly other USB drivers, that they cannot report the ACK status of frames to mac80211 which is problematic for hostapd.
I realise that this probably doesn't help and is tangential to the question being asked, but I do not think processing ACK frames in software is possible for this, since the software does not know which frame was transmitted, due to four queues being used, and retries etc.
johannes
Quoted 5 lines · Johannes Berg
Quoted 4 lines · Ivo van Doorn
Hi,
Just as side information for other readers:
Quoted 8 lines
Quoted 3 lines
Alexandre is looking into the problem of rt2500usb/rt73usb and possibly other USB drivers, that they cannot report the ACK status of frames to mac80211 which is problematic for hostapd.
I realise that this probably doesn't help and is tangential to the question being asked, but I do not think processing ACK frames in software is possible for this, since the software does not know which frame was transmitted, due to four queues being used, and retries etc.
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame was in the list and remove the frame from the list and generate a tx_status response indicating success.
Off course all frames must be checked for the timeout value as well to see if the frame wasn't send (in which case the tx_status event is send as well).
There shouldn't be a problem with multi-queue with this if the list of frames is put onto a single list instead of one list per queue.
As for the retries and other statistics, do we honestly care?
At the moment rt2500usb/rt73usb indicate the frame has not been acked
and set the retry value to 1. If we somehow can tell if the frame was send out or not, isn't that a step forward already? The retry value is needed for the rate algorithm, but it is receiving the same incorrect value now as well, so it wouldn't be a step backward in that perspective. ;)
Ivo
Quoted 7 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
^^^^^^^^^^^^^^^^^^^
Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
johannes
Quoted 7 lines · Johannes Berg
Quoted 5 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
Quoted 6 lines
Quoted 2 lines
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
^^^^^^^^^^^^^^^^^^^Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
Hmm, so would there be any alternatives of fixing this problem? Because it is quite hard to sell to people that rt2500usb/rt73usb don't support Master mode, while the legacy drivers (the closed source version) actually do support it, because they apparently don't care for the ACK status.
Ivo
Quoted 8 lines · Ivo van Doorn
Quoted 7 lines · Johannes Berg
Quoted 5 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
^^^^^^^^^^^^^^^^^^^Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
Hmm, so would there be any alternatives of fixing this problem?
The proper way of fixing this would be a firmware upgrade ;)
Working around it would be possible if the driver queued only a single frame to the hardware, when it knew the frame needed ACK status, and flushed all queues before that frame, so it knows exactly about the frame... This has HUGE overhead and performance impact though, and requires lots of work in mac80211 to not request status for every frame to start with.
Since this breaks hostapd operation quite significantly, and I don't see hostapd changing to accommodate this since that essentially breaks the ability to be spec compliant (I'm fairly certain some places require checking for ACK).
An easier way would be to fake a ACK reception in the driver for every frame...
johannes
Quoted 27 lines · Johannes Berg
Quoted 8 lines · Ivo van Doorn
Quoted 7 lines · Johannes Berg
Quoted 5 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
^^^^^^^^^^^^^^^^^^^Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
Hmm, so would there be any alternatives of fixing this problem?
The proper way of fixing this would be a firmware upgrade ;)
Working around it would be possible if the driver queued only a single frame to the hardware, when it knew the frame needed ACK status, and flushed all queues before that frame, so it knows exactly about the frame... This has HUGE overhead and performance impact though, and requires lots of work in mac80211 to not request status for every frame to start with.
Quoted 7 lines
Since this breaks hostapd operation quite significantly, and I don't see hostapd changing to accommodate this since that essentially breaks the ability to be spec compliant (I'm fairly certain some places require checking for ACK).
An easier way would be to fake a ACK reception in the driver for every frame...
Ok, well I'll go with this route then. Since firmware upgrades for older hardware like rt73usb sounds very unlikely. And for rt2500usb it is plain impossible (no firmware ;))
Alexandre: Well that seems to make your project a lot easier...
Ivo
Quoted 42 lines · Ivo van Doorn
Quoted 31 lines · Johannes Berg
Quoted 13 lines · Ivo van Doorn
Quoted 11 lines · Johannes Berg
Quoted 8 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
Quoted 7 lines
Quoted 5 lines
^^^^^^^^^^^^^^^^^^^Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
Hmm, so would there be any alternatives of fixing this problem?
The proper way of fixing this would be a firmware upgrade ;)
Working around it would be possible if the driver queued only a single frame to the hardware, when it knew the frame needed ACK status, and flushed all queues before that frame, so it knows exactly about the frame... This has HUGE overhead and performance impact though, and requires lots of work in mac80211 to not request status for every frame to start with.
Quoted 8 lines
Since this breaks hostapd operation quite significantly, and I don't see hostapd changing to accommodate this since that essentially breaks the ability to be spec compliant (I'm fairly certain some places require checking for ACK).
An easier way would be to fake a ACK reception in the driver for every frame...
Quoted 8 lines
Ok, well I'll go with this route then. Since firmware upgrades for older hardware like rt73usb sounds very unlikely. And for rt2500usb it is plain impossible (no firmware ;))
Alexandre: Well that seems to make your project a lot easier...
Ivo
Thanks for your answers! I'm gonna try it that way :)
Alexandre
Quoted 47 lines · Alexandre Becholey
Quoted 46 lines · Ivo van Doorn
Quoted 31 lines · Johannes Berg
Quoted 13 lines · Ivo van Doorn
Quoted 11 lines · Johannes Berg
Quoted 8 lines · Ivo van Doorn
Well I believe the idea would be that (I'll see if I can dig up a reference to the initial discussion about this feature on this list) the driver sets a flag that mac80211 needs to keep a list of all frames send out to the driver and listens for ACK's.
As soon as a ACK was passed from driver to mac80211 it could check if the corresponding frame
Quoted 7 lines
Quoted 5 lines
^^^^^^^^^^^^^^^^^^^Here's the problem. What I'm saying is that there's no way to knowing what the "corresponding frame" is.
Hmm, so would there be any alternatives of fixing this problem?
The proper way of fixing this would be a firmware upgrade ;)
Working around it would be possible if the driver queued only a single frame to the hardware, when it knew the frame needed ACK status, and flushed all queues before that frame, so it knows exactly about the frame... This has HUGE overhead and performance impact though, and requires lots of work in mac80211 to not request status for every frame to start with.
Quoted 8 lines
Since this breaks hostapd operation quite significantly, and I don't see hostapd changing to accommodate this since that essentially breaks the ability to be spec compliant (I'm fairly certain some places require checking for ACK).
An easier way would be to fake a ACK reception in the driver for every frame...
Ok, well I'll go with this route then. Since firmware upgrades for older hardware like rt73usb sounds very unlikely. And for rt2500usb it is plain impossible (no firmware ;))
Quoted 7 lines
Quoted 4 lines
Alexandre: Well that seems to make your project a lot easier...
Ivo
Thanks for your answers! I'm gonna try it that way :)
Just as a hint, please do not replace all instances of TXDONE_UNKNOWN with TXDONE_SUCCESS. I rather see the driver report TXDONE_UNKNOWN to rt2x00lib, and the decision to report that state as success should be done there.
Ivo