From: Jouni Malinen <j@w1.fi>
To: "Mikko Virkkilä" <mikko.virkkila@bluegiga.com>
Cc: Mattias Nissler <mattias.nissler@gmx.de>,
Johannes Berg <johannes@sipsolutions.net>,
Ivo van Doorn <ivdoorn@gmail.com>,
rt2400-devel@lists.sourceforge.net,
"John W. Linville" <linville@tuxdriver.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
dsd@gentoo.org, kune@deine-taler.de, j@w1.fi
Subject: Re: ACK matching [was: TX status reporting with help of an ack queue]
Date: Fri, 19 Sep 2008 20:50:26 +0300 [thread overview]
Message-ID: <48D3E662.9050902@w1.fi> (raw)
In-Reply-To: <1221834033.22224.22.camel@virkkmi-linux>
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 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 y=
ou
>>> 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.=
=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.
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 rea=
lly
> require CTS protection/status information, and can be made reliable a=
nd
> standards compliant without support for it from the driver.
> Unfortunately I don't have high hopes for that, but I wonder what's M=
r.
> Malinen's opinion?
IEEE 802.11 association state in the AP is changed when receiving an AC=
K
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=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.
- Jouni
--
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
next prev parent reply other threads:[~2008-09-19 17:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1221494693.14102.22.camel@virkkmi-linux>
2008-09-15 17:11 ` [RFC][PATCH] TX status reporting with help of an ack queue Ivo van Doorn
2008-09-15 17:56 ` Mattias Nissler
2008-09-15 18:03 ` Johannes Berg
2008-09-15 19:00 ` Mattias Nissler
2008-09-15 19:21 ` Johannes Berg
2008-09-15 19:39 ` Mattias Nissler
2008-09-15 19:46 ` Johannes Berg
2008-09-15 20:20 ` Mattias Nissler
2008-09-15 20:33 ` Johannes Berg
2008-09-15 21:01 ` Mattias Nissler
2008-09-24 0:59 ` John W. Linville
2008-09-24 7:40 ` Mattias Nissler
2008-09-24 8:34 ` Johannes Berg
2008-09-15 21:28 ` Ivo van Doorn
2008-09-15 21:41 ` Mattias Nissler
2008-09-16 18:17 ` Ivo van Doorn
2008-09-17 23:08 ` Mattias Nissler
2008-09-16 6:24 ` Mikko Virkkilä
2008-09-16 4:58 ` Mikko Virkkilä
2008-09-16 18:18 ` Ivo van Doorn
2008-09-18 20:37 ` Mattias Nissler
2008-09-18 22:29 ` ACK matching [was: TX status reporting with help of an ack queue] Mattias Nissler
2008-09-19 9:08 ` Mikko Virkkilä
2008-09-19 9:46 ` Mattias Nissler
2008-09-19 9:54 ` Johannes Berg
2008-09-19 10:19 ` Mattias Nissler
2008-09-19 10:31 ` Johannes Berg
2008-09-19 13:51 ` Mattias Nissler
2008-09-19 13:55 ` Johannes Berg
2008-09-19 14:20 ` Mikko Virkkilä
2008-09-19 17:50 ` Jouni Malinen [this message]
2008-09-23 6:09 ` Mikko Virkkilä
2008-09-23 7:05 ` Mattias Nissler
2008-09-19 18:30 ` Ivo van Doorn
2008-10-19 5:49 ` Daniel Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D3E662.9050902@w1.fi \
--to=j@w1.fi \
--cc=dsd@gentoo.org \
--cc=ivdoorn@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kune@deine-taler.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mattias.nissler@gmx.de \
--cc=mikko.virkkila@bluegiga.com \
--cc=rt2400-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).