On Fri, 2008-09-19 at 20:50 +0300, Jouni Malinen wrote: > Mikko Virkkilä wrote: > > On Fri, 2008-09-19 at 15:51 +0200, Mattias Nissler wrote: > >> On Fri, 2008-09-19 at 12:31 +0200, Johannes Berg wrote: > >>> But you can do workarounds all you want in hostapd, I don't care. > > But I do care.. ;-) As such, I would change that to "you can do > workarounds in your copy of hostapd". And yes, this would likely be the > best location for the workaround. > > >>> 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 have never seen wlan design that does not report frame ACK status > properly for transmitted unicast frames. Is it absolutely clear that > that is indeed the case here or could we should be missing some > documentation explaining how this should be done? > > > I'd really love for some workaround that would allow AP mode to work. > > The workaround would be to make hostapd generate bogus TX callback > internally with claim for a successfully received ACK when sending > (re)association response. I'm not very keen on including such > functionality and certainly do not consider dropping the correct > behavior because of a broken hw design. > > If someone can come up with a clean patch that allows this to be > configured in hostapd.conf without affecting the default behavior, I > could consider applying the changes. However, please keep in mind that > I'm interested in using TX status reporting to improve reliability of > connection setup, so its use is more likely to increase in the future. > > > 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? > > IEEE 802.11 association state in the AP is changed when receiving an ACK > from the STA for a (re)association response frame with success status > (see IEEE Std 802.11-2007, 11.3.2.2). In order to be able to implement > this correctly, AP mode operation require the TX status callback to > provide information for the ACK status of (re)association response > frames. > > I would also like to see this status used to speed up recovery from > dropped EAPOL frames during IEEE 802.1X EAP authentication, 4-way > handshake and group handshake. In certain environments, this could > improve stability of connection establishment greatly. > > - Jouni Well, sounds like there are good reasons to keep investigating the possibility of fixing this a bit more properly in the driver. If we turn off the AUTO_TX_SEQ and/or TXD_W1_HW_SEQUENCE (what'as the difference?) and assigning sequence numbers manually, could we then match the ack-frame's sequence number to the ones we have sent? - 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
