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