IEEE80211 Acknowledgement

IEEE80211 Acknowledgement

[Alexandre Becholey]

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

Re: IEEE80211 Acknowledgement

[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'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

Re: IEEE80211 Acknowledgement

[Johannes Berg]

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

On Mon, 2009-05-04 at 17:29 +0200, Ivo van Doorn wrote:
> 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

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

Re: IEEE80211 Acknowledgement

[Ivo van Doorn]

On Monday 04 May 2009, Johannes Berg wrote:
> On Mon, 2009-05-04 at 17:29 +0200, Ivo van Doorn wrote:
> > 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.

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

Re: IEEE80211 Acknowledgement

[Johannes Berg]

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

On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:

> 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

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

Re: IEEE80211 Acknowledgement

[Ivo van Doorn]

On Monday 04 May 2009, Johannes Berg wrote:
> On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
> 
> > 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.

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

Re: IEEE80211 Acknowledgement

[Johannes Berg]

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

On Mon, 2009-05-04 at 18:55 +0200, Ivo van Doorn wrote:
> On Monday 04 May 2009, Johannes Berg wrote:
> > On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
> > 
> > > 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.
> 
> 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

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

Re: IEEE80211 Acknowledgement

[Ivo van Doorn]

On Monday 04 May 2009, Johannes Berg wrote:
> On Mon, 2009-05-04 at 18:55 +0200, Ivo van Doorn wrote:
> > On Monday 04 May 2009, Johannes Berg wrote:
> > > On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
> > > 
> > > > 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.
> > 
> > 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...

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

Re: IEEE80211 Acknowledgement

[Alexandre Becholey]

Ivo van Doorn wrote:
> On Monday 04 May 2009, Johannes Berg wrote:
>   
>> On Mon, 2009-05-04 at 18:55 +0200, Ivo van Doorn wrote:
>>     
>>> On Monday 04 May 2009, Johannes Berg wrote:
>>>       
>>>> On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
>>>>
>>>>         
>>>>> 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.
>>>>         
>>> 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...
>>     
>
> 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

Re: IEEE80211 Acknowledgement

[Ivo van Doorn]

On Tuesday 05 May 2009, Alexandre Becholey wrote:
> Ivo van Doorn wrote:
> > On Monday 04 May 2009, Johannes Berg wrote:
> >   
> >> On Mon, 2009-05-04 at 18:55 +0200, Ivo van Doorn wrote:
> >>     
> >>> On Monday 04 May 2009, Johannes Berg wrote:
> >>>       
> >>>> On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
> >>>>
> >>>>         
> >>>>> 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.
> >>>>         
> >>> 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...
> >>     
> >
> > 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 :)

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