We have been working on the madwifi driver as a part of our MTech thesis in creating a TDMA wireless mesh network. We came across some interesting facts and hacks in the drivers. We found that the documentation of the drivers could be a little better if we explain what we have understood. In this blog, we approach the problem of understanding the driver from a newbie perspective. Hope you find the information helpful. Please do write to us your queries or comments to our posts.
Both authors were students at the Computer Science and Engineering Department at IIT Bombay, India. Nirav now works for LSI in Pune and Ashutosh works for Intel in Bangalore. The discussion in the posts is about madwifi 0.9.4, though it may be equally applicable to other versions. Most experiments are done on a Soekris board with Ubiquity wifi cards.
Madwifi 
Hi Guys!
I just read your blog and it was very nice. I am very interested in the possibility of disabling the backoff-times of madwifi. I am testing this with a simple C-program, that just sends out UDP-frames with a total size of 140 bytes (measured with wireshark) and then sleeps for 3ms. This is done in an endless loop.
While sniffing this with a thrid wireless card in monitor mode, I can see packets being delayed a lot (some packets are sent out after 20 ms or even slower). After lots of investigation, I am quite sure, that this is due to the backoff time.
If I want to transmit as fast as I can and disable the CSMA/CA-mechanisms, I read in your blog, that activating the “txcont”-iwpriv could help. But when I did so, the measured times did not decrease. I issued the command on the AP-side.
Could you telle me in detail, how you have been able to get such times down?
Thanks a lot in advance,
Dennis
I will phrase my answers in steps. First let us speak about sniffing packets using a third device in monitor mode.
1. Typically you must be using a software such as Wireshark to do this sniffing. I must say that it is not a very accurate method of knowing the exact packet reception time. If you have access to the madwifi driver source code, you must record the packet reception time as returned from the hardware at the rx_poll (or rx_tasklet in the 0.9.4 driver) function. You should use ds->ds_rxstat.rs_tstamp (in 0.9.4 and something similar in the trunk version) to get a 15 bit hardware reception timestamp. Then you must call the ath_extend_tsf() function to convert this 15-bit value to a 64 bit time stamp. This is the most accurate way of getting received time stamps at the driver level.
2. The best method is to check on an oscilloscope. Just connect your card to the input of a modern spectrum analyzer that works in the 2.4GHz frequency range, and start your transmission. Check the inter-packet gap on the oscilloscope screen.
Now let me talk about continuous transmissions.
1. Search for cwmin in the entire if_ath.c file and change all cwmin and cwmax values to 0.
2. Also change all aifs values to 0.
3. Set sc->sc_channoise to a very high value in the interrupt routine (this will disable CCA (actually some more things may be needed to be done for disabling CCA, I am not currently sure about it)
4. Now, on the prompt, turn off burst mode and fast frame mode by using iwpriv athx burst 0 and iwpriv athx ff 0
5. Also put the line qi.tqi_qflags |= HAL_TXQ_BACKOFF_DISABLE; in the ath_txq_setup function.
6. Set #define ATH_TXBUF 5000 /* number of TX buffers */
You must be good to run your program now, but I would still ask you to check it on a spectrum analyzer first (typically such costly equipment is a part of some lab in the electronics department of a university).
txcont actually sends garbled packets continuously on air. You may want to look at the txcont_configure_radio function (I am forgetting the exact name of the function, but just search for txcont and you will find the one I mentioned here.) It does a lot of steps to ensure absolutely back to back transmission. You may recreat that setting and just send your own packets (after commenting out the code that actually sends the garbled packets.)
hello
I must thank you for your effort in sharing the blog. I find it very informative & imbibed a lot from them.Currently I am working on the optimisation of madwifi driver for my project.where specifically I am working on adhoc mode with the goal to make the driver go to RUN state after INIT, no scanning , no authentication & association.
My question is how can i trick the driver with the software changes? second How to send unicast,multicast & beacon control or management frame, how is it done.. to be precise complete picture from PHY to MAC with respect to the madwifi functions.
Thanks in advance , awaiting for your reply asap.
By what you have described, “go to RUN state after INIT, no scanning , no authentication & association”, I think the monitor mode or ahdemo mode might be more suitable for you.
About the full picture from the MAC to the PHY, Nirav’s thesis and the presentation will be useful for you.
http://www.cse.iitb.ac.in/alumni/~nirav06/project.htm
Particularly slides 16-19 in his presentation are useful for you. Let me know if you want any specifics.
Hello
Thank you so much for the help.I still have few questions unanswered, to give you the background I am using adhoc mode and 802.11p protocol charter I have to follow where I have to respect the CSMA protocol and the corresponding mechanism like backoff ,I cant use TDMA here.so I need to disable/timeout ACK and disable RTS/CTS .
1.since ACK is in the hardware, can you tell me which file and command i need to follow to time out it.
2. if I disable/timeout ACK at the transmitter what would happen when i receive an ACK from the receiver.
3. after disable/timeout the transmitter will keep on sending the same message again or the new one in the queue.
4.lastly how can i disable RTS/CTS , i mean which file and command.
Since i have a project deadline to meet, these answers are very much critical to me.I need your guidance.If possible let me which time suits your convenience so that i can call you & explain everything in detail. Provided you give me your contact no.
thanks a lot
Disabling ACK: In madwifi,
ath/if_ath.c file.
In function ath_tx_start(), write
flags |= HAL_TXDESC_NOACK;
just before call to ath_hal_setuptxdesc()
Also, write the following at the end of ath_reset() function.
#define AR5K_AR5212_DIAG_SW 0x8048
OS_REG_WRITE(ah, AR5K_AR5212_DIAG_SW, 0x00000002);
#undef AR5K_AR5212_DIAG_SW
To understand how it works, you will have to dig into the HAL code.
Please note that we have tested this only in monitor mode and we used raw packets for send and receive. You will have to verify that it works by using a network monitor package like wireshark to see that indeed no acks are generated.
ath_hal_setuptxdesc can also be used for setting rts/cts rate and duration. But you are on your own in this regard because we used monitor mode to stop RTS/CTS.
Hope this helps.
I am a PhD candidate and I found the information given in this website really useful.
Keep the good work!
Hello Ashutosh, many thanks for posting this on your blog. Wrt your replies 1 & 3, I have one question: Do I need to compile MadWifi after making the above changes? Would appreciate your early response.
I assume you are talking about my replies starting with “I will phrase my answers in steps…” and “Disabling ACK: In madwifi…”
Yes, you will need to compile the driver for these changes. However, you should not be afraid of having to compile the source code. Once you get all things going, it takes only a few minutes and I remember we used to compile the code many times in a day.
The madwifi official page is your friend. Also check this: http://madwifi-project.org/wiki/UserDocs/Makefile
Yes – your assumption is correct – i was referring to the said steps. Thank you very much for your reply. Shall take it up from here & let you know how it goes.. Have a nice day.
Hi Ashutosh. Here’s a quick look at the results:
1. Compilation was successful. Followed the regular MadWifi instructions for re-install after unloading existing one.
2. RTS/CTS was apparently not observed in trace capture over wireshark. Note: I’m setting up two Peer to Peer links in Ad-hoc mode
3. However Beacons were freely floating around! 🙂 (Intended behavior I guess)
4. Unable to ascertain the ACK behavior, as wireshark capture shows periodical 802.11 ACKs bearing only Destination MAC. Frequency is very less but strangely enough such infrequent ACKs seem to have no source MAC but various destination MACs including the 2 adhoc nodes of my setup. Could it be possibly arising out of the card with monitor mode?
P.S : The compiled driver above was installed only in one of the Adhoc peers. I haven’t tried replicating it over to the other node as I require the other node to be in strictly Rx only mode. And this is where I’m stuck presently as ‘monitor’ mode disables communication between L2 & higher layers. Please help.
Hello Ashutosh, was wondering if you had a chance to read my comment above. Would be of great help if you could share some thoughts to unblock the issue around Rx in monitor mode.
Sorry, I did not get a chance to think about the problem you mentioned. Can you please elaborate as to what problem you are facing? In monitor mode, transmission of packets is a big deal. However, receiving of packets should not be a problem. Maybe I am missing something. Can you please explain exactly what you want to do?
Thanks Ashutosh for your prompt reply. To elaborate further:
What I’m trying to achieve:
********************************
1. Tx in ‘normal’ mode with CSMA/CA disabled & with Ad-hoc mode of operation
2. Rx in ‘monitor’ mode with ability to pass on packets to L3 & higher layers of the OSI stack.
Hope this explains the situation. Nevertheless, please let me know in case you have further queries.
Thank you once again.
Hello Ashutosh: sorry if I have to bother you on this. I happened to go through Nirav’s ‘Hello World’ post(https://madwifi.wordpress.com/2009/04/05/hello-world/). It occurs to me, that you guys have been successful in establishing communication over ‘monitor’ mode. However, I’m feeling lost here as I’m not sure how to proceed to adapt it only for the Rx path. Looking forward for your help & guidance.
Thanks,
Ansuman
Hi Ansuman,
We also faced a similar problem. I will reply to you in some time.
Hi Ansuman,
In the monitor mode, applications such as Wireshark will show you all the packets received by the device. However, the received packets are modified by the madwifi driver and therefore the network layer “owner” of these packets does not see them.
Some code level modification has to be done for the above layers to see the packets. In our thesis work, we achieved proper communication between two nodes both working at monitor mode.
Nirav has properly documented the steps we took in his second stage report here: http://www.cse.iitb.ac.in/alumni/~nirav06/i/Stage2_Report.pdf
Particularly, look at the section “Monitor Mode Changes” and the figure that follows. The required changes must be made in the code and the code recompiled. Moreover, since you are using the ad-hoc mode as a sender, you might see some slight variation in the received packet from what we have described in the report.
Our post on the TX RX path will also be very useful for better understanding what to check. madwifi.wordpress.com/2009/04/16/tx-rx-path/
BTW, the code we used and therefore the above post is more than a couple of years old. A lot might have changed and we cannot currently help you with that. However, the source code of our project is available on request. This project was also published as a paper in the NSDR 2009 conference (http://dritte.org/nsdr09/files/nsdr09_camera/s2p4_dhekne09nsdr.pdf).
Hi Ashutosh,
Sorry: I meant to reply earlier. Many thanks for your detailed reply above. I’m in the process of going through the same to figure out the remedy.
Thanks again for your time.
Regards,
Ansuman