Add radiotap-based packet injection capability to monitor mode

Hi folks -

This patch adds the monitor mode packet injection stuff that was talked about a week or so ago to mac80211. Using a radiotap header prepended to the injection payload was felt to be a reasonable way forward.

The patch can deal with a variable-sized radiotap header containing any fields that are understood by Linux, although currently it skips everything except antenna, power and rate selection. You just put an interface in monitor mode and direct packets at it, selecting rate and so on by using radiotap semantics.

Along with this patch I have also updated packetspammer

http://warmcat.com/packetspammer-0.3.tar.gz

to allow it to send [ radiotap + ieee80211 + payload ] packets from userspace into a Monitor mode interface. The --help and README both show how to do it. At the moment it simply injects a 54Mbps packet with a ping-type payload in it to fixed fake MAC addresses, you can see these packets from another box running in Monitor mode on the same channel.

I tested the rate action with a zd1211rw-mac80211 USB device and it seems to be happy. I'm not sure how to test the antenna selection action and didn't try to test the tx power selection action yet.

The patch is against Linville's FC7 #4 test kernel sources, which are only a few days old.

-Andy

@@ -189,6 +189,7 @@
 #define IEEE80211_TXCTL_FIRST_FRAGMENT	(1<<8) /* this is a first fragment of
 						* the frame */
 #define IEEE80211_TXCTL_TKIP_NEW_PHASE1_KEY (1<<9)
+#define IEEE80211_TXCTL_INJECTED_PACKET (1<<10) /* tx into monitor IF */
 	u32 flags;			       /* tx control flags defined
 						* above */
 	u8 retry_limit;		/* 1 = only first attempt, 2 = one retry, .. */

@@ -162,6 +162,7 @@
 	unsigned int requeue:1;
 	unsigned int mgmt_iface:1;
 	unsigned int queue:4;
+	unsigned int is_injected_into_monitor:1;
 };
 
 struct ieee80211_tx_stored_packet {

It seems rather odd to inject with radiotap headers when capturing with AVS headers. I've attached a patch which switches mac80211 to using radiotap. It's pretty much the same patch I posted a while ago, except all support for AVS on monitor interfaces was removed. Drivers need to implement radiotap for best results, but if it isn't implemented, the stack fills in a minimal radiotap header. The minimal radiotap header filling code is new in this version of the patch and I haven't had a chance to test it yet. The rate filling part might be wrong. Anyway, I recommend basing your patch on top of this one. Aside from the new default radiotap filling code, the rest is fairly solid AFAIK. I had a corresponding patch to hook up radiotap support in zd1211rw-mac80211 but it seems like I've lost it. I'll put together a new one tomorrow.

Thanks,
-Michael Wu

mac80211: Add radiotap support

From: Michael Wu <[email protected]>

---

 include/net/mac80211.h         |    3 ++
 net/mac80211/ieee80211.c       |   69 +++++++++++++++++++++++++++++++++-------
 net/mac80211/ieee80211_iface.c |    2 +
 3 files changed, 61 insertions(+), 13 deletions(-)

index 916b21b..050f126 100644
@@ -529,6 +529,9 @@ struct ieee80211_hw {
 	 * per-packet RC4 key with each TX frame when doing hwcrypto */
 #define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (1<<14)
 
+	/* Driver supports radiotap. Temporary until all drivers support it. */
+#define IEEE80211_HW_RADIOTAP_SUPPORTED (1<<20)
+
 	u32 flags;			/* hardware flags defined above */
 
 	/* Set to the size of a needed device specific skb headroom for TX skbs. */

index 3e0b4fa..51197b1 100644
@@ -199,7 +199,7 @@ void ieee80211_if_set_type(struct net_device *dev, int type)
 		break;
 	}
 	case IEEE80211_IF_TYPE_MNTR:
-		dev->type = ARPHRD_IEEE80211_PRISM;
+		dev->type = ARPHRD_IEEE80211_RADIOTAP;
 		break;
 	default:
 		printk(KERN_WARNING "%s: %s: Unknown interface type 0x%x",

Yes it seemed that radiotap on the capture part of Monitor was preferred and seen as the place to end up from the last discussion. But the itch I needed to scratch was the injection, so your patch and mine go together really well in principle and migrate the whole stack to radiotap.

Okay I will apply your code when I can resume work on this later today.
They shouldn't conflict since yours is only on the receive path and
mine only on the transmit path. I need to learn about quilt it seems.

I am monitoring from an ipw2200 box that issues driver radiotap headers and tcpdump can do a lot more with them than the PRISM2 stuff.

I posted a patch that annotates radiotap as little-endian, but I haven't seen any reaction so far.

I'm not aware of any driver that implements radiotap as native endian (at least intentionally). All implementation I know are little endian, even if it means sparse warnings (that's how I became aware of the problem with the non-annotated include file for radiotap).

Regards,
Pavel Roskin