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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
