Initial cut at making IBSS support 802.11n aware.

* Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not
  100% correct as it's not looking at the draft 11n HTINFO location,
  but I don't think anyone will care.

* When doing an IBSS join make sure the 11n channel configuration
  is used - otherwise the 11a/11bg channel will be used
  and there won't be any chance for an upgrade to 11n.

* When creating an IBSS network, ensure the channel is updated to an
  11n channel so other 11n nodes can see it and speak to it with MCS
  rates.

* Add a bit of code that's disabled for now which handles the HT
  field updating.  This won't work out very well with lots of adhoc
  nodes as we'd end up ping-ponging between the HT configuration for
  each node.  Instead, we should likely only pay attention to the
  "master" node we initially associated against and then ensure we
  propagate that information forward in our subsequent beacons.  However,
  due to the nature of IBSS (ie, there's no specific "master" node in
  the specification) it's unclear which node we should lift the HT
  parameters from.

  So for now this assumes the HT parameters are squirreled away in the
  initial beacon/probe response.

So there's some trickiness here.

With ap/sta pairing, the probe response just populates a legacy node
and the association request/response is what is used for negotiation
11n-ness (and upgrading things as needed.)

With ibss networks, the pairing is done with probe request/response,
with discovery being done by creating nodes when new beacons in the
IBSS / BSSID are heard.  There's no assoc request/response frames going on.

So the trick here has been to figure out where to upgrade things.
I don't like how I just taught ieee80211_sta_join() to "speak" HT -
I'd rather there be an upgrade path when an IBSS node joins and there
are HT parameters present.  Once I've done that, I'll kill this
HT special casing that's going on in ieee80211_sta_join().

Tested:

* AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests
  whilst in a non-encrypted adhoc network.

TODO:

* Fix up the HT upgrade path for IBSS nodes rather than adding code
  in ieee80211_sta_join(), then remove my code from there.

* When associating, there's a concept of a "master" node in the IBSS
  which is the node you first joined the network through.  It's possible
  the correct thing to do is to listen to HT updates and configure WME
  parameters from that node.  However, once that node goes away, which
  node(s) should be listened to for configuration changes?

  For things like HT channel width, it's likely going to be ok to
  just associate as HT40 and then use the per-neighbor rate control
  and HTINFO/HTCAP fields to figure out which rates and configuration
  to speak.  Ie, for a 20MHz 11n node, just speak 20MHz rates to
  it.  It shouldn't "change", like what goes on in AP/STA configurations.

1 files changed, 19 insertions, 5 deletions

diff --git a/sys/net80211/ieee80211_scan_sta.c b/sys/net80211/ieee80211_scan_sta.c
index 6f5e9d2..381faca 100644
--- a/sys/net80211/ieee80211_scan_sta.c
+++ b/sys/net80211/ieee80211_scan_sta.c
@@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$");
 #ifdef IEEE80211_SUPPORT_MESH
 #include <net80211/ieee80211_mesh.h>
 #endif
+#include <net80211/ieee80211_ratectl.h>
 
 #include <net/bpf.h>
 
@@ -1567,6 +1568,7 @@ adhoc_pick_bss(struct ieee80211_scan_state *ss, struct ieee80211vap *vap)
 	struct sta_table *st = ss->ss_priv;
 	struct sta_entry *selbs;
 	struct ieee80211_channel *chan;
+	struct ieee80211com *ic = vap->iv_ic;
 
 	KASSERT(vap->iv_opmode == IEEE80211_M_IBSS ||
 		vap->iv_opmode == IEEE80211_M_AHDEMO ||
@@ -1612,15 +1614,19 @@ notfound:
 			 */
 			if (vap->iv_des_chan == IEEE80211_CHAN_ANYC ||
 			    IEEE80211_IS_CHAN_RADAR(vap->iv_des_chan)) {
-				struct ieee80211com *ic = vap->iv_ic;
-
 				chan = adhoc_pick_channel(ss, 0);
-				if (chan != NULL)
-					chan = ieee80211_ht_adjust_channel(ic,
-					    chan, vap->iv_flags_ht);
 			} else
 				chan = vap->iv_des_chan;
 			if (chan != NULL) {
+				struct ieee80211com *ic = vap->iv_ic;
+				/*
+				 * Create a HT capable IBSS; the per-node
+				 * probe request/response will result in
+				 * "correct" rate control capabilities being
+				 * negotiated.
+				 */
+				chan = ieee80211_ht_adjust_channel(ic,
+				    chan, vap->iv_flags_ht);
 				ieee80211_create_ibss(vap, chan);
 				return 1;
 			}
@@ -1644,6 +1650,14 @@ notfound:
 	chan = selbs->base.se_chan;
 	if (selbs->se_flags & STA_DEMOTE11B)
 		chan = demote11b(vap, chan);
+	/*
+	 * If HT is available, make it a possibility here.
+	 * The intent is to enable HT20/HT40 when joining a non-HT
+	 * IBSS node; we can then advertise HT IEs and speak HT
+	 * to any subsequent nodes that support it.
+	 */
+	chan = ieee80211_ht_adjust_channel(ic,
+	    chan, vap->iv_flags_ht);
 	if (!ieee80211_sta_join(vap, chan, &selbs->base))
 		goto notfound;
 	return 1;				/* terminate scan */