From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless <linux-wireless@vger.kernel.org>
Cc: Jouni Malinen <j@w1.fi>, Tomas Winkler <tomasw@gmail.com>
Subject: mac80211 and QoS support
Date: Thu, 20 Sep 2007 11:57:53 +0200 [thread overview]
Message-ID: <1190282273.18521.31.camel@johannes.berg> (raw)
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]
Hey,
After looking again into why we were sending frames with invalid QoS
control fields under certain circumstances it occurred to me that this
would only happen when CONFIG_NET_SCHED was not set.
That, however, seems wrong: when CONFIG_NET_SCHED is unset we really are
behaving as a non-QoS STA. However, even if it is set we never announce
our QoS capability, hostapd will never set the QoS capability field in a
beacon and neither will we set in our capability information in
(re)association requests.
On the other hand, in both cases we will start sending QoS frames if the
other side has announced support for it in their capability information.
It seems to me that this violates the mandated behaviour if we're an AP
in that we force a QoS-capable STA to behave as a QoS STA although it is
associated to a non-QoS BSS and thus should expect to work as a non-QoS
STA.
It seems to me that we should introduce a new per-interface (where VLAN
interfaces use the AP setting) "QoS enabled" setting that wpa_supplicant
(when acting as MLME) or hostapd set. For the in-kernel-MLME, I would
suggest to force it to be off. Enabling QoS would be disallowed when
CONFIG_NET_SCHED is unset or when we have only one hardware queue. It
should then behave like the 802.11 option "dot11QosOptionImplemented",
but consistency wouldn't be enforced (i.e. hostapd sets this option so
it is also required to set the QoS capability flag and insert the EDCA
parameter set or QOS capability IE)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
reply other threads:[~2007-09-20 13:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1190282273.18521.31.camel@johannes.berg \
--to=johannes@sipsolutions.net \
--cc=j@w1.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=tomasw@gmail.com \
/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