Re: ACK matching [was: TX status reporting with help of an ack queue]

["Mikko Virkkilä" <mikko.virkkila@bluegiga.com>]

On Fri, 2008-09-19 at 15:51 +0200, Mattias Nissler wrote:
> On Fri, 2008-09-19 at 12:31 +0200, Johannes Berg wrote:
> > On Fri, 2008-09-19 at 12:19 +0200, Mattias Nissler wrote:
> > 
> > > Well, maybe we can work around this requirement? I still need to learn
> > > about the details, but what happens for example if the STA sends the ACK
> > > and then resets due to a crash? I guess the AP is able to cope with
> > > that, no? So maybe we can relax the rules a bit (unless we become really
> > > incompliant with the standard of course).
> > 
> > I don't really see how to. We can't just assume the station got the
> > frame properly and advance our state machine. The case you're citing is
> > quite different, we'll advance the state machine but it won't work
> > because the STA crashed; if we advance but the station simply hasn't
> > gotten the frame we'll get out of sync and stuff will fail for no real
> > reason.
> 
> Well, I understand that we need synchronization of the state machines,
> maybe we can advance optimistically and detect in the next state that
> the STA didn't receive the last message? Just some random thoughts, I
> see it'll at least be tricky, I just wanted your opinion on whether you
> see a chance :-) As I said, I'll look into it when I find some time.
> 

Just as a side note: it's the mac80211 stack which converts a missing
TX_ACK flag to be a IEEE80211_RADIOTAP_F_TX_FAIL flag. The hostapd sees
that TX_FAIL and assumes TX failed.

> > 
> > But you can do workarounds all you want in hostapd, I don't care.
> 
> :-)
> 
> > However, I do think that if the hardware just isn't up to the job you
> > should probably buy new hardware, after all, it's dirt cheap. :)
> 
> I totally agree with you. I'm just curious to see whether there is a
> chance to help our users. I'm perfectly fine if it turns out there is no
> chance to do it properly, and I'll rather accept that fact instead of
> trying to introduce workarounds that are known to be incorrect. The sad
> thing is that if we controlled the firmware, we could probably arrange
> to have the necessary information passed to the driver.
> 
> Mattias
> 

I'd really love for some workaround that would allow AP mode to work. 

It would be great if it could be deemed that the protocol doesn't really
require CTS protection/status information, and can be made reliable and
standards compliant without support for it from the driver.
Unfortunately I don't have high hopes for that, but I wonder what's Mr.
Malinen's opinion?

- Mikko