mac80211: Remove ieee80211_privacy_mismatch

Remove ieee80211_privacy_mismatch() and associated variable "privacy_enabled". It serves no purpose and breaks dynamic wep.

---

The patch is on top of Johannes' patches.

index b028cac..d13c06a 100644
@@ -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)

index b68da75..fbdd1d1 100644
@@ -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 ||

index 9234183..f2cf4de 100644
@@ -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);
-	}
 }
 
 

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

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

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

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

Oh right, but I dropped that patch now that Jouni complained about it :)

So far I understand, that's exactly what happens with WPA as well.

Ah, so that's mixed cell. Had me wondering anyway :)

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.

thanks for that, where did you get that from?

johannes

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...

I found it at Dell's support page:

http://www.support.dell.com/support/edocs/network/P94583/en/security.htm