Tuesday, November 30, 2010

Saturday night @ ucc: 11n hackery

I'm going to work on the FreeBSD 802.11n support a little more this upcoming Friday night and Saturday at UCC.

My short-short term TODO list:

  1. Figure out why crypto isn't working in 11n mode - I've likely just not fully implemented something there;
  2. Hopefully I'll have the AR9220 based SR-71 cards by then - so if I do, see whether my HAL works on the AR9280 and AR9220 based NICs;
  3. Test the legacy HAL (AR5212 support at least) to make sure I haven't broken that;
  4. Make the TX path run-time configurable rather than a compile #ifdef - ie, if the card says it does 11n, use the 11n-aware TX routines;
  5. Keep breaking apart sys/dev/ath/if_ath.c into smaller parts to make this whole thing more manageable moving forward.
That's all I think I need to finish up before I begin preparation for committing this work to FreeBSD-HEAD.

Saturday, November 20, 2010

A productive night at the computer club ..

I spent most of Saturday at the UWA Computer Club, participating in their "Hardware Hacking Night". Whilst others were hacking on power supplies, coke machines and the like, I sat down to try and figure out how 11n TX works.

Which I did, around 11:30pm last night. I still have a long way to go. The AR9160 NIC seems quite happy pumping out packets all the way up to MCS15. I couldn't figure out how to make things work correctly using the 11n RTSCTS protection - if I configure that in the TX registers, no packets are ever sent. That's the next thing on my plate to figure out.

Once I figure that out, I'll worry about the 802.11n "niceities" (short-GI, HT-40 mode to name two) and then see about how to ensure that I'm interoperating (enough!) with legacy non-n devices. There's also hostap and adhoc modes to test.

Thursday, November 18, 2010

Now that exams are over ..

My university exams are over for another semester. Remind me why I put myself through this? :-)

So now that they're over, my open source work plate now is rapidly filling up again:

FreeBSD 802.11n:
  • 802.11n RX works!
  • But now I need to grovel through ath9k and figure out how 802.11n TX works.
  • I'm blissfully ignoring handling sending or receiving A-MPDU and A-MSDU frames for now. That can come (much) later once I have stable 802.11n TX/RX in station and hostap mode (which is enough of a challenge for now, thanks.)
Lusca:
  • IPv6 client support! I need to finish merging in more stuff to test.
  • Thread manager - this is an important one.
  • Find my RPM build patches and include them in the subversion tree.
Who needs sleep?

Tuesday, October 12, 2010

FreeBSD 802.11n: aiee

I've been toying with getting 802.11n working on these atheros AR9160's.

I've got somewhat working 802.11n on the receive side using my public HAL, up to MCS15. But it (currently) isn't implementing AMPDU (datagram aggregation) which is done in software, so it isn't much faster than legacy mode.

But it -does- work - in 20mhz 11ng mode:

root@OpenWrt:~# iw dev wlan0 station dump
Station 00:15:6d:84:05:52 (on wlan0)
inactive time: 0 ms
rx bytes: 41144714
rx packets: 475307
tx bytes: 1059470517
tx packets: 692698
signal: -50 dBm
tx bitrate: 130.0 MBit/s MCS 15

Thursday, September 16, 2010

bsdbox - take #1

One of the nice things about building embedded Linux "stuff" is busybox. The other is "uClibc", which isn't really the focus of this post.

I've fleshed out a basic busybox style thing based on the crunched binary stuff which generates sysinstall and the rescue binaries. Thankfully, most of the hard work (read: the hacks needed) are done for you - both in the rescue Makefile and the general FreeBSD build framework.

So, I give you "bsdbox" - a not-so-small static binary busybox style solution to help build a standalone image.

# ls -l /sbin/bsdbox
-rwxr-xr-x 1 0 0 2958668 Sep 16 17:44 /sbin/bsdbox

# /sbin/bsdbox

usage: bsdbox ..., where is one of:

ls cat dd df cp hostname kill mkdir sleep sh -sh dmesg sysctl init reboot

mount mdmfs mount_mfs mdconfig newfs ifconfig route ping true false hexdump

tail netstat chown chgrp arp hostapd hostapd_cli bsdbox


And with that, I have this TP-Link device happily running FreeBSD as a WPA-enabled wireless access point.

Combined with the GEOM uzip module, the entire filesystem (which is the above binary and a few shell scripts) - is just slightly above 1 megabyte in size. (geom_lzma will make that even smaller.)

The bsdbox stuff is in my GIT repository in "bsdbox". It's built as part of the base system and installed in /bsdbox/. The binary can then be cherry picked and built into an image with whatever symlinks are needed. There's more to do - more binaries for a start; but also making it a bit easier to configure bits than a single Makefile - but it's useful right now.

Monday, September 13, 2010

Antenna Diversity: Ubiquiti SR-2

The Ubiquiti SR-2 is a high-power 11bg card based on the Atheros AR5213 MAC. It has three antenna fittings - one UFL, one MMCX, and a third set of solder pads for a non-existent connector. The first two are treated as separate antennas and are controlled by an external antenna switch. The third looks like it's an alternative to the UFL connector.

I discovered that these cards occasionally calibrate their NF at some impossibly low level - under -100 dBm. The reason? Antenna diversity is occasionally selecting the MMCX connector as the RX antenna - and this never has an antenna attached. Tsk.

Antenna diversity also often chooses the MMCX antenna for TX. Grr.

Sunday, September 12, 2010

FreeBSD/MIPS: AR9132 and AR9100 wireless support

I've now made the wireless MAC/PHY work on my AR9132 wireless access point - the TP-LINK TR-WL1043nd.

The wireless bits are below:

ath0: at mem 0x180c0000-0x180effff irq 0 on nexus0
ath0: [ITHREAD]
eepromdata pointer: 0xbfff1000
eeprom: attaching
eeprom: allocating
eeprom: copying the data!
eeprom: endian check
eeprom: swapsies: 0
ath0: AR9100 mac 20.1 RF2133 phy 10.2

It doesn't currently like client mode - it's something to do with the channel changes and aborting some pending queued stuff isn't working. I'll have to go digging at some point soon.

But it works in hostap mode:

# ifconfig wlan0 list sta
ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
1c:4b:d6:97:ac:26 1 6 1M 32.5 15 2 32160 ES AQE WME

# ifconfig wlan0 list channels

Channel 1 : 2412 MHz 11g ht Channel 7 : 2442 MHz 11g ht
Channel 2 : 2417 MHz 11g ht Channel 8 : 2447 MHz 11g ht
Channel 3 : 2422 MHz 11g ht Channel 9 : 2452 MHz 11g ht
Channel 4 : 2427 MHz 11g ht Channel 10 : 2457 MHz 11g ht
Channel 5 : 2432 MHz 11g ht Channel 11 : 2462 MHz 11g ht
Channel 6 : 2437 MHz 11g ht

# ifconfig wlan0 list sta

ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG
1c:4b:d6:97:ac:26 1 6 54M 33.5 0 2682 45008 ES AQE WME

# ifconfig wlan0 scan

SSID/MESH ID BSSID CHAN RATE S:N INT CAPS
WLAN Lucy-Gaby 94:44:52:4b:f5:52 6 54M -65:-96 100 EP RSN HTCAP WPA WME
CACHEBOY_DA... 00:25:86:d8:7c:da 6 54M -65:-96 100 EP WPA RSN
davinayarker 00:1c:df:e4:d6:5f 6 54M -83:-96 100 EP MESHCONF MESHCONF WPS HTCAP WPA RSN WME
surbi 00:22:b0:9a:d0:ab 6 54M -88:-96 100 EPS WPA ATH WPS

I haven't yet committed the code anywhere - it's a bit of a mess. In particular:
  • There's some weird stuff surrounding the EEPROM logic determining when to swap what. The existing code assumes that a Big-Endian system requires swapping the byte order - but the EEPROM contents stored in flash are stored in big endian order already! Tsk.
  • There's also a bit of a mess in getting the EEPROM contents out from memory-mapped SPI flash into a private buffer. The linux AR9100 commit(s) mention that accessing it direct can be unreliable.
  • The AR9100 support is sprinkled throughout the AR5416/AR9160 support...
  • .. and I'm sure there's bits that I've missed in porting it from ath9k ..
  • .. and I know there's a few bits here and there which are also missing. I'll check that out later.
I'll look to tidy this code up and get it pushed into something public in the next week or so.

Update

The diff against my GIT repository is available at http://www.creative.net.au/diffs/git_ath_diff_1.diff . The patch includes where the GIT repository can be found.