On Tue, 2008-09-23 at 09:09 +0300, Mikko Virkkilä wrote: > 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? Unfortunately, ACK frames do not carry sequence numbers. Only management and control frames have them. 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
