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