Remove ieee80211_privacy_mismatch() and associated variable
"privacy_enabled". It serves no purpose and breaks dynamic wep.
Signed-off-by: Volker Braun <[email protected]>
---
The patch is on top of Johannes' patches.
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b028cac..d13c06a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -278,7 +278,6 @@ struct ieee80211_if_sta {
unsigned long request;
struct sk_buff_head skb_queue;
- int privacy_enabled;
unsigned long last_probe;
#define IEEE80211_AUTH_ALG_OPEN BIT(0)
diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index b68da75..fbdd1d1 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -1955,23 +1955,7 @@ static int ieee80211_ioctl_siwauth(struct net_device *dev,
case IW_AUTH_CIPHER_GROUP:
case IW_AUTH_WPA_ENABLED:
case IW_AUTH_RX_UNENCRYPTED_EAPOL:
- break;
case IW_AUTH_KEY_MGMT:
- if (sdata->type != IEEE80211_IF_TYPE_STA)
- ret = -EINVAL;
- else {
- /*
- * What are the semantics in wext supposed to be?
- *
- * Don't bother figuring that out... It's wext after
- * all so figuring it out will most likely require a
- * moderate amount of clairvoyance.
- *
- * TODO: remove in favour of something well-defined
- * in cfg80211/nl80211.
- */
- sdata->u.sta.privacy_enabled = !!data->value;
- }
break;
case IW_AUTH_80211_AUTH_ALG:
if (sdata->type == IEEE80211_IF_TYPE_STA ||
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 9234183..f2cf4de 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1162,29 +1162,6 @@ void ieee80211_send_dls_teardown(struct net_device *dev,
}
-static int ieee80211_privacy_mismatch(struct net_device *dev,
- struct ieee80211_if_sta *ifsta)
-{
- struct ieee80211_sta_bss *bss;
- int res = 0;
-
- if (!ifsta || ifsta->privacy_enabled)
- return 0;
-
- bss = ieee80211_rx_bss_get(dev, ifsta->bssid);
- if (!bss)
- return 0;
-
- if (ieee80211_sta_wep_configured(dev) !=
- !!(bss->capability & WLAN_CAPABILITY_PRIVACY))
- res = 1;
-
- ieee80211_rx_bss_put(dev, bss);
-
- return res;
-}
-
-
static void ieee80211_associate(struct net_device *dev,
struct ieee80211_if_sta *ifsta)
{
@@ -1200,12 +1177,6 @@ static void ieee80211_associate(struct net_device *dev,
ifsta->state = IEEE80211_ASSOCIATE;
printk(KERN_DEBUG "%s: associate with AP " MAC_FMT "\n",
dev->name, MAC_ARG(ifsta->bssid));
- if (ieee80211_privacy_mismatch(dev, ifsta)) {
- printk(KERN_DEBUG "%s: mismatch in privacy configuration and "
- "mixed-cell disabled - abort association\n", dev->name);
- ifsta->state = IEEE80211_DISABLED;
- return;
- }
ieee80211_send_assoc(dev, ifsta);
@@ -2949,14 +2920,6 @@ void ieee80211_sta_work(struct work_struct *work)
ifsta->state);
break;
}
-
- if (ieee80211_privacy_mismatch(dev, ifsta)) {
- printk(KERN_DEBUG "%s: privacy configuration mismatch and "
- "mixed-cell disabled - disassociate\n", dev->name);
-
- ieee80211_send_disassoc(dev, ifsta, WLAN_REASON_UNSPECIFIED);
- ieee80211_set_disassoc(dev, ifsta, 0);
- }
}
On Wed, 2007-08-22 at 13:57 -0400, Volker Braun wrote:
> Thats PRISM2_PARAM_MIXED_CELL=1039, which you removed in your
> 023-remove-unused-ioctls-3.patch. If I revert that then I'm sure your
> iwpriv call would work around my problem.
Oh right, but I dropped that patch now that Jouni complained about it :)
> Note that I'm not in a mixed cell! iee80211_privacy_mismatch checks
> the
> wrong mismatch. In my case, the AP broadcasts privacy, but I do not
> (yet) have a WEP key.
So far I understand, that's exactly what happens with WPA as well.
> But really mixed cell support is about the AP
> _not_ broadcasting privacy, yet the user _having_ a WEP key
> configured.
Ah, so that's mixed cell. Had me wondering anyway :)
> So say we fix iee80211_privacy_mismatch in checking for the right
> mismatch only. Then everybody would be happy, except some poor soul on
> a
> mixed cell network who would probably never figure out how to enable
> mixed cell mode. Why do we hate him so much? ;-) There is no security
> implication in enabling mixed mode by default --- management frames
> stay
> unencrypted and data frames with privacy mismatch continue to be
> dropped.
That's true. However, I'm trying to figure out why wpa_supplicant
doesn't tell mac80211 it's doing key management in your case. The first
check in privacy_mismatch() should make it return 0 if wpa_supplicant
sets key management, which works fine with WPA. I'm wondering if there's
actually a bug in wpa_supplicant here.
> ------------------ snip --------------------------------
> Mixed Cells Mode
thanks for that, where did you get that from?
johannes
On Fri, Aug 17, 2007 at 11:00:18PM -0400, Volker Braun wrote:
> Remove ieee80211_privacy_mismatch() and associated variable
> "privacy_enabled". It serves no purpose and breaks dynamic wep.
I don't know what has happened here, but ieee80211_privacy_mismatch()
and being able to disable/enable mixed-cell operations was here for
purpose (to prevent associating with APs that have mismatching
configuration by default, but allowing this to be enabled if the target
network is known to use some of the virtual AP designs that would
otherwise cause problems). However, someone seems to have broken this
completely by removing the mixed_cell configuration option..
--
Jouni Malinen PGP id EFC895FA
On Thu, 2007-08-23 at 16:16 +0200, Johannes Berg wrote:
> However, I'm trying to figure out why wpa_supplicant
> doesn't tell mac80211 it's doing key management in your case.
Yes, I also looked quickly into wpa_supplicant but so far haven't found
out why the key management is not set. I'll try to debug that further...
> > ------------------ snip --------------------------------
> > Mixed Cells Mode
> thanks for that, where did you get that from?
I found it at Dell's support page:
http://www.support.dell.com/support/edocs/network/P94583/en/security.htm
On Fri, 2007-08-17 at 20:41 -0700, Jouni Malinen wrote:
> I don't know what has happened here, but ieee80211_privacy_mismatch()
> and being able to disable/enable mixed-cell operations was here for
> purpose
Volker, can you try
# iwpriv wlan0 param 1039 1
instead of this patch? Yep, that's the UI for enabling mixed cell as far
as I can tell. Great huh?...
johannes
On Fri, 2007-08-17 at 20:41 -0700, Jouni Malinen wrote:
> I don't know what has happened here, but ieee80211_privacy_mismatch()
> and being able to disable/enable mixed-cell operations was here for
> purpose (to prevent associating with APs that have mismatching
> configuration by default, but allowing this to be enabled if the target
> network is known to use some of the virtual AP designs that would
> otherwise cause problems).
Actually, that does work, but in the case Volker has apparently
wpa_supplicant fails to set the authentication method to 802.1X via
wireless extensions and thus he fails to be able to associate to the
network. For WPA, it correctly sets it so you can associate without
having keys.
johannes
On Wed, 2007-08-22 at 15:04 +0200, Johannes Berg wrote:
> Volker, can you try # iwpriv wlan0 param 1039 1
Thats PRISM2_PARAM_MIXED_CELL=1039, which you removed in your
023-remove-unused-ioctls-3.patch. If I revert that then I'm sure your
iwpriv call would work around my problem.
Note that I'm not in a mixed cell! iee80211_privacy_mismatch checks the
wrong mismatch. In my case, the AP broadcasts privacy, but I do not
(yet) have a WEP key. But really mixed cell support is about the AP
_not_ broadcasting privacy, yet the user _having_ a WEP key configured.
So say we fix iee80211_privacy_mismatch in checking for the right
mismatch only. Then everybody would be happy, except some poor soul on a
mixed cell network who would probably never figure out how to enable
mixed cell mode. Why do we hate him so much? ;-) There is no security
implication in enabling mixed mode by default --- management frames stay
unencrypted and data frames with privacy mismatch continue to be
dropped.
------------------ snip --------------------------------
Mixed Cells Mode
Some access points, for example Cisco 350 or Cisco 1200, support
environments in which not all client stations support WEP encryption;
this is called Mixed-Cell Mode. When these wireless networks operate in
"optional encryption" mode, client stations that join in WEP mode send
all messages encrypted, and stations that join in using standard mode
send all messages unencrypted. These access points broadcast that these
network do not use encryption, but allow clients to join using WEP mode.
When "Mixed-Cell" is enabled in a profile, it allows you to connect to
access points that are configured for "optional encryption".
--------------------------------------------------------
-Volker