Hi everyone!
the following intentionally-broken patch outlines the current state of
things in my nl80211 hacking branch. Comments, extensions and feedback
more than welcome.
Human-readable summary:
- struct ieee80211_channel:
use (phymode, channel, 80211n-mode) as "key"; kill off frequency
(which will move to some get_channel_foobar function)
- cfg80211: make API more complete:
- add channel get/set/chanlist;
- those are using struct ieee80211_channel
- channel listing works by providing a callback to the driver, which
iterates then.
- add get interface type.
- nl80211: seriously extend API
- wiphy listing now works via dumping; serves for listing and getting
current config (including channel, phymode, list of virtual interfaces)
- add channel get/set/chanlist
- chanlist exports freq & maxpower from kernel, too
(solves 20 userspace apps implementing 50 frequency tables)
- getting virtual interfaces works via ifindex, which needs to be known.
- no dumping (would have locking issues with userspace MLME)
- use list of vifs from GET_WIPHY
- only thing it currently should return is vif type. essid & stuff
should be retrievable via GET_ASSOCIATION, which won't be valid for
monitor interfaces
So, what's left?
- more PHY config stuff?
- TX power? Should be able to configure a lower value...
- antenna selection?
- Atheros "Turbo" modes - are those useful to add as phymodes or as
attributes?
- more stuff I forgot.
As for implementation, my hacking tree has a working "proof of concept" for
configuring the phy over nl80211. However, especially the regulatory stuff
will require a reworking of it, and reconfiguring the channel doesn't
produce a notification yet, either. (Configuring something via wext should
trigger that notification too, so hopefully the split-out of the regulatory
stuff will allow adding a central notification call too).
Anyway, for the appetite:
# iw link; iw phy chanlist phy0 channel 3
0: phy0: <RENAME,SETCHANNEL,CHANLIST,ADDVIF> mode 802.11g channel 1
10: wlan0: <DELVIF> type managed
9: wmaster0: <DELVIF> type ap
0: phy0: channel 3 mode 802.11g # 54M 2.422 GHz
0: phy0: channel 3 mode 802.11b # 11M 2.422 GHz
# iw phy set phy0 channel 3 mode b; iw phy
0: phy0: <RENAME,SETCHANNEL,CHANLIST,ADDVIF> mode 802.11b channel 3
Hoping for feedback, and to reach a preliminary API consent soon,
-David
---
include/linux/nl80211.h | 41 +++++++++++++++++++++++++++++------------
include/net/cfg80211.h | 13 +++++++++++++
include/net/ieee80211.h | 21 +++++++++++++++++----
3 files changed, 59 insertions(+), 16 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index cef969c..02094a7 100644
-%-- a/include/linux/nl80211.h
+%++ b/include/linux/nl80211.h
@@ -9,9 +9,17 @@
/**
* enum nl80211_commands - supported nl80211 commands
* @NL80211_CMD_UNSPEC: unspecified command to catch errors
+ * @NL80211_CMD_GET_WIPHY: request a wiphy or dump request to get a list.
+ * @NL80211_CMD_NEW_WIPHY: returned list of all wiphys. Has attributes
+ * corresponding to the PHY's configuration capabilities. Has at least
+ * %NL80211_ATTR_WIPHY and %NL80211_ATTR_WIPHY_NAME
* @NL80211_CMD_RENAME_WIPHY: rename a wiphy, needs
* %NL80211_ATTR_WIPHY and %NL80211_ATTR_WIPHY_NAME
* @NL80211_CMD_WIPHY_NEWNAME: rename notification
+ * @NL80211_CMD_SET_CHANNEL: configure a PHY.
+ * @NL80211_CMD_NEW_CHANNEL: reconfiguration notification.
+ * @NL80211_CMD_GET_CHANLIST: TBA
+ * @NL80211_CMD_NEW_CHANLIST: TBA
* @NL80211_CMD_GET_CMDLIST: TO BE DEFINED PROPERLY. currently the code makes
* it depend on the wiphy only but it really should depend on the
* interface type too....
@@ -24,12 +32,12 @@
* @NL80211_CMD_CHANGE_VIRTUAL_INTERFACE: change type of virtual interface to
* the type given by %NL80211_ATTR_IFTYPE, the interface is identified by
* %NL80211_ATTR_IFINDEX.
- * @NL80211_CMD_GET_WIPHYS: request a list of all wiphys present in the system
- * @NL80211_CMD_NEW_WIPHYS: returned list of all wiphys
- * @NL80211_CMD_GET_INTERFACES: request a list of all interfaces belonging to
- * the wiphy identified by %NL80211_ATTR_WIPHY
- * @NL80211_CMD_NEW_INTERFACES: result for %NL80211_CMD_GET_INTERFACES
- * @NL80211_CMD_INITIATE_SCAN: initiate a scan with the passed parameters. THe
+ * @NL80211_CMD_GET_INTERFACE: request an interface's configuration.
+ * pass a %NL80211_ATTR_IFINDEX, get below reply.
+ * @NL80211_CMD_NEW_INTERFACE: result for %NL80211_CMD_GET_INTERFACES.
+ * Has %NL80211_ATTR_WIPHY, %NL80211_ATTR_IFINDEX and
+ * %NL80211_ATTR_IFTYPE attributes.
+ * @NL80211_CMD_INITIATE_SCAN: initiate a scan with the passed parameters. The
* parameters may contain %NL80211_ATTR_FLAG_SCAN_ACTIVE,
* %NL80211_ATTR_PHYMODE and a list of channels in an
* %NL80211_ATTR_CHANNEL_LIST attribute (an array of nested attributes)
@@ -52,9 +60,17 @@
enum nl80211_commands {
/* don't change the order or add anything inbetween, this is ABI! */
NL80211_CMD_UNSPEC,
+ /* %input: */
+ NL80211_CMD_GET_WIPHY, /* may dump req */
+ NL80211_CMD_NEW_WIPHY,
/* %input: wiphy, wiphy_name */
NL80211_CMD_RENAME_WIPHY,
NL80211_CMD_WIPHY_NEWNAME,
+ /* %input: wiphy */
+ NL80211_CMD_SET_CHANNEL,
+ NL80211_CMD_NEW_CHANNEL,
+ NL80211_CMD_GET_CHANLIST,
+ NL80211_CMD_NEW_CHANLIST,
/* %input: wiphy|ifindex */
NL80211_CMD_GET_CMDLIST,
NL80211_CMD_NEW_CMDLIST,
@@ -64,12 +80,9 @@ enum nl80211_commands {
NL80211_CMD_DEL_VIRTUAL_INTERFACE,
/* %input: ifindex, iftype */
NL80211_CMD_CHANGE_VIRTUAL_INTERFACE,
- /* %input: */
- NL80211_CMD_GET_WIPHYS,
- NL80211_CMD_NEW_WIPHYS,
/* %input: wiphy */
- NL80211_CMD_GET_INTERFACES,
- NL80211_CMD_NEW_INTERFACES,
+ NL80211_CMD_GET_INTERFACE, /* may dump req */
+ NL80211_CMD_NEW_INTERFACE,
NL80211_CMD_INITIATE_SCAN,
NL80211_CMD_SCAN_RESULT,
NL80211_CMD_GET_ASSOCIATION,
@@ -151,11 +164,15 @@ enum nl80211_attrs {
/* %type: u32 */
NL80211_ATTR_IFTYPE,
NL80211_ATTR_INTERFACE_LIST,
- NL80211_ATTR_WIPHY_LIST,
NL80211_ATTR_BSSID,
NL80211_ATTR_SSID,
NL80211_ATTR_CHANNEL,
NL80211_ATTR_PHYMODE,
+ NL80211_ATTR_11N_MODE,
+ /* the following two are ONLY for channel list: */
+ NL80211_ATTR_FREQ,
+ NL80211_ATTR_MAXPOWER,
+ /* ^ ^ ^ */
NL80211_ATTR_CHANNEL_LIST,
NL80211_ATTR_BSS_LIST,
NL80211_ATTR_BSSTYPE,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1398c21..efdd8b4 100644
-%-- a/include/net/cfg80211.h
+%++ b/include/net/cfg80211.h
@@ -78,6 +78,10 @@ struct key_params {
/* from net/wireless.h */
struct wiphy;
+/* callback to be called by driver to give nl80211 a channel list */
+typedef int (*cfg80211_chanlist_cb)(void *arg,
+ struct ieee80211_channel *channel);
+
/**
* struct cfg80211_ops - backend description for wireless configuration
*
@@ -121,6 +125,15 @@ struct cfg80211_ops {
int (*del_virtual_intf)(struct wiphy *wiphy, int ifindex);
int (*change_virtual_intf)(struct wiphy *wiphy, int ifindex,
enum nl80211_iftype type);
+ int (*get_virtual_intf)(struct wiphy *wiphy, int ifindex,
+ enum nl80211_iftype *type);
+
+ int (*get_channel)(struct wiphy *wiphy,
+ struct ieee80211_channel *channel);
+ int (*set_channel)(struct wiphy *wiphy, int chan,
+ struct ieee80211_channel *channel);
+ int (*get_chanlist)(struct wiphy *wiphy, cfg80211_chanlist_cb cb,
+ void *arg);
int (*associate)(struct wiphy *wiphy, struct net_device *dev,
struct association_params *params);
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index bbd85cd..148ed90 100644
-%-- a/include/net/ieee80211.h
+%++ b/include/net/ieee80211.h
@@ -28,6 +28,7 @@
#include <linux/if_ether.h> /* ETH_ALEN */
#include <linux/kernel.h> /* ARRAY_SIZE */
#include <linux/wireless.h>
+#include <linux/nl80211.h>
#define IEEE80211_VERSION "git-1.1.13"
@@ -973,7 +974,7 @@ enum ieee80211_state {
#define IEEE80211_52GHZ_CHANNELS (IEEE80211_52GHZ_MAX_CHANNEL - \
IEEE80211_52GHZ_MIN_CHANNEL + 1)
-enum {
+enum ieee80211_channel_flags {
IEEE80211_CH_PASSIVE_ONLY = (1 << 0),
IEEE80211_CH_80211H_RULES = (1 << 1),
IEEE80211_CH_B_ONLY = (1 << 2),
@@ -983,10 +984,22 @@ enum {
IEEE80211_CH_INVALID = (1 << 6),
};
+enum ieee80211n_subchannel {
+ IEEE80211N_SUBCH_LEGACY, /* 20 MHz 11a/g compat */
+ IEEE80211N_SUBCH_LEGACY_DUP, /* 2x20 MHz, same data */
+ IEEE80211N_SUBCH_NATIVE, /* 40 MHz native */
+ IEEE80211N_SUBCH_LOWER, /* lower 20MHz, legacy & native */
+ IEEE80211N_SUBCH_UPPER, /* upper 20MHz, legacy & native */
+};
+
struct ieee80211_channel {
- u32 freq; /* in MHz */
- u8 channel;
- u8 flags;
+ /* configurable: */
+ enum nl80211_phymode phymode;
+ u16 channel;
+ enum ieee80211_subchannel n_subch;
+
+ /* fixed: */
+ enum ieee80211_channel_flags flags;
u8 max_power; /* in dBm */
};
--
1.5.2.1
> > Shouldn't wpa_supplicant know when the connection is ready?
> > It has support for dormant mode, so the link can be held down
> > by userspace until it is ready.
> > The driver shouldn't need to figure out when the link is
> > ready to go up.
>
> 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.
I don't know too much about WPA, so, er... is it possible for a device to
have a set of keys configured and still not be operational?
Basing operational state on a sequence of set-key operations is obviously
weird, but basing it on having a full set of keys might actually be right,
IF and only IF those two statements are equivalent, so - are they?
-David
P.S.: anyone got some WPA doc/spec pointer for me?
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
Hi,
> - struct ieee80211_channel:
> use (phymode, channel, 80211n-mode) as "key"; kill off frequency
> (which will move to some get_channel_foobar function)
Hmm. Maybe we should've kept frequency. How do we want to handle
dot11ChannelStartingFactor (see 17.3.8.3.2 Channel numbering in
802.11j), I quote:
Change the text of 17.3.8.3.2 as follows:
Channel center frequencies are defined at every integral multiple of 5 MHz above Channel starting
frequency. The relationship between center frequency and channel number is given by Equation (27):
Channel center frequency = Channel starting frequency + (nch × 5) (MHz) (27)
where
is 0,1,... 200,
nch
Channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz or
is defined as 5 GHz for systems where dot11RegulatoryClassesRequired is
false or not defined.
For example, dot11ChannelStartingFactor = 10 000 indicates that Channel
zero center frequency is 5.000 GHz. The value NULL for nch shall be
reserved, and a channel center frequency of 5.000 GHz shall be indicated by
dot11ChannelStartingFactor = 8000 and nch = 200. An SME managing
multiple channel sets can change the channel set being managed by changing
the value of dot11ChannelStartingFactor.
johannes
Hi David,
Great stuff!
> - getting virtual interfaces works via ifindex, which needs to be known..
> - no dumping (would have locking issues with userspace MLME)
> - use list of vifs from GET_WIPHY
> - only thing it currently should return is vif type. essid & stuff
> should be retrievable via GET_ASSOCIATION, which won't be valid for
> monitor interfaces
Hmm, in fact, if we go that route then we can do dumping for vifs (by
wiphy I guess) since all this information is available in the kernel,
only GET_ASSOCIATION should need a callout. vif type can be dumped just
fine.
> So, what's left?
> - more PHY config stuff?
> - TX power? Should be able to configure a lower value...
Yeah, but as we said, this really needs to tie in with any regulatory
stuff.
> - antenna selection?
Sounds reasonable, needs automatic/... but for .11n it might need some
more things. Not sure.
johannes
> - antenna selection?
not only antenna, but also antenna diversity
On 6/12/07, Dan Williams <[email protected]> wrote:
> On Tue, 2007-06-12 at 11:15 +0200, Johannes Berg wrote:
> > Hi David,
> >
> > Great stuff!
> >
> > > - getting virtual interfaces works via ifindex, which needs to be known.
> > > - no dumping (would have locking issues with userspace MLME)
> > > - use list of vifs from GET_WIPHY
> > > - only thing it currently should return is vif type. essid & stuff
> > > should be retrievable via GET_ASSOCIATION, which won't be valid for
> > > monitor interfaces
> >
> > Hmm, in fact, if we go that route then we can do dumping for vifs (by
> > wiphy I guess) since all this information is available in the kernel,
> > only GET_ASSOCIATION should need a callout. vif type can be dumped just
> > fine.
> >
> > > So, what's left?
> > > - more PHY config stuff?
> > > - TX power? Should be able to configure a lower value...
> >
> > Yeah, but as we said, this really needs to tie in with any regulatory
> > stuff.
> >
> > > - antenna selection?
> >
> > Sounds reasonable, needs automatic/... but for .11n it might need some
> > more things. Not sure.
>
> Just a quick question; for .11n and later, do we care about being as
> detailed as specifying each antenna and whether or not each antenna can
> be used for TX and/or RX, and then being able to assign specific
> antennas to either TX or RX? Or does hardware expose a simpler
> interface like "2x2" or "3x2"? That means either:
>
> set-antennas([(1, TX & RX), (2, TX & RX), (3, RX)])
>
> or
>
> set-antennas(tx=2, rx=3)
>
> Dan
>
>
You can be explicit and then it's port of hand shake, Yet antenna
selection/number is part of rate index (MCS) and there it is chosen by
rate scaling alorithm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, 2007-06-12 at 18:01 +0100, 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.
Is that really something the driver needs to handle? I see controlled
port operation in mac80211 but I didn't dig yet why it is necessary. As
Michael points out, shouldn't it be possible to handle it entirely from
userland? What userland are you using that needs the driver doing it?
Of course, there's the question of whether to accept packets anyway or
not, I think that's what the 8021x setting in mac80211 does. Not sure.
johannes
> > - struct ieee80211_channel:
> > use (phymode, channel, 80211n-mode) as "key"; kill off frequency
> > (which will move to some get_channel_foobar function)
>=20
> Hmm. Maybe we should've kept frequency. How do we want to handle
> dot11ChannelStartingFactor (see 17.3.8.3.2 Channel numbering in
> 802.11j), I quote:
>=20
> Change the text of 17.3.8.3.2 as follows:
> Channel center frequencies are defined at every integral multiple of =
5 MHz above Channel starting
> frequency. The relationship between center frequency and channel numb=
er is given by Equation (27):
>=20
> Channel center frequency =3D Channel starting frequency + (nch =C3=
=97 5) (MHz) (27)
>=20
(nl80211 part:)
Well, I would handle it exactly like that. Keep channel numbers, add
channel starting frequency as configurable (regulatory?) parameter for =
the
device.
The mapping between channel numbers an frequencies, while for most case=
s
fixed, can't be assumed to be so under all circumstances. Applications
should use CMD_GET_CHANLIST to get a list of stuff supported. If the de=
vice
is configured to use 11j 4.9GHz band, that list might for example conta=
in:
mode=3D80211A channel=3D184 # frequency=3D4920
mode=3D80211A10 channel=3D184 # frequency=3D4920
mode=3D80211A10 channel=3D186 # frequency=3D4930
(no idea whether that channel exists, example pulled from hot air using
channel start =3D 4000M)
(cfg80211 part:)
Now the real question is how to handle that inside the kernel... you're
right, unless we introduce a channel_to_freq function which takes both
the channel structure *and* the base frequency as parameters, we need t=
o
have the frequency in struct ieee80211_channel.
Anyone feel like elaborating (dis)advantages of those two? Drivers migh=
t
actually be setting their RF using the channel value, having a non-matc=
hing
freq might confuse things... OTOH, having the final frequency is nice
too... this requires some thought :/.
=2E.. since for most devices there is a fixed (phymode)->(channel_start=
)
mapping, I'm tempted to say "have channel_start be a mode parameter" fo=
r
now.
Anyway, 802.11j needs configurable channel *width* too (10M/20M). I'd a=
dd
it as "80211A10" phymode; that wouldn't require any new API or stuff. A=
nd
for setting the channel starting frequency, the regulatory API might bo=
th
make sense and be the closest thing related.
(btw, I think we should multicast NL80211_CMD_NEW_CHANLIST notification=
s
on regulatory updates).
-David
P.S.: Just for fun, we could actually have the set_channel part work on
802.16 (WiMAX) devices too :) - we only need to return an appropriate
channel list, define a phymode value and *poof* universal channel switc=
her
:)
P.P.S.: Just joking.
Hi,
just for fun, I created a graph of wext->nl80211 mappings:
http://git.spaceboyz.net/?p=nl80211/nl80211-meta.git;a=blob_plain;f=nl80211-map.png;hb=865687f294a84d7847ed7a05aa63de5cbb1a0c89
- wext stuff marked red means I have no idea what that ioctl does
- lines marked blue mean I'm not sure whether that's correct
- nl80211 cmds in lowercase and light green aren't outlined yet
So, what's left?
> - more PHY config stuff?
> - TX power? Should be able to configure a lower value...
> - antenna selection?
- antenna diversity, as noted by Holger Schurig
- the entire regulatory stuff
For this, my first idea (included in that graph) would be to have a
GET_REGULATORY_CAPS command which returns whether the device has a fixed
list of regdomains or whether it can load anything. Depending on that,
either SELECT_REGDOMAIN or SET_CHANLIST can be used. For the chanlist,
there would be additional attributes specifying stuff like max power,
active scanning, etc.
Other new:
- {get,set}{mac,radio} for tx power (within regulatory limits), retry
stuff, antennas?, etc.
What I totally missed is that there also is no rate configuration command
yet (!). Do we want that in SET_CHANNEL? (and rename it to SET_PHY?)
-David
On Tue, 2007-06-12 at 11:15 +0200, Johannes Berg wrote:
> Hi David,
>
> Great stuff!
>
> > - getting virtual interfaces works via ifindex, which needs to be known.
> > - no dumping (would have locking issues with userspace MLME)
> > - use list of vifs from GET_WIPHY
> > - only thing it currently should return is vif type. essid & stuff
> > should be retrievable via GET_ASSOCIATION, which won't be valid for
> > monitor interfaces
>
> Hmm, in fact, if we go that route then we can do dumping for vifs (by
> wiphy I guess) since all this information is available in the kernel,
> only GET_ASSOCIATION should need a callout. vif type can be dumped just
> fine.
>
> > So, what's left?
> > - more PHY config stuff?
> > - TX power? Should be able to configure a lower value...
>
> Yeah, but as we said, this really needs to tie in with any regulatory
> stuff.
>
> > - antenna selection?
>
> Sounds reasonable, needs automatic/... but for .11n it might need some
> more things. Not sure.
Just a quick question; for .11n and later, do we care about being as
detailed as specifying each antenna and whether or not each antenna can
be used for TX and/or RX, and then being able to assign specific
antennas to either TX or RX? Or does hardware expose a simpler
interface like "2x2" or "3x2"? That means either:
set-antennas([(1, TX & RX), (2, TX & RX), (3, RX)])
or
set-antennas(tx=2, rx=3)
Dan
David Lamparter wrote:
> Hi,
>
> just for fun, I created a graph of wext->nl80211 mappings:
> http://git.spaceboyz.net/?p=nl80211/nl80211-meta.git;a=blob_plain;f=nl
> 80211-map.png;hb=865687f294a84d7847ed7a05aa63de5cbb1a0c89
> - wext stuff marked red means I have no idea what that ioctl does
> - lines marked blue mean I'm not sure whether that's correct
> - nl80211 cmds in lowercase and light green aren't outlined yet
Very interesting. It raised a question in my mind...
When associating to a WPA network, at what point should the driver open
the controlled port?
With wext/wpa_supplicant, the driver relies on knowing that the
supplicant sets the pairwise key first and group key second and can open
the controlled port after the second key.
Can we tie down the correct behaviour more tightly in cfg80211/nl80211?
thanks
Mark
--
Mark Powell mailto:[email protected]
Group Leader, Host Drivers Tel: +44 (0)1223 692000
CSR, Business Park, Cowley Road, Cambridge, CB24 0WZ, UK
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
> -----Original Message-----
> From: Michael Wu [mailto:[email protected]]
> Sent: 12 June 2007 17:46
> To: Mark Powell
> Cc: David Lamparter; Johannes Berg; David Lamparter; Dan
> Williams; linux-wireless
> Subject: Re: [RFC] {cfg,nl}80211 API
>
> On Tuesday 12 June 2007 06:58, Mark Powell wrote:
> > Very interesting. It raised a question in my mind...
> > When associating to a WPA network, at what point should the driver
> > open the controlled port?
> > With wext/wpa_supplicant, the driver relies on knowing that the
> > supplicant sets the pairwise key first and group key second and can
> > open the controlled port after the second key.
> >
> > Can we tie down the correct behaviour more tightly in
> cfg80211/nl80211?
> >
> Shouldn't wpa_supplicant know when the connection is ready?
> It has support for dormant mode, so the link can be held down
> by userspace until it is ready.
> The driver shouldn't need to figure out when the link is
> ready to go up.
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.
Mark
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
On Tuesday 12 June 2007 06:58, Mark Powell wrote:
> Very interesting. It raised a question in my mind...
> When associating to a WPA network, at what point should the driver open
> the controlled port?
> With wext/wpa_supplicant, the driver relies on knowing that the
> supplicant sets the pairwise key first and group key second and can open
> the controlled port after the second key.
>
> Can we tie down the correct behaviour more tightly in cfg80211/nl80211?
>
Shouldn't wpa_supplicant know when the connection is ready? It has support for
dormant mode, so the link can be held down by userspace until it is ready.
The driver shouldn't need to figure out when the link is ready to go up.
-Michael Wu
