Posts filed under 'madwifi'
I’m sure that no-one has noticed that I’ve been fairly silent on the blogging front for a while. I took a three month break from the Ph.D to do some work for Cambridge Silicon Radio. The experience working on a real-world project was great and the project itself was both interesting and challenging.
I am however looking forward to getting back into the Ph.D work. I’ve still got a week or so before the Ph.D kicks back in so at the moment I’m doing some driver work for RuralLink - specifically getting MadWiFi working better on the CPE/AP devices.
I spent a week or so before the CSR work started looking into performance improvements for MadWiFi. After spending quite a bit of time with oprofile I found a couple of areas in the driver which were causing a large number of PCI transactions to take place unnecessarily. Now, on a laptop or desktop platform this didn’t really make much difference. On an already resource-starved platform such as the Soekris 4526 however, this was resulting in some pretty significant overhead. A couple of patches to MadWiFi later (a couple merged upstream already, one that’s a bit more of a hack specific to our needs) and we’re seeing some much nicer throughput numbers. Off the top of my head, we went from being able to bridge about 9-10 Mbit/s of traffic over wireless through the wired ethernet to about ~15 Mbit/s.
The other neat hack we did was to create a transparent wireless bridge by hacking the ad-hoc demo mode to use 4-address 802.11 frames. This could already be done in other modes, but we really like ad-hoc demo due to its utter simplicity - no associations, no beacons, nothing - just passing frames.
Right now we’re working on implementing our own rate control algorithm. We seem to run into far too many problems on our networks with rate control and Perry came up with a neat idea - as is his wont - so we’re running with it. At the same time we’re looking at using it as a chance to collect large amounts of performance data to give us some deeper knowledge as to what’s going on on our networks. Hopefully lots more info on that soon.
At some point in the (very) near future I need to start thinking about the Ph.D again - I’m starting to think that I should be putting more of a measurement focus into it, but I need to nail down a few ideas first. And maybe play a bit of Guitar Hero as well 
August 9th, 2007
Initial results from playing with the new noise functions in the HAL are pleasing. I initially added a call to ath_hal_process_noisefloors to the scan_end callback, however that wasn’t being called often enough (i thought it was supposed to be doing background scanning? oh well), so the noise wasn’t updating very often. I’ve decided for now to call it at the end (or maybe it should be the start) of a receive interrupt. The noise is then retreived from the HAL and stored in the ath_softc struct. Here is a graph showing a trace of about 5 mins worth of monitoring. You can see that the noise values are changing, and that they look sensible. This is from initial testing, so the new noise code isn’t hooked into any of the kernel wireless extensions - the only way to get measured noise out is via a radiotap trace 
Next is to figure out what is happening with the data points whose signal values are below the noise floor. Once that’s done I’ll start integrating all of this into the driver proper, which is going to be easier said than done. Hopefully though it should lead to a very useful contribution to madwifi.
September 13th, 2006
So after a couple of revisions, I’ve pretty much got radiotap in libtrace sorted. As well as that, I’ve implemented an abstract interface for dealing with wireless information in libtrace, so the application doesn’t need to know whether the trace is based on radiotap or prism, it can just call one of the trace_get_wireless_* functions. At the moment this only works for radiotap traces, but prism shouldn’t be too much of an issue to get going. I think the interface has turned out quite well, as it guarantees that any values returned are in host byte order, are of a certain type, and gracefully deals with unsupported link-types (like prism at the moment) as well as fields that aren’t available.
I’ve also submitted a patch to madwifi to include the absolute signal and noise levels in the radiotap header, as the only signal information that was present previously was the rssi. Hopefully that will be committed soon.
Had a look this evening at whether we can get any sort of measured noise levels out of the HAL. The atheros descriptors (structures that are used to send frames to and from the HAL and which all information is taken from) only contain a field for rssi, which is db relative to a fixed reference (in this case the noise floor of -95 dBm). So the atheros descriptors don’t tell us much. None of the HAL functions seem to return anything useful, but interestingly there is a “new” public HAL function - at least it was introduced since the madwifi project last updated the HAL-usage wiki page…
/*
* Calibrate noise floor data following a channel scan or similar.
* This must be called prior retrieving noise floor data.
*/
extern void __ahdecl ath_hal_process_noisefloor(struct ath_hal *ah);
Interesting… this function isn’t called anywhere in madwifi. I wonder what it does… it certainly doesn’t return anything - the only thing it could do is update a field in the hal struct… which leads us to…
int16_t __ahdecl(*ah_getChanNoise)(struct ath_hal *, HAL_CHANNEL *);
Which also isn’t called anywhere in madwifi, nor is it documented in the madwifi wiki page. It seems this function has slipped in under the radar. Unfortunately I’ve turned off my test box at work, so I can’t play with it from home. I think with this new information and a bit of hacking I’ll be able to get actual measured noise data, even if it is only updated once per scan, or similar. A patch to end the silly “noise is always -95 dBm” in madwifi would be really really cool. Can’t wait to get hacking on that!
I also have a patch in the works to add a /proc entry to monitor vaps to allow us to see error frames, such as frames that failed their fcs, were too short, etc.
Well, that was a long post. It’s been a very productive week and next week is looking very interesting indeed.
September 8th, 2006
Spent some time today figuring out how to get low-level radio information from Atheros-based wireless cards. A madwifi device can be set to a pretty standard monitor mode, with a choice of several encapsulations. 802.11 is better than nothing, but doesn’t give the physical layer information I’m after. Radiotap and Prism monitoring headers are also supported, as well as output of the actual atheros descriptors used by the driver/HAL which contain HAL status information after each descriptor is processed by the hardware. The atheros descriptor format is something I’d like to look at later. With a choice of Prism or Radiotap, I’m going with Radiotap as it seems much saner.
Radiotap allows us to on a per-packet basis get RSSI (signal in db above noise floor), timing information (a 64-bit value in microseconds indicating when the first bit of the MPDU hit the MAC), rate, channel, and most importantly (for me at least) the 802.11 frame-check sequence which is usually stripped off the end of the frame before being passed up.
Unfortunately, it seems that pcap doesn’t know about the radiotap ARPHRD used by madwifi, which is fair enough I guess, as neither libc nor linux have defined an ARPHRD for radiotap yet. What this means is that tcpdump will fall back to linux SLL and you’ll end up with an unusable trace.
Enter libtrace. libtrace doesn’t have radiotap support yet, but after a bit of a chat with Perry I’ve got it recognising the ARPHRD madwifi uses and I can now open a trace on a live device and get the radiotap headers. Right now I’m just grabbing each frame and manually casting to a radiotap structure, but I plan on implementing proper radiotap support in libtrace over the next while, which should be interesting and allow us to do fun things like run tracedump over a radiotap trace.
So there’s a few things on my todo list now…
- Implement proper radiotap support in libtrace
- Add a /proc interface to madwifi monitor vaps to enable passing up frames that fail their FCS (and other error frames)
- Figure out exactly what does/doesn’t work when creating a monitor mode vap when there’s already a sta/ap/adhoc vap around
- Create libtrace packages for crcnet-bpc
- Grab some decent traces from CRCnet with radiotap headers enabled
- Analyse
That should keep me busy for a while at least… Hopefully this work will also help with things like the link-testing stuff that Ivan is up to at the moment.
September 6th, 2006
