Saturday, November 26, 2011

FreeBSD on the TP-Link TL-WR1043nd!

I've now included (almost) all of the support needed to run FreeBSD natively on the TP-Link TL-WR1043nd. It's a 3-antenna, 2x2 stream 2.4ghz 802.11n AP which you can get for under AUD $100.

It supports hostap mode (which is what I bet most of you want to use) and I'm currently using it at home alongside my Ubiquiti Routerstation Pro based hostap (which is what I use to test out all the other pre-11n and 11n NICs that I currently own.)

I currently get around 50mbit TCP throughput - but I leave full FreeBSD-HEAD debugging on. I'm sure I can push the unit closer to 100mbit. (Compare to the Routerstation Pro + AR9160 hostap - where I routinely get 160mbit of TCP throughput.)

What works (read: what I've tested):
  • Ethernet (at least the WAN port);
  • Wireless - 802.11bgn - 20/40mhz operation as well as legacy operation (and both, if that's what you need);
  • Serial console - if you've soldered in one.

The firmware image stores the configuration in a 64k flash partition which is read upon boot. You can modify files in /etc and then save these to flash via "cfg_save".

What isn't supported:
  • The onboard switch - so I believe the only port available at the present moment is the WLAN port;
  • The GPIO lines aren't being configured, so the WLAN, status and USB/QSS buttons don't function.
I haven't tested out Multi-SSID mode yet. The earlier AR9130 revisions have some issues with multi-SSID mode and handling block-ack tracking, so I _think_ I'll need to somehow disable aggregation on the second and later VAP interfaces. Just keep that in mind if you're tinkering.

Further details about the hardware and how to build the software for yourself can be found here in my FreeBSD wifi development project wiki.

No, I won't (yet) be putting up firmware images for people to test. Things are changing quite rapidly and there's no easy way to reflash a unit once you've placed FreeBSD on it - you'll need to have added a serial console to the device.

FreeBSD 802.11n update: 27 November 2011.

I've merged in most of the reset related fixes from my git tree into FreeBSD-HEAD. This means that normal resets (eg stuck beacon, calibration resets, etc) shouldn't drop frames any longer.

Frames are still dropped during things like channel/operation mode changes and channel scanning (which does do a channel change.) I'll have to look into that at a later stage. If you're using this in station mode you will likely need to disable background scanning or your aggregation sessions may occasionally drop. You'll have random messages logged when frames are dropping during a flush or reset, so just check your system dmesg log for anything from the ath driver.

I'll be next working on correctly handling failed/filtered frames and then adding some transition stuff to net80211 so the TIM/ATIM bitmaps can be kept correctly up to date. This should fix some of the power saving issues that I'm sure exist.

Unfortunately transmitting BAR frames is still quite a bit off. There's a lot more tidying up that I'd like to do before I start down the path of handling BAR TX, including trying to figure out how to better handle packet transmission and reception when the NIC is off-channel (eg when doing a background channel scan.)

I also have a long list of things I'd like to do to the rate control code and all the surrounding code which sets up rates and creates aggregates. The code I ported/wrote is a little too verbose and duplicate-y for me. That likely will occur after the christmas break.

Enjoy!

Wednesday, November 16, 2011

FreeBSD is now doing (even more) 802.11n..

I held off merging in my 802.11n work as much as possible but I decided that I'd like to get it done before the end of the year. Even though 9.0-RELEASE is still around the corner, I decided that it would be better to merge in what I have into -HEAD and then tidy that up then wait for what could be a few more months.

So, it's in there, bugs and all, supporting both station and hostap mode. No, wds, adhoc, mesh and TDMA aren't currently supported (I have enough bugs to worry about for the time being, without trying to debug the other operating modes. But I'd like to.)

What works:
  • TX and RX aggregation!
  • The rest of the 802.11n negotiation stuff, mostly thanks to Bernhard Schmidt who fixed up a lot of the net80211 quirks.
  • Lots of ANI changes which hopefully make noisy environments more stable.

What doesn't yet work:

  • Interface resets cause frames to be dropped from the RX and TX queues. This messes up aggregation and causes sessions to hang. I'm fixing that up in a git branch at the moment.
  • BAR TX - I'll implement BAR TX soon - it's just tricky to get right.
  • Filtered frames - ie, TX failed frames from the hardware. Instead of the current method of "always try", the hardware supports failing the current and subsequent frames in a set. That way a hostap seeing a station going into power saving mode can quickly abort all TX frames to said station and then only retransmit them when the station indicates it's again awake. If I don't do this then the hardware will constantly fail a lot of frames, causing BAR frames to be TXed when they likely shouldn't be.

But it's enough to try. So if you have an AR5416, AR9160, AR9220, AR9280, AR9285, AR9227 or AR9287, give it a whirl. If you have a pre-11n NIC then please, give it a go too. I'd like to ensure that the hardware support for earlier chipsets hasn't broken.

If you'd like to use this in production on a hostap then please keep in mind that power saving support isn't entirely functional and featured, so stations which go into frequent power saving mode may have some performance issues. I'll tinker with this some more soon.

Finally, thank you very much to Hobnob, Inc. for sponsoring this work and Qualcomm Atheros for providing me source code, documentation and assistance in understanding how all of this works.

Saturday, October 29, 2011

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"

Sunday, September 25, 2011

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
*/

Monday, September 12, 2011

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.

Sunday, September 11, 2011

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