libtrace and madwifi progress
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.
Add comment September 8th, 2006