Re: ACK matching [was: TX status reporting with help of an ack queue]

["Mikko Virkkilä" <mikko.virkkila@bluegiga.com>]

On Fri, 2008-09-19 at 20:50 +0300, Jouni Malinen wrote:
> Mikko Virkkil=C3=A4 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.
>=20
> 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 t=
he
> best location for the workaround.
>=20
> >>> 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. :)
>=20
> 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?
>=20
> > I'd really love for some workaround that would allow AP mode to wor=
k.=20
>=20
> 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.
>=20
> 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 tha=
t
> 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=
=2E
>=20
> > It would be great if it could be deemed that the protocol doesn't r=
eally
> > 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?
>=20
> 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 implemen=
t
> this correctly, AP mode operation require the TX status callback to
> provide information for the ACK status of (re)association response
> frames.
>=20
> I would also like to see this status used to speed up recovery from=20
> 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.
>=20
> - Jouni

Well, sounds like there are good reasons to keep investigating the
possibility of fixing this a bit more properly in the driver.=20

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-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html