Re: IEEE80211 Acknowledgement

[Ivo van Doorn <ivdoorn@gmail.com>]

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