My friend Nirav Uchat and I have been involved in a project that uses madwifi driver for communication between wireless nodes. This make us no authority on madwifi drivers, but since we have used and tapped into the intricacies of the driver for sometime now, we would like to document what we know.
The madwifi driver sits between the kernel’s network layer and the Atheros hardware abstraction layer (HAL). Above the driver, in the kernel code, nothing is known about the physical interface over which the network packets are to be sent. This changes at the driver, however. The driver is fully aware of the kind of hardware and the physical layer over which the packets are to be delivered. The driver implements most of the components of the MAC standards, but leaves the most time-sensitive functions to the HAL and the hardware chip. Any possible configuration that the hardware offers, must be exposed up to the driver, otherwise, it is almost of no use. The driver exposes some of the functionalities that are available to it through ioctl calls and entries in the /proc system. All users of the madwifi drivers, who wish to turn into developers, must have a good knowledge of the functionalities already exposed by the iwpriv directives and through the /proc entires. It took us some time, and we tried to do all our modifications from inside the driver code, but it is much simpler to do it from the exposed calls. The madwifi project website (userdocs) provides descriptions of many such iwpriv directives.
In this blog, we shall walk you through the transmit and receive path of a packet inside the madwifi code. We shall show you ways to trick the driver into doing what you want it to. Such idiosyncrasies may be needed for your academic project, or you may just want to be playful. Using what is given in this blog, it might be possible to spoof MAC addresses and exhaust all the access points around. However, we caution you from doing any such thing outside of an academic setting since there are stringent laws in most countries about all such things. This blog wants to aid you in your wireless project; not turn you into crooks. Further, we do not claim that all information written here is perfect, and we do not take any responsibility (or credit) of the consequences of using our suggestions.