Sitting in a hotel, getting stuck beacons..

I'm sitting in a hotel here in Sydney, wondering if Qantas will allow my flight to happen on Monday, when I discover my 11bg AP interface here is going a bit bezerk-o with the stuck beacons.

This isn't terribly good - I thought I had fixed all the stuck beacon issues! Apparently not.

It turns out that in this hotel room, overlooking St Martins Place, I can see a whole lot of random crap. And this includes a very persistent little wireless client:

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Crime Prevention"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "vodafone8A1F"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Boingo Hotspot"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Belkin.44FD"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "mycloud"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "101-108"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Willkommen bei La Maison du Pain"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "WLAN-E36697"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "FRITZ!BoxWLAN7240 HB"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Telekom_ICE"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "minershotspot"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "GANAG"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "WLAN-001C4A075A8D"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "iJumeirah"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "bunny"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Vineyard Square Hotel"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Belkin.44FD"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "mycloud"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "101-108"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Willkommen bei La Maison du Pain"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "FRITZ!BoxWLAN7240 HB"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "Telekom_ICE"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "minershotspot"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "GANAG"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "WLAN-001C4A075A8D"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "iJumeirah"

[e8:06:88:8b:23:57] discard probe_req frame, ssid mismatch: "bunny"

I know this is old..

From if_wi.c in FreeBSD:

/*
* Lucent WaveLAN/IEEE 802.11 PCMCIA driver.
*
* Original FreeBSD driver written by Bill Paul
* Electrical Engineering Department
* Columbia University, New York City
*/

From if_wi.c in OpenBSD:

/*
* Lucent WaveLAN/IEEE 802.11 driver for OpenBSD.
*
* Originally written by Bill Paul
* Electrical Engineering Department
* Columbia University, New York City
*/

FreeBSD vendor summit - November 2011; Sunnyvale, California

Since this doesn't seem to have gotten much notice - there's a FreeBSD vendor summit being held in Sunnyvale, California on the 3rd and 4th of November 2011. This is an opportunity for developers and vendors to share project direction and goals, collaborate on various projects, and likely hit each other with a big "why can't you do X" stick :-)

NetApp is sponsoring the event.

I'll be there with someone from Qualcomm Atheros, who will be presenting on Qualcomm/Atheros' open source direction and strategy. There'll likely be some (informal) discussion about how developers and vendors can sign up to their open source developer programme and obtain documentation/reference code for the Atheros wireless and embedded chipsets.

(This is what I've signed up to and it's been a huge help in getting Atheros 802.11n support up and going in FreeBSD.)

More details can be found here:

http://wiki.freebsd.org/201111VendorSummit

If you're a vendor using FreeBSD, or you're a vendor thinking about using FreeBSD in a project (wireless or otherwise) this mini-conference is just for you. Personally I'm interested in talking with the nvidia representative about trying to get some CUDA stuff going on FreeBSD.

Wireless update - 802.11n development

A few of us have been working towards 802.11n support in FreeBSD. Bernhard Schmidt and I were hoping to get 802.11n support up to scratch before 9.0-RELEASE but a combination of timing constraints and work constraints has hampered things somewhat.

But that said, we the net80211 support for 802.11n is in a lot better shape than it was in previous releases. Bernhard has been working out the kinks in the intel driver (if_iwn) and has 802.11n support mostly stable for those NICs. Someone else has been working on if_ral 802.11n support and has had quite a bit of success there. And I've been working on if_ath/ath_hal support.

(As a side-note, I've ordered some Marvell if_mwl compatible NICs to do some testing with.)

The 802.11n support in the FreeBSD atheros driver is already mostly usable for testing - 802.11n TX and RX works, but 802.11n TX aggregation doesn't work. So if you'd like to test it out in 9.0-RELEASE, you can do this:

* build a kernel with "options ATH_ENABLE_11N";
* ifconfig wlan0 -ampdutx
* associate as per normal to an 802.11n network.

Your download speeds will be good (as RX aggregation works) but as TX aggregation doesn't, you won't be getting full speed.

Now, as for the current work I'm doing. I've been porting over (and reimplementing in places) the 802.11n TX aggregation support, based on a combination of the atheros reference/carrier codebases and what's filtered through to the Linux ath9k driver.

In short - so far, so good. There's a lot to do, but basic TX aggregation is working in both station and hostap mode. My current test setup is:

• A routerstation pro with an AR9160 NIC, running locally built firmware (FreeBSD) in hostap mode;
• An EEEPC 701 retrofitted with an AR9280 NIC, running FreeBSD, as a station;
• My macbook pro (broadcom 802.11n) as a station.

So far it's performing well - 200mbit TX/RX UDP in 5ghz HT/40 2x2 stream mode; and 130-140mbit TX/RX TCP.

I'm currently doing the work in a FreeBSD user svn branch. The details are in the Wiki - http://wiki.freebsd.org/AdrianChadd/AtherosTxAgg . I currently have exactly one tester (AR5416 STA, AR9280 hostap) who is reporting excellent success. I'd obviously like a few more. :)

There's still a lot of work to be done before this can be merged into HEAD. I'm sorry to say it won't happen before 9.0-RELEASE as there are some upcoming net80211 changes which will be rather intrusive and a bit risky to throw into the release at this late stage. It may also be difficult to backport as some changes will break kernel ABI.

But don't let anyone tell you FreeBSD doesn't support 802.11n. 9.0-RELEASE may not have much support, but all the key pieces are there. Once the release has been cut, I'll do some chasing up to get the Intel, Marvell and Ralink 802.11n support updated. (If someone would like to take charge of the broadcom NIC drivers, please drop freebsd-wireless@ a line.)

The next 6 months will be very interesting in the FreeBSD 802.11 world. :)

Finally, none of this current work would've been possible without the support of the sponsor paying me to get FreeBSD's net80211 and ath support updated - Hobnob, Inc. They contacted me a few months ago to help work out kinks in the Atheros NIC they're using in FreeBSD and seem impressed enough by my work to sponsor general net80211/ath improvements which they'll likely roll into future products. So when you're using Atheros 802.11n hardware in FreeBSD and getting that nice 140-150mbit TCP throughput, please give them thanks. :)

And finally finally, Qualcomm Atheros and the Linux ath9k developers have been instrumental in this work. The documentation, reference code and general interactive discussions have allowed me to get all of this work done in such a short period of time. (Yes, I did say "Atheros", "Documentation" and "Source Code" there, in the context of open source. Honest.)

Wireless update - DFS wrapup

Now that the DFS work has been completed, tested and paid for, I guess I can now write about it.

The DFS work was sponsored by KBC Networks, a wireless product company based in the USA. The eventual aim is to integrate this DFS work into their mesh product. I can't talk any further about what's going on there, except to say that they very graciously allowed the FreeBSD work to be released back to the community.

So FreeBSD now has:

• Updated DFS master (hostap) and DFS slave (station) support in net80211;
  
• Updated regulatory domain entries for the USS ("FCC3");
• Changes to the ath(4) driver to fix corner cases in DFS master and DFS slave modes.

All of this work is now in FreeBSD-HEAD and will be available in FreeBSD-9.0.

Future work will hopefully include DFS IBSS and DFS mesh functionality. This work didn't include 802.11n DFS - but that's not too difficult to do (hint: if someone would like the mini-project, please contact me!)

Along with that was a port of the Atheros radar detection code (from Fusion, their earlier carrier codebase) which is currently proprietary. The Linux wireless developers have been working towards DFS compliance for a while, but haven't yet integrated working radar detection into any drivers. So this was a good exercise in uncharted territory to see how difficult it would be.

It turns out that it wasn't terribly difficult at all. After spending a bit of time chasing down missing bits in the FreeBSD atheros HAL driver, the third party doing said radar code porting managed to get FreeBSD doing radar detection at the same level as the commercial firmware.

During this particular exercise we discovered a few things about the software radar detection, which I think the community at large should know about.

The process of getting a device FCC/ETSI certified is just that - the whole device. This includes the NIC, the internal cabling, the enclosure, the antenna(s) and any external cabling. Maybe even whether it's indoors or outdoors, I wasn't involved in that. This likely has repercussions for any open source DFS implementation - although the DFS machinery in a specific FreeBSD release could be certified, the software based radar matching code may need tuning for the specific hardware used. So it's likely that Linux/FreeBSD can't just publish a single "ath_dfs" source module that will work for all Atheros NICs - or even a single NIC. It's likely that things will need tuning based on how a given NIC is used, the environment it's intending to be used in, and a variety of other things I haven't even thought about yet.

So if/when this does occur, the open source wireless community (FreeBSD, Linux, NetBSD, OpenBSD, DragonflyBSD, whatever..) will have to be responsible and not just simply run an "ath_dfs" radar module, assuming that it works. For complete, correct, certified behaviour, it's going to likely need the community to work with vendors and users in order to create "working, certified" combinations of hardware and software. So, if a vendor (call them U) wishes to release a new "SR-M" NIC, they could work with the open source wireless community to create a certified NIC+board+enclosure+antenna combination and publish a set of radar patterns and settings. They could leverage the proposed existing open source radar pattern matching code and simply add whatever configuration is needed. Users should then be responsible - they should only use the given radar dfs code with the correct setup. If they wish to run a modified setup, they should work with the vendor and upstream community to get things re-certified.

This way the DFS and radar pattern matching code is open source - what then changes is the radar patterns and configuration, which depends upon the NIC, cabling, antenna and environment.

For home users/developers, having a set of certified hardware combinations will make things easier for them.

For commercial vendors, if they adopt open-source FreeBSD or Linux on their platforms then (in an ideal world) they could get their equipment certified once (which as I note, they have to do anyway) and then publish the relevant radar patterns and configuration. The rest of the driver (including the radar pattern matching source and the general DFS support) would already be open source. Users can then use this when running their own kernel/distribution/OS on that platform.

I know this is all very fluffy and assumes that vendors/users act in a responsible, open manner. But I think this is what needs to occur if the open source community wishes to see stable, supported DFS regulatory compliance in their open source project.

To wrap this up, if you're a company wishing to leverage open source on their (Atheros) wireless platform and are interested in regulatory compliance, please drop me a line. I'll put you in contact with the relevant people inside Qualcomm Atheros to discuss how to best achieve this.

FreeBSD: DFS update

I've spent the last few weeks sorting out the DFS support in FreeBSD. I've made some decent progress with it however there's still a long way to go. This has been paid work and I'm glad to see increasing interest in 802.11 support under FreeBSD.

I've debugged DFS channel switching behaviour in station and access point mode. This now functions correctly in both instances.

The ath driver now behaves "better" when doing a DFS channel change. The driver would change channels and wait for the first beacon to program the beacon timers - which are then used to signal when there's a lack of beacons (and thus net80211 marks the state as "SCAN" and begins hunting for another AP.) If a channel change occured to a channel that required a CAC (clear access check) and a radar event occured, a second channel switch would occur - and there'd never be any beacons on that channel. The NIC would sit there forever waiting to hear a first beacon that never came.

I've updated the FCC3 regulatory domain to include frequency bands that require DFS.

I've also introduced some radar device setup and event parsing code into the ath HAL layer which would allow an interested party to tinker with radar detection/classification code on the AR5212 series NICs. I don't have permission to commit the radar frame decoding code for the 11N NICs - I'm working on this.

Finally, I've introduced a radar detection layer - called "ath_dfs" - which currently does nothing (hence the only module is "dfs_null".) This provides all the hooks needed to do radar detection, classification and signaling.

Now, what I haven't done:

• The project also includes working porting the radar classification code and getting it to work. This unfortunately won't be open sourced. I'm going to try and get as much of the radar hardware setup and radar event frame parsing code committed to FreeBSD so an interested party can begin tinkering with this.
• I haven't yet ported a lot of the "channel interference" support. It's there, but I haven't really fleshed it out to be useful and then used it.
  
• There's no DFS support for 11N yet - in particular, 11N HT/40 channels aren't correctly marked as "interference" or "radar"; 11N channels also aren't scanned for during DFS channel selection. That's a later project.
• I need to extend things a bit to handle the weather radar stuff when doing DFS - the ETSI requirements include different channel quiet/scan times.
• There's no support in net80211 (yet) for the DFS, TPC and Quiet elements. This is going to be required for a fully compliant DFS implementation.
• I've not investigated implementing/fixing up the DFS support for IBSS and mesh modes.
  

However, even though there are shortcomings and some missing support in the DFS support, FreeBSD-9.0 will support DFS STA mode well enough to correctly obey instructions from a DFS-compliant access point.

Unintentional side-effects - IPv4/IPv6 load balancing..

Here's a fun one:

1310397101.830 416 X TCP_MISS/200 700 GET http://www.freebsd.org/layout/images/front_get_back.png adrian DIRECT/[2001:4f8:fff6::22] image/png
1310397101.835 413 X TCP_MISS/200 851 GET http://www.freebsd.org/layout/images/front_get_tr.png adrian DIRECT/69.147.83.34 image/png

Since the ipcache code already balances outbound connections between multiple hosts, any IPv6 hosts get similarly load balanced.. between IPv4 hosts as well.

I may end up adding in logic to connect to "only v4" and "only v6" in forward.c...