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

[Mattias Nissler <mattias.nissler@gmx.de>]

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.

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