Ok, I've started digging into this a bit more. I need to get 11n adhoc
working so I can get 11n ahdemo working, so we can actually do 11n
TDMA at some point in the near future.
There's a whole lot of missing stuff:
* ieee80211_add_neighbor() and ieee80211_init_neighbor() don't know
about HT at all; they don't populate the HT IEs or 11n rates;
* when scanning and choosing a channel to create a BSS on, there are two things:
+ if it doesn't find an IBSS, it creates one
+ if it doesn't find an IBSS, it joins that IBSS initially, via
whatever is in the scan cache, using the scan cache channel results.
Now, I fixed the primary so it does correctly populate the
HTINFO/HTCAP IEs; so now the IBSS 11n beaconing does indeed include
the TX/RX MCS configuration necessary to do HT/MCS.
But the second is the problem - namely, it looks in the scan cache,
selects the matched entry (that used a legacy channel, as scanning is
done using legacy channels!) then it just calls ieee80211_sta_join()
using that. So it always creates a non-HT channel configuration and
associates as a non-HT node.
Now, if I change adhoc_pick_bss() to adjust the channel to be a HT
channel before it goes off and calls ieee80211_sta_join(), it will
successfully setup the channel to be an 11n channel and it'll do MCS
rates with an 11n peer fine. (traffic throughput sucks and panics
though; so it's not all smooth sailing here.) But that raises a big
If the first node that a new IBSS device sees is non-11n, will it just
assume the BSS is legacy, or will it magically promote itself to
11n/ht20 or 11n/ht40 and continue along merrily?
It'd be nice to figure out what the behaviour there should be.
Anyway. I'm making a little progress. I'll see if I can figure out why
I'm getting panics and crappy throughput when doing traffic tests - I
bet the adhoc RX and TX data path doesn't have some 11n related fixes
in there and it's messing things up.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"