[PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request

[PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request

[Alexander Simon]

Extend cfg80211 ibss struct for HT mode

Check if extension channel can be used

Export can_beacon_sec_chan for use in mac80211.
Must be called from ibss.c because the channel may change.

Signed-off-by: Alexander Simon <an.alexsimon@googlemail.com>
---
 include/net/cfg80211.h |   11 +++++++++++
 net/wireless/chan.c    |   11 ++++++-----
 net/wireless/nl80211.c |   25 +++++++++++++++++++++++--
 3 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b42136a..eaa3a9d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1105,6 +1105,7 @@ struct cfg80211_ibss_params {
 	u8 *ssid;
 	u8 *bssid;
 	struct ieee80211_channel *channel;
+	enum nl80211_channel_type channel_type;
 	u8 *ie;
 	u8 ssid_len, ie_len;
 	u16 beacon_interval;
@@ -3118,6 +3119,16 @@ void cfg80211_cqm_pktloss_notify(struct net_device *dev,
 void cfg80211_gtk_rekey_notify(struct net_device *dev, const u8 *bssid,
 			       const u8 *replay_ctr, gfp_t gfp);
 
+/**
+ * cfg80211_can_use_ext_chan - test if ht40 on extension channel can be used
+ * @wiphy: the wiphy
+ * @chan: main channel
+ * @channel_type: HT mode
+ */
+bool cfg80211_can_beacon_sec_chan(struct wiphy *wiphy,
+				  struct ieee80211_channel *chan,
+				  enum nl80211_channel_type channel_type);
+
 /* Logging, debugging and troubleshooting/diagnostic helpers. */
 
 /* wiphy_printk helpers, similar to dev_printk */
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 17cd0c0..81740af 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -44,9 +44,9 @@ rdev_freq_to_chan(struct cfg80211_registered_device *rdev,
 	return chan;
 }
 
-static bool can_beacon_sec_chan(struct wiphy *wiphy,
-				struct ieee80211_channel *chan,
-				enum nl80211_channel_type channel_type)
+bool cfg80211_can_beacon_sec_chan(struct wiphy *wiphy,
+				  struct ieee80211_channel *chan,
+				  enum nl80211_channel_type channel_type)
 {
 	struct ieee80211_channel *sec_chan;
 	int diff;
@@ -75,6 +75,7 @@ static bool can_beacon_sec_chan(struct wiphy *wiphy,
 
 	return true;
 }
+EXPORT_SYMBOL(cfg80211_can_beacon_sec_chan);
 
 int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
 		      struct wireless_dev *wdev, int freq,
@@ -109,8 +110,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
 		switch (channel_type) {
 		case NL80211_CHAN_HT40PLUS:
 		case NL80211_CHAN_HT40MINUS:
-			if (!can_beacon_sec_chan(&rdev->wiphy, chan,
-						 channel_type)) {
+			if (!cfg80211_can_beacon_sec_chan(&rdev->wiphy, chan,
+							  channel_type)) {
 				printk(KERN_DEBUG
 				       "cfg80211: Secondary channel not "
 				       "allowed to initiate communication\n");
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1108954..320f61e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4537,13 +4537,34 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
 		ibss.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
 	}
 
-	ibss.channel = ieee80211_get_channel(wiphy,
-		nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
+	if (info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]) {
+		enum nl80211_channel_type channel_type;
+
+		channel_type = nla_get_u32(
+				info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]);
+		if (channel_type > NL80211_CHAN_HT40PLUS)
+			return -EINVAL;
+		ibss.channel_type = channel_type;
+	} else {
+		ibss.channel_type = NL80211_CHAN_NO_HT;
+	}
+
+	ibss.channel = rdev_freq_to_chan(rdev,
+		nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]),
+		ibss.channel_type);
 	if (!ibss.channel ||
+	    ibss.channel->flags & IEEE80211_CHAN_RADAR ||
 	    ibss.channel->flags & IEEE80211_CHAN_NO_IBSS ||
 	    ibss.channel->flags & IEEE80211_CHAN_DISABLED)
 		return -EINVAL;
 
+	/* Both channels should be able to initiate communication */
+	if ((ibss.channel_type == NL80211_CHAN_HT40PLUS ||
+	     ibss.channel_type == NL80211_CHAN_HT40MINUS) &&
+	    !cfg80211_can_beacon_sec_chan(&rdev->wiphy, ibss.channel,
+					  ibss.channel_type))
+		return -EINVAL;
+
 	ibss.channel_fixed = !!info->attrs[NL80211_ATTR_FREQ_FIXED];
 	ibss.privacy = !!info->attrs[NL80211_ATTR_PRIVACY];
 
-- 
1.7.3.4

[PATCH v3 2/3] mac80211: Add HT helper functions

[Alexander Simon]

Some refactoring for IBSS HT.

Move HT info and capability IEs building code into separate functions.

Add function to get the channel type from an HT info IE.

Signed-off-by: Alexander Simon <an.alexsimon@googlemail.com>
---
 net/mac80211/ieee80211_i.h |    8 +++
 net/mac80211/util.c        |  116 +++++++++++++++++++++++++++++++++++++------
 net/mac80211/work.c        |   29 +-----------
 3 files changed, 108 insertions(+), 45 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 21186e2..d6ff264 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1339,6 +1339,12 @@ void ieee80211_recalc_smps(struct ieee80211_local *local);
 size_t ieee80211_ie_split(const u8 *ies, size_t ielen,
 			  const u8 *ids, int n_ids, size_t offset);
 size_t ieee80211_ie_split_vendor(const u8 *ies, size_t ielen, size_t offset);
+u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct ieee80211_supported_band *sband,
+			      u16 cap);
+u8 *ieee80211_ie_build_ht_info(u8 *pos,
+				struct ieee80211_sta_ht_cap *ht_cap,
+				struct ieee80211_channel *channel,
+				enum nl80211_channel_type channel_type);
 
 /* internal work items */
 void ieee80211_work_init(struct ieee80211_local *local);
@@ -1367,6 +1373,8 @@ ieee80211_get_channel_mode(struct ieee80211_local *local,
 bool ieee80211_set_channel_type(struct ieee80211_local *local,
 				struct ieee80211_sub_if_data *sdata,
 				enum nl80211_channel_type chantype);
+enum nl80211_channel_type
+ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info);
 
 #ifdef CONFIG_MAC80211_NOINLINE
 #define debug_noinline noinline
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 4b1466d..5462c0b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -814,23 +814,8 @@ int ieee80211_build_preq_ies(struct ieee80211_local *local, u8 *buffer,
 		offset = noffset;
 	}
 
-	if (sband->ht_cap.ht_supported) {
-		u16 cap = sband->ht_cap.cap;
-		__le16 tmp;
-
-		*pos++ = WLAN_EID_HT_CAPABILITY;
-		*pos++ = sizeof(struct ieee80211_ht_cap);
-		memset(pos, 0, sizeof(struct ieee80211_ht_cap));
-		tmp = cpu_to_le16(cap);
-		memcpy(pos, &tmp, sizeof(u16));
-		pos += sizeof(u16);
-		*pos++ = sband->ht_cap.ampdu_factor |
-			 (sband->ht_cap.ampdu_density <<
-				IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
-		memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
-		pos += sizeof(sband->ht_cap.mcs);
-		pos += 2 + 4 + 1; /* ext info, BF cap, antsel */
-	}
+	if (sband->ht_cap.ht_supported)
+		pos = ieee80211_ie_build_ht_cap(pos, sband, sband->ht_cap.cap);
 
 	/*
 	 * If adding more here, adjust code in main.c
@@ -1353,3 +1338,100 @@ void ieee80211_disable_rssi_reports(struct ieee80211_vif *vif)
 	_ieee80211_enable_rssi_reports(sdata, 0, 0);
 }
 EXPORT_SYMBOL(ieee80211_disable_rssi_reports);
+
+u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct ieee80211_supported_band *sband,
+			      u16 cap)
+{
+	__le16 tmp;
+
+	*pos++ = WLAN_EID_HT_CAPABILITY;
+	*pos++ = sizeof(struct ieee80211_ht_cap);
+	memset(pos, 0, sizeof(struct ieee80211_ht_cap));
+
+	/* capability flags */
+	tmp = cpu_to_le16(cap);
+	memcpy(pos, &tmp, sizeof(u16));
+	pos += sizeof(u16);
+
+	/* AMPDU parameters */
+	*pos++ = sband->ht_cap.ampdu_factor |
+		 (sband->ht_cap.ampdu_density <<
+			IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
+
+	/* MCS set */
+	memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
+	pos += sizeof(sband->ht_cap.mcs);
+
+	/* extended capabilities */
+	pos += sizeof(__le16);
+
+	/* BF capabilities */
+	pos += sizeof(__le32);
+
+	/* antenna selection */
+	pos += sizeof(u8);
+
+	return pos;
+}
+
+u8 *ieee80211_ie_build_ht_info(u8 *pos,
+			       struct ieee80211_sta_ht_cap *ht_cap,
+			       struct ieee80211_channel *channel,
+			       enum nl80211_channel_type channel_type)
+{
+	struct ieee80211_ht_info *ht_info;
+	/* Build HT Information */
+	*pos++ = WLAN_EID_HT_INFORMATION;
+	*pos++ = sizeof(struct ieee80211_ht_info);
+	ht_info = (struct ieee80211_ht_info *)pos;
+	ht_info->control_chan =
+			ieee80211_frequency_to_channel(channel->center_freq);
+	switch (channel_type) {
+	case NL80211_CHAN_HT40MINUS:
+		ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+		break;
+	case NL80211_CHAN_HT40PLUS:
+		ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+		break;
+	case NL80211_CHAN_HT20:
+	default:
+		ht_info->ht_param = IEEE80211_HT_PARAM_CHA_SEC_NONE;
+		break;
+	}
+	if (ht_cap->cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
+		ht_info->ht_param |= IEEE80211_HT_PARAM_CHAN_WIDTH_ANY;
+	ht_info->operation_mode = 0x0000;
+	ht_info->stbc_param = 0x0000;
+
+	/* It seems that Basic MCS set and Supported MCS set
+	   are identical for the first 10 bytes */
+	memset(&ht_info->basic_set, 0, 16);
+	memcpy(&ht_info->basic_set, &ht_cap->mcs, 10);
+
+	return pos + sizeof(struct ieee80211_ht_info);
+}
+
+enum nl80211_channel_type
+ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info)
+{
+	enum nl80211_channel_type channel_type;
+
+	if (!ht_info)
+		return NL80211_CHAN_NO_HT;
+
+	switch (ht_info->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
+	case IEEE80211_HT_PARAM_CHA_SEC_NONE:
+		channel_type = NL80211_CHAN_HT20;
+		break;
+	case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
+		channel_type = NL80211_CHAN_HT40PLUS;
+		break;
+	case IEEE80211_HT_PARAM_CHA_SEC_BELOW:
+		channel_type = NL80211_CHAN_HT40MINUS;
+		break;
+	default:
+		channel_type = NL80211_CHAN_NO_HT;
+	}
+
+	return channel_type;
+}
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index bac3439..b399849 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -103,7 +103,6 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
 	u8 *pos;
 	u32 flags = channel->flags;
 	u16 cap = sband->ht_cap.cap;
-	__le16 tmp;
 
 	if (!sband->ht_cap.ht_supported)
 		return;
@@ -154,34 +153,8 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
 	}
 
 	/* reserve and fill IE */
-
 	pos = skb_put(skb, sizeof(struct ieee80211_ht_cap) + 2);
-	*pos++ = WLAN_EID_HT_CAPABILITY;
-	*pos++ = sizeof(struct ieee80211_ht_cap);
-	memset(pos, 0, sizeof(struct ieee80211_ht_cap));
-
-	/* capability flags */
-	tmp = cpu_to_le16(cap);
-	memcpy(pos, &tmp, sizeof(u16));
-	pos += sizeof(u16);
-
-	/* AMPDU parameters */
-	*pos++ = sband->ht_cap.ampdu_factor |
-		 (sband->ht_cap.ampdu_density <<
-			IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
-
-	/* MCS set */
-	memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
-	pos += sizeof(sband->ht_cap.mcs);
-
-	/* extended capabilities */
-	pos += sizeof(__le16);
-
-	/* BF capabilities */
-	pos += sizeof(__le32);
-
-	/* antenna selection */
-	pos += sizeof(u8);
+	ieee80211_ie_build_ht_cap(pos, sband, cap);
 }
 
 static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
-- 
1.7.3.4

[PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Alexander Simon]

The HT mode is set by iw (previous patchsets).
The interface is set into the specified HT mode.
HT mode and capabilities are announced in beacons.

If we add a station that uses HT also, the fastest matching HT mode will be used
for transmission. That means if we are using HT40+ and we add a station running
on HT40-, we would transfer at HT20.

If we join an IBSS with HT40, but the HT40 channel map or regdom blocks it, we
will fall back into HT20.

Allow frame aggregation to start in IBSS mode.

Signed-off-by: Alexander Simon <an.alexsimon@googlemail.com>
---
 net/mac80211/agg-rx.c      |    2 +
 net/mac80211/agg-tx.c      |    5 ++-
 net/mac80211/ht.c          |    2 +
 net/mac80211/ibss.c        |   88 ++++++++++++++++++++++++++++++++++++++-----
 net/mac80211/ieee80211_i.h |    1 +
 net/mac80211/rx.c          |    3 +-
 6 files changed, 88 insertions(+), 13 deletions(-)

diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index e6cab51..89d882d 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -180,6 +180,8 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
 		memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
 	else if (sdata->vif.type == NL80211_IFTYPE_STATION)
 		memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+	else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+		memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
 
 	mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
 					  IEEE80211_STYPE_ACTION);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 3cef5a7..bedd702 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -81,6 +81,8 @@ static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,
 		memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
 	else if (sdata->vif.type == NL80211_IFTYPE_STATION)
 		memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+	else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+		memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
 
 	mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
 					  IEEE80211_STYPE_ACTION);
@@ -379,7 +381,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
 	 */
 	if (sdata->vif.type != NL80211_IFTYPE_STATION &&
 	    sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
-	    sdata->vif.type != NL80211_IFTYPE_AP)
+	    sdata->vif.type != NL80211_IFTYPE_AP &&
+	    sdata->vif.type != NL80211_IFTYPE_ADHOC)
 		return -EINVAL;
 
 	if (test_sta_flags(sta, WLAN_STA_BLOCK_BA)) {
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 2b9b52c..da1c432 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -199,6 +199,8 @@ void ieee80211_send_delba(struct ieee80211_sub_if_data *sdata,
 		memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
 	else if (sdata->vif.type == NL80211_IFTYPE_STATION)
 		memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+	else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+		memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
 
 	mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
 					  IEEE80211_STYPE_ACTION);
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 836b275..1810f57 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -77,6 +77,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
 	struct cfg80211_bss *bss;
 	u32 bss_change;
 	u8 supp_rates[IEEE80211_MAX_SUPP_RATES];
+	enum nl80211_channel_type channel_type;
 
 	lockdep_assert_held(&ifibss->mtx);
 
@@ -104,8 +105,16 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
 
 	sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
 
-	local->oper_channel = chan;
-	WARN_ON(!ieee80211_set_channel_type(local, sdata, NL80211_CHAN_NO_HT));
+	channel_type = ifibss->channel_type;
+	if (channel_type > NL80211_CHAN_HT20 &&
+	    !cfg80211_can_beacon_sec_chan(local->hw.wiphy, chan, channel_type))
+		channel_type = NL80211_CHAN_HT20;
+	if (!ieee80211_set_channel_type(local, sdata, channel_type)) {
+		/* can only fail due to HT40+/- mismatch */
+		channel_type = NL80211_CHAN_HT20;
+		WARN_ON(!ieee80211_set_channel_type(local, sdata,
+						    NL80211_CHAN_HT20));
+	}
 	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
 
 	sband = local->hw.wiphy->bands[chan->band];
@@ -171,6 +180,18 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
 		memcpy(skb_put(skb, ifibss->ie_len),
 		       ifibss->ie, ifibss->ie_len);
 
+	/* add HT capability and information IEs */
+	if (channel_type && sband->ht_cap.ht_supported) {
+		pos = skb_put(skb, 4 +
+				   sizeof(struct ieee80211_ht_cap) +
+				   sizeof(struct ieee80211_ht_info));
+		pos = ieee80211_ie_build_ht_cap(pos, sband, sband->ht_cap.cap);
+		pos = ieee80211_ie_build_ht_info(pos,
+						 &sband->ht_cap,
+						 chan,
+						 channel_type);
+	}
+
 	if (local->hw.queues >= 4) {
 		pos = skb_put(skb, 9);
 		*pos++ = WLAN_EID_VENDOR_SPECIFIC;
@@ -194,6 +215,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
 	bss_change |= BSS_CHANGED_BEACON;
 	bss_change |= BSS_CHANGED_BEACON_ENABLED;
 	bss_change |= BSS_CHANGED_BASIC_RATES;
+	bss_change |= BSS_CHANGED_HT;
 	bss_change |= BSS_CHANGED_IBSS;
 	sdata->vif.bss_conf.ibss_joined = true;
 	ieee80211_bss_info_change_notify(sdata, bss_change);
@@ -266,6 +288,7 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
 	u64 beacon_timestamp, rx_timestamp;
 	u32 supp_rates = 0;
 	enum ieee80211_band band = rx_status->band;
+	struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band];
 
 	if (elems->ds_params && elems->ds_params_len == 1)
 		freq = ieee80211_channel_to_frequency(elems->ds_params[0],
@@ -275,7 +298,10 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
 
 	channel = ieee80211_get_channel(local->hw.wiphy, freq);
 
-	if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
+	if (!channel ||
+	    channel->flags & (IEEE80211_CHAN_DISABLED ||
+			      IEEE80211_CHAN_NO_IBSS ||
+			      IEEE80211_CHAN_RADAR))
 		return;
 
 	if (sdata->vif.type == NL80211_IFTYPE_ADHOC &&
@@ -313,8 +339,41 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
 						GFP_ATOMIC);
 		}
 
-		if (sta && elems->wmm_info)
-			set_sta_flags(sta, WLAN_STA_WME);
+		if (sta) {
+			if (elems->wmm_info)
+				set_sta_flags(sta, WLAN_STA_WME);
+
+			/* we both use HT */
+			if (elems->ht_info_elem && elems->ht_cap_elem &&
+			    sdata->u.ibss.channel_type) {
+				enum nl80211_channel_type channel_type =
+					ieee80211_ht_info_to_channel_type(
+							   elems->ht_info_elem);
+				struct ieee80211_sta_ht_cap sta_ht_cap_new;
+
+				/*
+				 * fall back to HT20 if we don't use or use
+				 * the other extension channel
+				 */
+				if (channel_type > NL80211_CHAN_HT20 &&
+				    channel_type != sdata->u.ibss.channel_type)
+					channel_type = NL80211_CHAN_HT20;
+
+				ieee80211_ht_cap_ie_to_sta_ht_cap(sband,
+						elems->ht_cap_elem,
+						&sta_ht_cap_new);
+				if (memcmp(&sta->sta.ht_cap, &sta_ht_cap_new,
+					   sizeof(sta_ht_cap_new))) {
+					memcpy(&sta->sta.ht_cap,
+					       &sta_ht_cap_new,
+					       sizeof(sta_ht_cap_new));
+					rate_control_rate_update(local, sband,
+							sta,
+							IEEE80211_RC_HT_CHANGED,
+							channel_type);
+				}
+			}
+		}
 
 		rcu_read_unlock();
 	}
@@ -896,10 +955,15 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
 	struct sk_buff *skb;
 
 	skb = dev_alloc_skb(sdata->local->hw.extra_tx_headroom +
-			    36 /* bitrates */ +
-			    34 /* SSID */ +
-			    3  /* DS params */ +
-			    4  /* IBSS params */ +
+			    sizeof(struct ieee80211_hdr_3addr) +
+			    12 /* struct ieee80211_mgmt.u.beacon */ +
+			    2 + IEEE80211_MAX_SSID_LEN /* max SSID */ +
+			    2 + 8 /* max Supported Rates */ +
+			    3 /* max DS params */ +
+			    4 /* IBSS params */ +
+			    2 + (IEEE80211_MAX_SUPP_RATES - 8) +
+			    2 + sizeof(struct ieee80211_ht_cap) +
+			    2 + sizeof(struct ieee80211_ht_info) +
 			    params->ie_len);
 	if (!skb)
 		return -ENOMEM;
@@ -920,13 +984,15 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
 	sdata->vif.bss_conf.beacon_int = params->beacon_interval;
 
 	sdata->u.ibss.channel = params->channel;
+	sdata->u.ibss.channel_type = params->channel_type;
 	sdata->u.ibss.fixed_channel = params->channel_fixed;
 
 	/* fix ourselves to that channel now already */
 	if (params->channel_fixed) {
 		sdata->local->oper_channel = params->channel;
-		WARN_ON(!ieee80211_set_channel_type(sdata->local, sdata,
-						    NL80211_CHAN_NO_HT));
+		if (!ieee80211_set_channel_type(sdata->local, sdata,
+					       params->channel_type))
+			return -EINVAL;
 	}
 
 	if (params->ie) {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d6ff264..e9ec69b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -465,6 +465,7 @@ struct ieee80211_if_ibss {
 	u8 ssid_len, ie_len;
 	u8 *ie;
 	struct ieee80211_channel *channel;
+	enum nl80211_channel_type channel_type;
 
 	unsigned long ibss_join_req;
 	/* probe response/beacon for IBSS */
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index db46601..51157df 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2163,7 +2163,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
 		 */
 		if (sdata->vif.type != NL80211_IFTYPE_STATION &&
 		    sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
-		    sdata->vif.type != NL80211_IFTYPE_AP)
+		    sdata->vif.type != NL80211_IFTYPE_AP &&
+		    sdata->vif.type != NL80211_IFTYPE_ADHOC)
 			break;
 
 		/* verify action_code is present */
-- 
1.7.3.4

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Alexander Simon]

I came to the conclusion that the old patch was way too complicated and
confusing. Too much cases have to be taken into account when trying to
homogenize the HT mode.
I changed the code now that only mode given by iw is considered.

This yields in a way smaller patch and less refactoring as we don't need to
manipulate the beacon skb and match additionally for HT mode in scan results.

I think it's better that way.

Sorry for the confusion and/or extra work!

Re: [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request

[Johannes Berg]

On Sun, 2011-09-18 at 00:14 +0200, Alexander Simon wrote:

> +/**
> + * cfg80211_can_use_ext_chan - test if ht40 on extension channel can be used
> + * @wiphy: the wiphy
> + * @chan: main channel
> + * @channel_type: HT mode
> + */
> +bool cfg80211_can_beacon_sec_chan(struct wiphy *wiphy,

That doesn't match the documentation now ...

> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -4537,13 +4537,34 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
>  		ibss.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
>  	}
>  
> -	ibss.channel = ieee80211_get_channel(wiphy,
> -		nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
> +	if (info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]) {
> +		enum nl80211_channel_type channel_type;
> +
> +		channel_type = nla_get_u32(
> +				info->attrs[NL80211_ATTR_WIPHY_CHANNEL_TYPE]);
> +		if (channel_type > NL80211_CHAN_HT40PLUS)
> +			return -EINVAL;
> +		ibss.channel_type = channel_type;
> +	} else {
> +		ibss.channel_type = NL80211_CHAN_NO_HT;
> +	}
> +
> +	ibss.channel = rdev_freq_to_chan(rdev,
> +		nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]),
> +		ibss.channel_type);
>  	if (!ibss.channel ||
> +	    ibss.channel->flags & IEEE80211_CHAN_RADAR ||
>  	    ibss.channel->flags & IEEE80211_CHAN_NO_IBSS ||
>  	    ibss.channel->flags & IEEE80211_CHAN_DISABLED)
>  		return -EINVAL;
>  
> +	/* Both channels should be able to initiate communication */
> +	if ((ibss.channel_type == NL80211_CHAN_HT40PLUS ||
> +	     ibss.channel_type == NL80211_CHAN_HT40MINUS) &&
> +	    !cfg80211_can_beacon_sec_chan(&rdev->wiphy, ibss.channel,
> +					  ibss.channel_type))
> +		return -EINVAL;
> +
>  	ibss.channel_fixed = !!info->attrs[NL80211_ATTR_FREQ_FIXED];
>  	ibss.privacy = !!info->attrs[NL80211_ATTR_PRIVACY];
>  

With just this patch, you can set HT IBSS but mac80211 won't be able to
do it so there probably should be some form of feature check for this so
other (non-mac80211) drivers would be able to do this correctly -- I
don't expect all of them to implement HT IBSS.

johannes

Re: [PATCH v3 2/3] mac80211: Add HT helper functions

[Johannes Berg]

On Sun, 2011-09-18 at 00:14 +0200, Alexander Simon wrote:
> Some refactoring for IBSS HT.
> 
> Move HT info and capability IEs building code into separate functions.
> 
> Add function to get the channel type from an HT info IE.

> +enum nl80211_channel_type
> +ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info);

Did I miss it, or do you not use that function any more?

johannes

Re: [PATCH v3 2/3] mac80211: Add HT helper functions

[Alexander Simon]

Am Montag, 19. September 2011, 14:55:47 schrieben Sie:
> On Sun, 2011-09-18 at 00:14 +0200, Alexander Simon wrote:
> > Some refactoring for IBSS HT.
> > 
> > Move HT info and capability IEs building code into separate functions.
> > 
> > Add function to get the channel type from an HT info IE.
> > 
> > +enum nl80211_channel_type
> > +ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info);
> 
> Did I miss it, or do you not use that function any more?
> 
> johannes
I use it in ieee80211_rx_bss_info, patch 3/3.

Alex

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Johannes Berg]

On Sat, 2011-09-17 at 22:54 +0000, Alexander Simon wrote:
> I came to the conclusion that the old patch was way too complicated and
> confusing. Too much cases have to be taken into account when trying to
> homogenize the HT mode.
> I changed the code now that only mode given by iw is considered.
> 
> This yields in a way smaller patch and less refactoring as we don't need to
> manipulate the beacon skb and match additionally for HT mode in scan results.
> 
> I think it's better that way.

Hmm. 10.3.2.2.2 seems to indicate that HT operation parameters should be
adopted, and 11.14.2 says:
"An HT STA that is a member of an IBSS adopts the value of the Secondary
Channel Offset field in received frames according to the rules in 11.1.4
and shall not transmit a value for the Secondary Channel Offset field
that differs from the most recently adopted value."


Also, are you handling the following?

     1. 9.13.3.1: In an IBSS, the HT Protection field is reserved, but
        an HT STA shall protect HT transmissions as though the HT
        Protection field were set to non-HT mixed mode.
     2. In an IBSS, the RIFS Mode field of the HT Operation element is
        also reserved, but an HT STA shall operate as though this field
        were set to 1.
     3. 11.5.1.1: If the initiating STA is an HT STA, is a member of an
        IBSS, and has no other existing Block Ack agreement with the
        recipient STA, then the initiating STA shall transmit a Probe
        Request frame to the recipient STA and shall not transmit an
        ADDBA Request frame unless it receives a Probe Response frame
        from the recipient within dot11ADDBAFailureTimeout.

I'd like to at least give consideration to standards-compliance and make
it clear where we don't want to be compliant.

johannes

Re: [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request

[Alexander Simon]

> With just this patch, you can set HT IBSS but mac80211 won't be able to
> do it so there probably should be some form of feature check for this so
> other (non-mac80211) drivers would be able to do this correctly -- I
> don't expect all of them to implement HT IBSS.
Just that i got this right: Mac80211 and other cfg80211-drivers should set 
some flag that HT IBSS is supported that we can check.
So that if HT IBSS is requested but not available we can return an error?

Re: [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request

[Johannes Berg]

On Mon, 2011-09-19 at 15:18 +0200, Alexander Simon wrote:
> > With just this patch, you can set HT IBSS but mac80211 won't be able to
> > do it so there probably should be some form of feature check for this so
> > other (non-mac80211) drivers would be able to do this correctly -- I
> > don't expect all of them to implement HT IBSS.
> Just that i got this right: Mac80211 and other cfg80211-drivers should set 
> some flag that HT IBSS is supported that we can check.
> So that if HT IBSS is requested but not available we can return an error?

Right. Might also make sense to export that to userspace so it knows
whether to ask for it or not (in tools like NM)

johannes

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Alexander Simon]

Wow. I've been looking for anything regarding HT IBSS in the standard but I 
must confess that I found nothing.
And, I must confess this is more work than I first expected.

Of course I agree to conforming to the standard.
9.13.3.1 and 11.5.1.1 should not be too difficult to implement and that sould 
be done.

I need some help understanding 11.14.2 and 10.3.2.2.2. (11.1.3.4 seems to 
explain them somewhat easier in words)

10.3.2.2.2 tells to adopt the HT Info IE or none if none found ("else null"), 
which means to disable HT.
Then, 11.14.2 says I should use "the most common value" for the extension 
channel, which implies that the HT Info could diverge. This contradicts the 
previous statement...

Let's say we'd adopt the HT Info:
We may join the HT IBSS from a legacy station. Logically, we would disable HT 
even if there are stations that have HT enabled.

We also could use the most common value, again joining from a legacy STA:
We must be constantly watching and saving IEs and calculate percentages for 
them. Over which time window? In larger networks, this could mean several 
beacons until this homogenization happened, especially in changing network 
environments of mobile devices. When the network is using an HT Mode we aren't 
capable of, should we drop HT or even leave the IBSS?

The problem just is that the TSFs are already the same - we have no chance to 
tell which HT configuration is the oder one.

My first patch was going in that direction (no most-recent algorithm, just the 
first HT Info received is adopted), which quite some work, had an 
unpredictable behaviour, needed to change skbs on the fly, etc...

With all this text I'm just trying to say that it would be quite some work and 
maybe the resulting code would still be ... problematic.
As broadcasting always happens in legacy mode, I see no problem having a 
inhomogeneous HT configuration.


If we want homogenization (I'll just call it that way) I'd like to propose my 
idea:
When joining, adopt the most common HT config out there. Save the number of 
stations using that configuration, including itself (variable num_configs).
If no HT config found after scanning, create one, setting num_configs to 0.
When another configuration shows up, compare num_configs to the count of that 
configuration (should be 1 as it is unlikely that more than one config will 
show up within beacon_intervall of typically 100ms).
A station that created its own config will always adopt another one (as 
num_configs == 0), but a station that has already changed won't (num_configs > 
0). 
Constantly update num_configs. Eg having 4 stations seeing each other should 
result in all stations having num_configs = 4. One STA leaving -> num_config = 
3 and so on.
This way we could limit the uncontrolled growth somewhat.

I'll apreciate any comments on this.

Thanks, Alex

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Johannes Berg]

On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
> Wow. I've been looking for anything regarding HT IBSS in the standard but I 
> must confess that I found nothing.
> And, I must confess this is more work than I first expected.

:)
Yeah sometimes it looks small but then just seems to get more
complex ... I just had that with uAPSD too.

> Of course I agree to conforming to the standard.
> 9.13.3.1 and 11.5.1.1 should not be too difficult to implement and that sould 
> be done.

I have no idea why you need 11.5.1.1 this way -- if you have ever
received probe response information from that peer it should be OK? But
we can stick to this too.

> I need some help understanding 11.14.2 and 10.3.2.2.2. (11.1.3.4 seems to 
> explain them somewhat easier in words)

I think that just means adopt the bandwidth.

> 10.3.2.2.2 tells to adopt the HT Info IE or none if none found ("else null"), 
> which means to disable HT.
> Then, 11.14.2 says I should use "the most common value" for the extension 
> channel, which implies that the HT Info could diverge. This contradicts the 
> previous statement...

I don't see that in 11.14.2?

> Let's say we'd adopt the HT Info:
> We may join the HT IBSS from a legacy station. Logically, we would disable HT 
> even if there are stations that have HT enabled.

I'm not sure -- the legacy station wouldn't be an HT station so those
rules wouldn't necessarily apply?

> We also could use the most common value, again joining from a legacy STA:
> We must be constantly watching and saving IEs and calculate percentages for 
> them. Over which time window? In larger networks, this could mean several 
> beacons until this homogenization happened, especially in changing network 
> environments of mobile devices. When the network is using an HT Mode we aren't 
> capable of, should we drop HT or even leave the IBSS?
> 
> The problem just is that the TSFs are already the same - we have no chance to 
> tell which HT configuration is the oder one.
> 
> My first patch was going in that direction (no most-recent algorithm, just the 
> first HT Info received is adopted), which quite some work, had an 
> unpredictable behaviour, needed to change skbs on the fly, etc...
> 
> With all this text I'm just trying to say that it would be quite some work and 
> maybe the resulting code would still be ... problematic.
> As broadcasting always happens in legacy mode, I see no problem having a 
> inhomogeneous HT configuration.

I think the only way to get that would be to have two independently
created networks that merge by moving?

> If we want homogenization (I'll just call it that way) I'd like to propose my 
> idea:
> When joining, adopt the most common HT config out there. Save the number of 
> stations using that configuration, including itself (variable num_configs).
> If no HT config found after scanning, create one, setting num_configs to 0.
> When another configuration shows up, compare num_configs to the count of that 
> configuration (should be 1 as it is unlikely that more than one config will 
> show up within beacon_intervall of typically 100ms).
> A station that created its own config will always adopt another one (as 
> num_configs == 0), but a station that has already changed won't (num_configs > 
> 0). 
> Constantly update num_configs. Eg having 4 stations seeing each other should 
> result in all stations having num_configs = 4. One STA leaving -> num_config = 
> 3 and so on.
> This way we could limit the uncontrolled growth somewhat.
> 
> I'll apreciate any comments on this.

That seems pretty complex too ...

I don't really know. As I said, I think I'd be happy with an
implementation that maybe doesn't fully implement everything as long as
it considers the trade-offs.

johannes

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
> That seems pretty complex too ...
>
> I don't really know. As I said, I think I'd be happy with an
> implementation that maybe doesn't fully implement everything as long as
> it considers the trade-offs.

The same questions come up with HT support and 802.11s, as per Javier
this is not really well spelled out in the spec. My recommendation is
to just support for now the most simple case and let us not entangle
ourselves with the complexities of handling trying to merge different
setups. So only enable peering up for adhoc or mesh if and only if the
observed IE matches our own supported HT caps or target configuration.
If a legacy STA tries to peer up with an HT IBSS, this would simply be
rejected. We can leave off handling the change in configuration later
for userspace, but do not see this as being a requirement for
supporting HT for IBSS or Mesh. The simpler the better, so long as we
simply respect the spec.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
> <johannes@sipsolutions.net>  wrote:
>>  On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>  That seems pretty complex too ...
>>
>>  I don't really know. As I said, I think I'd be happy with an
>>  implementation that maybe doesn't fully implement everything as long as
>>  it considers the trade-offs.
>
> The same questions come up with HT support and 802.11s, as per Javier
> this is not really well spelled out in the spec. My recommendation is
> to just support for now the most simple case and let us not entangle
> ourselves with the complexities of handling trying to merge different
> setups. So only enable peering up for adhoc or mesh if and only if the
> observed IE matches our own supported HT caps or target configuration.
> If a legacy STA tries to peer up with an HT IBSS, this would simply be
> rejected. We can leave off handling the change in configuration later
> for userspace, but do not see this as being a requirement for
> supporting HT for IBSS or Mesh. The simpler the better, so long as we
> simply respect the spec.
I disagree. That'll make it useless for real deployments, which are 
often a mix of HT and non-HT devices.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>> <johannes@sipsolutions.net>  wrote:
>>>
>>>  On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>  That seems pretty complex too ...
>>>
>>>  I don't really know. As I said, I think I'd be happy with an
>>>  implementation that maybe doesn't fully implement everything as long as
>>>  it considers the trade-offs.
>>
>> The same questions come up with HT support and 802.11s, as per Javier
>> this is not really well spelled out in the spec. My recommendation is
>> to just support for now the most simple case and let us not entangle
>> ourselves with the complexities of handling trying to merge different
>> setups. So only enable peering up for adhoc or mesh if and only if the
>> observed IE matches our own supported HT caps or target configuration.
>> If a legacy STA tries to peer up with an HT IBSS, this would simply be
>> rejected. We can leave off handling the change in configuration later
>> for userspace, but do not see this as being a requirement for
>> supporting HT for IBSS or Mesh. The simpler the better, so long as we
>> simply respect the spec.
>
> I disagree. That'll make it useless for real deployments, which are often a
> mix of HT and non-HT devices.

I'm not saying to not do it at all, I'm saying to start off with basic
support *first* and *later* worry about the mixing.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>  <johannes@sipsolutions.net>    wrote:
>>>>
>>>>    On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>    That seems pretty complex too ...
>>>>
>>>>    I don't really know. As I said, I think I'd be happy with an
>>>>    implementation that maybe doesn't fully implement everything as long as
>>>>    it considers the trade-offs.
>>>
>>>  The same questions come up with HT support and 802.11s, as per Javier
>>>  this is not really well spelled out in the spec. My recommendation is
>>>  to just support for now the most simple case and let us not entangle
>>>  ourselves with the complexities of handling trying to merge different
>>>  setups. So only enable peering up for adhoc or mesh if and only if the
>>>  observed IE matches our own supported HT caps or target configuration.
>>>  If a legacy STA tries to peer up with an HT IBSS, this would simply be
>>>  rejected. We can leave off handling the change in configuration later
>>>  for userspace, but do not see this as being a requirement for
>>>  supporting HT for IBSS or Mesh. The simpler the better, so long as we
>>>  simply respect the spec.
>>
>>  I disagree. That'll make it useless for real deployments, which are often a
>>  mix of HT and non-HT devices.
>
> I'm not saying to not do it at all, I'm saying to start off with basic
> support *first* and *later* worry about the mixing.
Simply sticking with the configured HT opmode is also simple, but it's a 
lot more practical.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Javier Cardona]

On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>  I don't really know. As I said, I think I'd be happy with an
>>>  implementation that maybe doesn't fully implement everything as long as
>>>  it considers the trade-offs.
>>
>> The same questions come up with HT support and 802.11s, as per Javier
>> this is not really well spelled out in the spec. My recommendation is
>> to just support for now the most simple case and let us not entangle
>> ourselves with the complexities of handling trying to merge different
>> setups. So only enable peering up for adhoc or mesh if and only if the
>> observed IE matches our own supported HT caps or target configuration.
>> If a legacy STA tries to peer up with an HT IBSS, this would simply be
>> rejected. We can leave off handling the change in configuration later
>> for userspace, but do not see this as being a requirement for
>> supporting HT for IBSS or Mesh. The simpler the better, so long as we
>> simply respect the spec.
>
> I disagree. That'll make it useless for real deployments, which are often a
> mix of HT and non-HT devices.

For mesh, my initial thought was to allow mismatched peerings
according to the following rules:

 1. Peering is allowed between non-HT STAs as well as between HT and
non-HT STAs.  No HT checks in that case.
 2. If both peer candidates support HT, only allow peering if they
advertise the same BSSBasicMCSSet in their HT Operation IE.  This
ensures that a basic link can be established between these stations.
 3. Don't use the HT info for anything else: if there are poorly
matched HT links, let the path selection algorithm try and find better
ones (if there are any).

I believe the above is compliant with 802.11s.

Cheers,

Javier

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>
>>>  On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>>
>>>>  On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>>  <johannes@sipsolutions.net>    wrote:
>>>>>
>>>>>   On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>>   That seems pretty complex too ...
>>>>>
>>>>>   I don't really know. As I said, I think I'd be happy with an
>>>>>   implementation that maybe doesn't fully implement everything as long
>>>>> as
>>>>>   it considers the trade-offs.
>>>>
>>>>  The same questions come up with HT support and 802.11s, as per Javier
>>>>  this is not really well spelled out in the spec. My recommendation is
>>>>  to just support for now the most simple case and let us not entangle
>>>>  ourselves with the complexities of handling trying to merge different
>>>>  setups. So only enable peering up for adhoc or mesh if and only if the
>>>>  observed IE matches our own supported HT caps or target configuration.
>>>>  If a legacy STA tries to peer up with an HT IBSS, this would simply be
>>>>  rejected. We can leave off handling the change in configuration later
>>>>  for userspace, but do not see this as being a requirement for
>>>>  supporting HT for IBSS or Mesh. The simpler the better, so long as we
>>>>  simply respect the spec.
>>>
>>>  I disagree. That'll make it useless for real deployments, which are
>>> often a
>>>  mix of HT and non-HT devices.
>>
>> I'm not saying to not do it at all, I'm saying to start off with basic
>> support *first* and *later* worry about the mixing.
>
> Simply sticking with the configured HT opmode is also simple, but it's a lot
> more practical.

Just need to deal with the complexity, the complexity question is
where do we handle this, verifying it respects the standard, and
actually getting the work done. With AP mode of operation hostapd
already does all this for us so if we want to support IBSS and Mesh
without hostapd we'd need to figure out where to stuff this code. In
the long run this would need to be resolved for both IBSS and Mesh. We
can wait for all this work to get done or get a simple taste of basic
HT support for both modes by sticking to the supported HT mode based
on the observed beacons.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 9:05 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>    wrote:
>>>>
>>>>    On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>>>
>>>>>    On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>>>    <johannes@sipsolutions.net>      wrote:
>>>>>>
>>>>>>     On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>>>     That seems pretty complex too ...
>>>>>>
>>>>>>     I don't really know. As I said, I think I'd be happy with an
>>>>>>     implementation that maybe doesn't fully implement everything as long
>>>>>>  as
>>>>>>     it considers the trade-offs.
>>>>>
>>>>>    The same questions come up with HT support and 802.11s, as per Javier
>>>>>    this is not really well spelled out in the spec. My recommendation is
>>>>>    to just support for now the most simple case and let us not entangle
>>>>>    ourselves with the complexities of handling trying to merge different
>>>>>    setups. So only enable peering up for adhoc or mesh if and only if the
>>>>>    observed IE matches our own supported HT caps or target configuration.
>>>>>    If a legacy STA tries to peer up with an HT IBSS, this would simply be
>>>>>    rejected. We can leave off handling the change in configuration later
>>>>>    for userspace, but do not see this as being a requirement for
>>>>>    supporting HT for IBSS or Mesh. The simpler the better, so long as we
>>>>>    simply respect the spec.
>>>>
>>>>    I disagree. That'll make it useless for real deployments, which are
>>>>  often a
>>>>    mix of HT and non-HT devices.
>>>
>>>  I'm not saying to not do it at all, I'm saying to start off with basic
>>>  support *first* and *later* worry about the mixing.
>>
>>  Simply sticking with the configured HT opmode is also simple, but it's a lot
>>  more practical.
>
> Just need to deal with the complexity, the complexity question is
> where do we handle this, verifying it respects the standard, and
> actually getting the work done. With AP mode of operation hostapd
> already does all this for us so if we want to support IBSS and Mesh
> without hostapd we'd need to figure out where to stuff this code. In
> the long run this would need to be resolved for both IBSS and Mesh. We
> can wait for all this work to get done or get a simple taste of basic
> HT support for both modes by sticking to the supported HT mode based
> on the observed beacons.
HT capabilities are already handled properly, the main issue is handling 
the HT opmode. For that, the only important bit is whether we're using 
HT40+, HT40- or HT20. The code can easily just fall back to HT20 when 
the HT opmode of the peer is incompatible with the local HT opmode.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 12:31 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-20 9:05 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>
>>>  On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
>>>>
>>>>  On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>
>>>>  wrote:
>>>>>
>>>>>   On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>>>>
>>>>>>   On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>>>>   <johannes@sipsolutions.net>      wrote:
>>>>>>>
>>>>>>>    On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>>>>    That seems pretty complex too ...
>>>>>>>
>>>>>>>    I don't really know. As I said, I think I'd be happy with an
>>>>>>>    implementation that maybe doesn't fully implement everything as
>>>>>>> long
>>>>>>>  as
>>>>>>>    it considers the trade-offs.
>>>>>>
>>>>>>   The same questions come up with HT support and 802.11s, as per
>>>>>> Javier
>>>>>>   this is not really well spelled out in the spec. My recommendation
>>>>>> is
>>>>>>   to just support for now the most simple case and let us not entangle
>>>>>>   ourselves with the complexities of handling trying to merge
>>>>>> different
>>>>>>   setups. So only enable peering up for adhoc or mesh if and only if
>>>>>> the
>>>>>>   observed IE matches our own supported HT caps or target
>>>>>> configuration.
>>>>>>   If a legacy STA tries to peer up with an HT IBSS, this would simply
>>>>>> be
>>>>>>   rejected. We can leave off handling the change in configuration
>>>>>> later
>>>>>>   for userspace, but do not see this as being a requirement for
>>>>>>   supporting HT for IBSS or Mesh. The simpler the better, so long as
>>>>>> we
>>>>>>   simply respect the spec.
>>>>>
>>>>>   I disagree. That'll make it useless for real deployments, which are
>>>>>  often a
>>>>>   mix of HT and non-HT devices.
>>>>
>>>>  I'm not saying to not do it at all, I'm saying to start off with basic
>>>>  support *first* and *later* worry about the mixing.
>>>
>>>  Simply sticking with the configured HT opmode is also simple, but it's a
>>> lot
>>>  more practical.
>>
>> Just need to deal with the complexity, the complexity question is
>> where do we handle this, verifying it respects the standard, and
>> actually getting the work done. With AP mode of operation hostapd
>> already does all this for us so if we want to support IBSS and Mesh
>> without hostapd we'd need to figure out where to stuff this code. In
>> the long run this would need to be resolved for both IBSS and Mesh. We
>> can wait for all this work to get done or get a simple taste of basic
>> HT support for both modes by sticking to the supported HT mode based
>> on the observed beacons.
>
> HT capabilities are already handled properly, the main issue is handling the
> HT opmode. For that, the only important bit is whether we're using HT40+,
> HT40- or HT20. The code can easily just fall back to HT20 when the HT opmode
> of the peer is incompatible with the local HT opmode.

How about verifying that HT40 primary, secondary channel pair is
allowed per as IEEE 802.11n Annex J on each peer? In the AP case we do
this centrally, but for IBSS and Mesh, does each peer have to go on
and do the check? If each peer does the check, and change settings,
how do we go about changing the configuration of the established HT
configuration? Where will this code go? Currently this goes into
hostapd for APs.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 10:18 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 12:31 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-09-20 9:05 PM, Luis R. Rodriguez wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau<nbd@openwrt.org>    wrote:
>>>>
>>>>    On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
>>>>>
>>>>>    On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau<nbd@openwrt.org>
>>>>>    wrote:
>>>>>>
>>>>>>     On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote:
>>>>>>>
>>>>>>>     On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg
>>>>>>>     <johannes@sipsolutions.net>        wrote:
>>>>>>>>
>>>>>>>>      On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
>>>>>>>>      That seems pretty complex too ...
>>>>>>>>
>>>>>>>>      I don't really know. As I said, I think I'd be happy with an
>>>>>>>>      implementation that maybe doesn't fully implement everything as
>>>>>>>>  long
>>>>>>>>    as
>>>>>>>>      it considers the trade-offs.
>>>>>>>
>>>>>>>     The same questions come up with HT support and 802.11s, as per
>>>>>>>  Javier
>>>>>>>     this is not really well spelled out in the spec. My recommendation
>>>>>>>  is
>>>>>>>     to just support for now the most simple case and let us not entangle
>>>>>>>     ourselves with the complexities of handling trying to merge
>>>>>>>  different
>>>>>>>     setups. So only enable peering up for adhoc or mesh if and only if
>>>>>>>  the
>>>>>>>     observed IE matches our own supported HT caps or target
>>>>>>>  configuration.
>>>>>>>     If a legacy STA tries to peer up with an HT IBSS, this would simply
>>>>>>>  be
>>>>>>>     rejected. We can leave off handling the change in configuration
>>>>>>>  later
>>>>>>>     for userspace, but do not see this as being a requirement for
>>>>>>>     supporting HT for IBSS or Mesh. The simpler the better, so long as
>>>>>>>  we
>>>>>>>     simply respect the spec.
>>>>>>
>>>>>>     I disagree. That'll make it useless for real deployments, which are
>>>>>>    often a
>>>>>>     mix of HT and non-HT devices.
>>>>>
>>>>>    I'm not saying to not do it at all, I'm saying to start off with basic
>>>>>    support *first* and *later* worry about the mixing.
>>>>
>>>>    Simply sticking with the configured HT opmode is also simple, but it's a
>>>>  lot
>>>>    more practical.
>>>
>>>  Just need to deal with the complexity, the complexity question is
>>>  where do we handle this, verifying it respects the standard, and
>>>  actually getting the work done. With AP mode of operation hostapd
>>>  already does all this for us so if we want to support IBSS and Mesh
>>>  without hostapd we'd need to figure out where to stuff this code. In
>>>  the long run this would need to be resolved for both IBSS and Mesh. We
>>>  can wait for all this work to get done or get a simple taste of basic
>>>  HT support for both modes by sticking to the supported HT mode based
>>>  on the observed beacons.
>>
>>  HT capabilities are already handled properly, the main issue is handling the
>>  HT opmode. For that, the only important bit is whether we're using HT40+,
>>  HT40- or HT20. The code can easily just fall back to HT20 when the HT opmode
>>  of the peer is incompatible with the local HT opmode.
>
> How about verifying that HT40 primary, secondary channel pair is
> allowed per as IEEE 802.11n Annex J on each peer? In the AP case we do
> this centrally, but for IBSS and Mesh, does each peer have to go on
> and do the check? If each peer does the check, and change settings,
> how do we go about changing the configuration of the established HT
> configuration? Where will this code go? Currently this goes into
> hostapd for APs.
This is not really an IBSS specific issue. It applies to WDS or monitor 
mode as well. If we want to properly enforce Annex J channel pairs, this 
needs to be moved to cfg80211.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> This is not really an IBSS specific issue. It applies to WDS or monitor mode
> as well.

Excellent point!

> If we want to properly enforce Annex J channel pairs, this needs to
> be moved to cfg80211.

This does not still address the issue of one peer finding out it
cannot deal with an HT40 pair and correcting the topology and
propagating this out. Not yet sure if for 802.11ac we'll need
something similar but its worth considering.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 2:26 PM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> This is not really an IBSS specific issue. It applies to WDS or monitor mode
>> as well.
>
> Excellent point!
>
>> If we want to properly enforce Annex J channel pairs, this needs to
>> be moved to cfg80211.
>
> This does not still address the issue of one peer finding out it
> cannot deal with an HT40 pair and correcting the topology and
> propagating this out. Not yet sure if for 802.11ac we'll need
> something similar but its worth considering.

Sorry I meant section 11.14.3.2 which deals with neighboring BSSes
from the scan list, the annex J stuff would still need to be done by
all the initial radiators too though for a primary.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  If we want to properly enforce Annex J channel pairs, this needs to
>>  be moved to cfg80211.
>
> This does not still address the issue of one peer finding out it
> cannot deal with an HT40 pair and correcting the topology and
> propagating this out. Not yet sure if for 802.11ac we'll need
> something similar but its worth considering.
Don't think of it as a topology. Each node makes its own decisions about 
HT40+/HT40-/HT20. If modes are incompatible, fallback to HT20  always 
works for communicating with a peer.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-20 11:52 PM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 2:26 PM, Luis R. Rodriguez<mcgrof@frijolero.org>  wrote:
>>  On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>  This is not really an IBSS specific issue. It applies to WDS or monitor mode
>>>  as well.
>>
>>  Excellent point!
>>
>>>  If we want to properly enforce Annex J channel pairs, this needs to
>>>  be moved to cfg80211.
>>
>>  This does not still address the issue of one peer finding out it
>>  cannot deal with an HT40 pair and correcting the topology and
>>  propagating this out. Not yet sure if for 802.11ac we'll need
>>  something similar but its worth considering.
>
> Sorry I meant section 11.14.3.2 which deals with neighboring BSSes
> from the scan list, the annex J stuff would still need to be done by
> all the initial radiators too though for a primary.
If we need to handle this properly in the initial patch, then this can 
probably only be done in a simple way by not supporting HT40 yet. It 
should still support joining an IBSS with a different HT opmode though.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 2:52 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>
>>>  If we want to properly enforce Annex J channel pairs, this needs to
>>>  be moved to cfg80211.
>>
>> This does not still address the issue of one peer finding out it
>> cannot deal with an HT40 pair and correcting the topology and
>> propagating this out. Not yet sure if for 802.11ac we'll need
>> something similar but its worth considering.
>
> Don't think of it as a topology. Each node makes its own decisions about
> HT40+/HT40-/HT20.

OK lets go with an example.

Node A: HT40+
   Primary: 5785 (157)
   Extension: 5805 (161)

Node B: HT20 as it finds a legacy AP with on 5805.
  Channel: 5785 (157)

Node C: HT40-
  Primary:  5785 (157)
  Extension: 5765 (153)

So we want to support this setup?

What if the network changes and we cannot use the original HT40 pair
now but we can later? This applies even to today's hostapd AP setup
and more rhetorical.

> If modes are incompatible, fallback to HT20  always works
> for communicating with a peer.

Agreed.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 3:09 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-20 11:52 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 2:26 PM, Luis R. Rodriguez<mcgrof@frijolero.org>
>>  wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>>
>>>>  This is not really an IBSS specific issue. It applies to WDS or monitor
>>>> mode
>>>>  as well.
>>>
>>>  Excellent point!
>>>
>>>>  If we want to properly enforce Annex J channel pairs, this needs to
>>>>  be moved to cfg80211.
>>>
>>>  This does not still address the issue of one peer finding out it
>>>  cannot deal with an HT40 pair and correcting the topology and
>>>  propagating this out. Not yet sure if for 802.11ac we'll need
>>>  something similar but its worth considering.
>>
>> Sorry I meant section 11.14.3.2 which deals with neighboring BSSes
>> from the scan list, the annex J stuff would still need to be done by
>> all the initial radiators too though for a primary.
>
> If we need to handle this properly in the initial patch, then this can
> probably only be done in a simple way by not supporting HT40 yet.

Right, sorry I should have clarified my concern was the scanning
aspect, not annex J. In this case I still do believe we can still
support HT40 but the scan stuff can go out to iw, or this may be a
good use case for stuffing some stuff into a shared library between iw
/ hostapd. The Mesh stuff will hopefully eventually be merged into
hostapd, but for adhoc it seems overkill. I was actually more
concerned about the mismatch on configuration rather than the
scanning, but I think Annex J helps with this, by fixating primaries
apart from each other.

> It should still support joining an IBSS with a different HT opmode though.

So long as the scan/check is done, sure.

  Luis

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Felix Fietkau]

On 2011-09-21 12:37 AM, Luis R. Rodriguez wrote:
> On Tue, Sep 20, 2011 at 2:52 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote:
>>>
>>>  On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>    wrote:
>>>>
>>>>    If we want to properly enforce Annex J channel pairs, this needs to
>>>>    be moved to cfg80211.
>>>
>>>  This does not still address the issue of one peer finding out it
>>>  cannot deal with an HT40 pair and correcting the topology and
>>>  propagating this out. Not yet sure if for 802.11ac we'll need
>>>  something similar but its worth considering.
>>
>>  Don't think of it as a topology. Each node makes its own decisions about
>>  HT40+/HT40-/HT20.
>
> OK lets go with an example.
>
> Node A: HT40+
>     Primary: 5785 (157)
>     Extension: 5805 (161)
>
> Node B: HT20 as it finds a legacy AP with on 5805.
>    Channel: 5785 (157)
>
> Node C: HT40-
>    Primary:  5785 (157)
>    Extension: 5765 (153)
>
> So we want to support this setup?
>
> What if the network changes and we cannot use the original HT40 pair
> now but we can later? This applies even to today's hostapd AP setup
> and more rhetorical.
Whenever a node is not alone in an IBSS, it must keep the primary 
channel the same to be able to talk to its neighbors. If it cannot use 
its HT40 opmode because of overlap checks then it should just gracefully 
fall back to HT20. Refusal to join or randomly changing the primary 
channel would create big problems for bigger deployments, IBSS merging 
should always be considered potentially unreliable.

Most big ad-hoc mesh deployments use fixed channel and fixed cell-id for 
that reason.

- Felix

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Luis R. Rodriguez]

On Tue, Sep 20, 2011 at 3:54 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-09-21 12:37 AM, Luis R. Rodriguez wrote:
>>
>> On Tue, Sep 20, 2011 at 2:52 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>
>>>  On 2011-09-20 11:26 PM, Luis R. Rodriguez wrote:
>>>>
>>>>  On Tue, Sep 20, 2011 at 2:04 PM, Felix Fietkau<nbd@openwrt.org>
>>>>  wrote:
>>>>>
>>>>>   If we want to properly enforce Annex J channel pairs, this needs to
>>>>>   be moved to cfg80211.
>>>>
>>>>  This does not still address the issue of one peer finding out it
>>>>  cannot deal with an HT40 pair and correcting the topology and
>>>>  propagating this out. Not yet sure if for 802.11ac we'll need
>>>>  something similar but its worth considering.
>>>
>>>  Don't think of it as a topology. Each node makes its own decisions about
>>>  HT40+/HT40-/HT20.
>>
>> OK lets go with an example.
>>
>> Node A: HT40+
>>    Primary: 5785 (157)
>>    Extension: 5805 (161)
>>
>> Node B: HT20 as it finds a legacy AP with on 5805.
>>   Channel: 5785 (157)
>>
>> Node C: HT40-
>>   Primary:  5785 (157)
>>   Extension: 5765 (153)
>>
>> So we want to support this setup?
>>
>> What if the network changes and we cannot use the original HT40 pair
>> now but we can later? This applies even to today's hostapd AP setup
>> and more rhetorical.
>
> Whenever a node is not alone in an IBSS, it must keep the primary channel
> the same to be able to talk to its neighbors. If it cannot use its HT40
> opmode because of overlap checks then it should just gracefully fall back to
> HT20. Refusal to join or randomly changing the primary channel would create
> big problems for bigger deployments, IBSS merging should always be
> considered potentially unreliable.
>
> Most big ad-hoc mesh deployments use fixed channel and fixed cell-id for
> that reason.

Agreed, the above example shows not the primary changing but the
extension channel changing. I can't think of an issue with it at this
moment though.

  Luis