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

[Mattias Nissler <mattias.nissler@gmx.de>]

On Tue, 2008-09-23 at 09:09 +0300, Mikko Virkkil=E4 wrote:
> On Fri, 2008-09-19 at 20:50 +0300, Jouni Malinen wrote:
> > Mikko Virkkil=E4 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 car=
e.
> >=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=
 the
> > best location for the workaround.
> >=20
> > >>> However, I do think that if the hardware just isn't up to the j=
ob 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 tha=
t
> > 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 w=
ork.=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 t=
hat
> > I'm interested in using TX status reporting to improve reliability =
of
> > connection setup, so its use is more likely to increase in the futu=
re.
> >=20
> > > It would be great if it could be deemed that the protocol doesn't=
 really
> > > require CTS protection/status information, and can be made reliab=
le 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 a=
n ACK
> > from the STA for a (re)association response frame with success stat=
us
> > (see IEEE Std 802.11-2007, 11.3.2.2). In order to be able to implem=
ent
> > 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
>=20
> Well, sounds like there are good reasons to keep investigating the
> possibility of fixing this a bit more properly in the driver.=20
>=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?

Unfortunately, ACK frames do not carry sequence numbers. Only managemen=
t
and control frames have them.

Mattias

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