Hello world!

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.


8 Responses to Hello world!

  1. […] Madwifi Just another WordPress.com weblog « Hello world! […]

  2. Aakash says:

    Hi Guys! You got one permanent subscriber to your posts – I’ll be watching your blog, and awaiting new posts with great eagerness 🙂 Thanks for taking initiative (and pain) to share your head with the world 🙂

    Cheers, and a great beginning! keep posting often!

  3. Carlos says:

    Hi guys,

    Great post! Loved it!! I have this project that I want to do for a class. I want to a program to simulate “virtual hosts”, they will transmit certain packets created inside the program. I am using libpcap, and have succesfully created some packets, problem is that when I try to transmit with the “virtual” mac I want to use for the host it gets denied, channel is not getting inserted in the packet nor the signal information. I guess is because the “virtual” mac is not associated with the AP. How would you suggest I associated a “virtual” mac, do I create a separate program that will create the request and send them for me or should I call a function in madwifi?? Thanks in advance…

    • Ashutosh Dhekne says:

      You have not mentioned where the packet is getting denied. I mean, does the packet go out of the source wifi card (or is it denied transmission) and the AP throws the packet away (because this MAC is not associated with the AP)? It is possible to create packets inside the madwifi driver and put whatever information you want inside the packet (particularly if you use Monitor mode for sending the packets). However, the receiver has to understand this packet and make sense of it. If the receiver in your case could be another node in monitor mode, then it is perfectly okay to create any number of “virtual” hosts and send packets from them. In the madwifi code, you will just modify the source MAC of outgoing packets to look like different “virtual hosts” are sending them; on the receiver side (which is another node in monitor mode), you can use these packets and service them. If the receiver is an AP, however, the AP will discard these packets from unknown MAC addresses. All of the “virtual hosts” must then get associated to the AP (using assoc requests and so on (look at the 802.11 protocol for association)) and then they can communicate with the AP (it really does not matter that all these packets were actually coming from the same physical device).

      You also talk about the channel and the signal information. If you use monitor mode, you will get this information for all packets on air. Also, this info is known to the receiver (rather than being inside the packet). Of course, if you are looking at the packet content anywhere after the madwifi code (such as in wireshark or ethereal), you will see a Radiotap header (or some other header) which is actually attached by the receiving madwifi code providing the channel and signal information to the above layers. I don’t exactly know, but this info may not be available if the node is not in monitor mode.

      Hope I have not confused you. Do write to us if you have any doubts.

      • Carlos says:


        Thanks for the quick reply. I will post some logs later in the weekend so I can explain better what I meant with the SSI Signal and Channel not been set in the packet.

        I have the 802.11 Standard and I am reading the section about the authentication and association, my question is, do I have to create these packets from scratch, bit by bit, or can I use a function in Madwifi to process the Association and authentication? This is for my “virtual hosts”.


  4. Guest says:


    i was going through the code of driver and according to my perception most of header adding and processing is done by the Linux files and is simply called by the driver.

    i.e. to say they are not explicitly done by driver.
    Please point me if i am wrong.

  5. vijay Wanjari says:

    Thats good information regarding madwifi drivers.
    Can u just help me out with the problem….

    I am trying to write a shell script on bt2 (backtrack -2), BT2 supports madwifi drivers. I just want to create a virtual AP(VAP) with security as WEP,WPA,WPA-2,wpa 802.1x and wpa2-80.1x.( one security at a time and hope i can 11n capability to these AP’s too)

    Then i come to know that i need hostpad installed on my bt2.It gives me error while compilation ( make).

    Do you know how can i install hostapd on my bt2( kernel version 2.6.20). Please help me out with this problem

    Vijay Wanjari.

  6. Kea says:

    This blog is really good. I am trying to implement a super Wi-Fi network using a Wi-Fi development platform and a madwifi driver. I am trying to send and receive data using the monitor mode. Any idea how I can start. I have read a couple of theses and checked few forums so I kind of have an idea of my implementation. Any help would be appreciated.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: