From: Michael Wu <flamingice@sourmilk.net>
To: "Mark Powell" <Mark.Powell@csr.com>
Cc: "David Lamparter" <dl@diac24.net>,
"Johannes Berg" <johannes@sipsolutions.net>,
"David Lamparter" <lists@diac24.net>,
"Dan Williams" <dcbw@redhat.com>,
"linux-wireless" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] {cfg,nl}80211 API
Date: Tue, 12 Jun 2007 23:46:54 -0700 [thread overview]
Message-ID: <200706122346.59935.flamingice@sourmilk.net> (raw)
In-Reply-To: <F3555D2D288C3C4CBA0001C074188F119F8913@cameurexb01.EUROPE.ROOT.PRI>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Tuesday 12 June 2007 10:01, Mark Powell wrote:
> This is to do with the operation of the "Controlled Port" as specified
> by 802.1x, which is handled by the driver. When the key exchanges are
> complete and the link is secure, then data is allowed to flow. With
> wext, the driver has to guess when this state is reached, based on
> knowledge of how wpa_supplicant uses wext.
>
From Documentation/networking/operstates.txt:
However, an interface is not usable just because the admin enabled it
- ethernet requires to be plugged into the switch and, depending on
a site's networking policy and configuration, an 802.1X authentication
to be performed before user data can be transferred. Operational state
shows the ability of an interface to transmit this user data.
Thanks to 802.1X, userspace must be granted the possibility to
influence operational state. To accommodate this, operational state is
split into two parts: Two flags that can be set by the driver only, and
a RFC2863 compatible state that is derived from these flags, a policy,
and changeable from userspace under certain rules.
----
Dormant state allow userspace to control the state of an interface well enough
to do 802.1x properly, regardless of whether it is wired or wireless.
wpa_supplicant already uses this AFAIK. Drivers don't need to do anything.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-06-13 6:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 23:04 [RFC] {cfg,nl}80211 API David Lamparter
2007-06-12 9:15 ` Johannes Berg
2007-06-12 12:08 ` Dan Williams
2007-06-12 14:55 ` Tomas Winkler
2007-06-12 9:59 ` Holger Schurig
2007-06-12 13:15 ` David Lamparter
2007-06-12 13:58 ` Mark Powell
2007-06-12 16:45 ` Michael Wu
2007-06-12 17:01 ` Mark Powell
2007-06-13 6:46 ` Michael Wu [this message]
2007-06-13 13:25 ` David Lamparter
2007-06-13 16:08 ` Johannes Berg
2007-06-13 10:22 ` Johannes Berg
2007-06-13 13:18 ` [RFC] {cfg,nl}80211 API - 802.11j David Lamparter
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=200706122346.59935.flamingice@sourmilk.net \
--to=flamingice@sourmilk.net \
--cc=Mark.Powell@csr.com \
--cc=dcbw@redhat.com \
--cc=dl@diac24.net \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=lists@diac24.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