So 3.1 development has already started, and based on numerous user requests, one of the first tasks was adding IEEE 802.11 support. If you are someone who is interested in 802.11 support in tcpreplay, please take a few minutes to read this and write a reply. Your feedback is very important!

WiFi support is a bit more complicated then ethernet for a number of reasons:

1) Sending raw 802.11 frames is very OS/nic/driver specific. This means unlike *BSD’s BPF and Linux’s PF_PACKET, there are no standard cross-platform API’s. For many OS’s/drivers there is no way to write the 802.11 frame at all (or at least people don’t know how to do so). The good news is that there is the LORCON library which tries to support many nic/drivers, but it’s OS support is basically limited to Linux right now. Since my development platform is OS X, that makes testing difficult.

Why is this important? Well it basically means that tcpreplay won’t be able to:
a) Write raw 802.11 frames
b) Spoof source MAC addresses
c) Work without you first associating to an AP
d) Work with IEEE802_11_DLT pcaps. They’ll have to be converted using tcprewrite to 802.3 (ethernet) first.
e) Work reliably on all OS’s/nics

So I’d like to know how people plan to use tcpreplay/tcprewrite with WiFi and IEEE802_11_DLT pcap’s. Having some real world use-cases will help me understand if my current plan is “good enough” or not.

2) I’m having a really hard time finding raw 802.11 non-encrypted (WEP) frames for testing. If someone has a pcap of a IEEE802_11_DLT pcap w/o WEP, that would help me a lot in testing.

3) I’d like to know how important decrypting WEP frames is for people. You’ll need to provide the appropriate WEP key information. (ie, I’m not going to do WEP key cracking, just decryption using a user provided key). Same for WPA/WPA2. This would be mostly useful for taking a WEP encrypted pcap, decrypting it and sending it over ethernet or other non-WiFi network interface.

Thanks!