Skip to contentSkip to conversation

Radiotap injection for Monitor Mode

PATCH In review [email protected] 3 participants 9 messages Jun 11, 2007

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

cover Radiotap injection for Monitor Mode

Patches add ability to inject packets down a monitor mode interface for transmission according to a prepended radiotap header.

For injecting packets, the you issue a packet using libpcap or a SOCK_PACKET socket down an interface to the wireless device that is in Monitor Mode. The packet has a normal radiotap header prepended to the IEEE80211 header. The radiotap header is variable length depending on what the user wants to specify, currently the transmit rate, power and antenna can be specified using normal radiotap semantics. Any other entries are skipped.

The radiotap parser is broken out into its own file under cfg80211.

A usermode app packetspammer is available from here

http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer

which allows easy injection of these packets from the commandline. At the moment it loops issuing packets at a variety of rates which can be seen from another machine's monitor mode interface on the same channel. There are instructions for build and using it on the page above.

Currently it has been tested for both rx and tx using zd1211rw-mac80211.

The patches are based against current wireless-dev.

I also added some documentation files which explains how to use the injection functionality and radiotap header notes.

#1 lore raw

PATCH 1/4 mac80211: Monitor mode radiotap injection docs

From: Andy Green <[email protected]>

---
 Documentation/networking/mac80211-injection.txt |   59 +++++++++++++++++
 Documentation/networking/radiotap-headers.txt   |   79 ++++++++++++++++++++++++
 2 files changed, 138 insertions(+)
Documentation/networking/mac80211-injection.txt new file +59 -0
Index: wireless-dev/Documentation/networking/mac80211-injection.txt
===================================================================
@@ -0,0 +1,59 @@
+How to use packet injection with mac80211
+=========================================
+
+mac80211 now allows arbitrary packets to be injected down any Monitor Mode
+interface from userland.  The packet you inject needs to be composed in the
+following format:
+
+ [ radiotap header  ]
+ [ ieee80211 header ]
+ [ payload ]
+
+The radiotap format is discussed in
+./Documentation/networking/radiotap-headers.txt.
+
+Despite 13 radiotap argument types are currently defined, most only make sense
+to appear on received packets.  Currently three kinds of argument are used by
+the injection code, although it knows to skip any other arguments that are
+present (facilitating replay of captured radiotap headers directly):
+
+ - IEEE80211_RADIOTAP_RATE - u8 arg in 500kbps units (0x02 --> 1Mbps)
+
+ - IEEE80211_RADIOTAP_ANTENNA - u8 arg, 0x00 = ant1, 0x01 = ant2
+
+ - IEEE80211_RADIOTAP_DBM_TX_POWER - u8 arg, dBm
+
+Here is an example valid radiotap header defining these three parameters
+
+	0x00, 0x00, // <-- radiotap version
+	0x0b, 0x00, // <- radiotap header length
+	0x04, 0x0c, 0x00, 0x00, // <-- bitmap
+	0x6c, // <-- rate
+	0x0c, //<-- tx power
+	0x01 //<-- antenna
+
+The ieee80211 header follows immediately afterwards, looking for example like
+this:
+
+	0x08, 0x01, 0x00, 0x00,
+	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0x13, 0x22, 0x33, 0x44, 0x55, 0x66,
+	0x13, 0x22, 0x33, 0x44, 0x55, 0x66,
+	0x10, 0x86
+
+Then lastly there is the payload.
+
+After composing the packet contents, it is sent by send()-ing it to a logical
+mac80211 interface that is in Monitor mode.  Libpcap can also be used,
+(which is easier than doing the work to bind the socket to the right
+interface), along the following lines:
+
+	ppcap = pcap_open_live(szInterfaceName, 800, 1, 20, szErrbuf);
+...
+	r = pcap_inject(ppcap, u8aSendBuffer, nLength);
+
+You can also find sources for a complete inject test applet here:
+
+http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer
+
+Andy Green <[email protected]>
Documentation/networking/radiotap-headers.txt new file +79 -0

79 lines not on this page · raw message

#2 lore raw

PATCH 2/4 mac80211: Define present bitmap extend bit mask

In reply to [email protected]

Used to detect if the field presence mask is extended

---
 include/net/ieee80211_radiotap.h |    2 ++
 1 file changed, 2 insertions(+)
include/net/ieee80211_radiotap.h +2 -0
Index: wireless-dev/include/net/ieee80211_radiotap.h
===================================================================
@@ -90,6 +90,8 @@ struct ieee80211_radiotap_header {
 				 */
 };
 
+#define IEEE80211_RADIOTAP_PRESENT_EXTEND_MASK 0x80000000
+
 /* Name                                 Data type    Units
  * ----                                 ---------    -----
  *
#3 lore raw

PATCH 3/4 cfg80211: Radiotap parser

In reply to [email protected]

Generic code to walk through the fields in a radiotap header, accounting for nasties like extended "field present" bitfields and alignment rules

Try #2
- added sanity check to extended present bitmap u32 walking code - disallow possibility to walk past the end of the radiotap header length

Try #1
- Based on Johannes Berg's comments, broke out the radiotap parsing into its own file as part of cfg80211
- From same comments, added mask constant for b31 of arg presence bitfield to ieee80211_radiotap.h
- Fixed subtle but nasty bug with alignment: args in the radiotap area are aligned *relative to the start of the header* now. The header is not guaranteed to align to anything (it is randomly in an skb data area).

===================================================

---
 include/net/cfg80211.h  |   47 +++++++++
 net/wireless/Makefile   |    2 
 net/wireless/radiotap.c |  236 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 284 insertions(+), 1 deletion(-)
include/net/cfg80211.h +47 -0
Index: wireless-dev/include/net/cfg80211.h
===================================================================
@@ -74,6 +74,53 @@ struct key_params {
 	u32 cipher;
 };
 
+
+/* Radiotap header iteration
+ *   implemented in net/wireless/radiotap.c
+ *
+ * call __ieee80211_radiotap_iterator_init() to init a semi-opaque iterator
+ * struct ieee80211_radiotap_iterator (no need to init the struct beforehand)
+ * then loop calling __ieee80211_radiotap_iterator_next()... it returns -1
+ * if there are no more args in the header, or the next argument type index
+ * that is present.  The iterator's this_arg member points to the start of the
+ * argument associated with the current argument index that is present,
+ * which can be found in the iterator's this_arg_index member.  This arg
+ * index corresponds to the IEEE80211_RADIOTAP_... defines.
+ */
+/**
+ * struct ieee80211_radiotap_iterator - tracks walk thru present radiotap args
+ * @rtheader: pointer to the radiotap header we are walking through
+ * @max_length: length of radiotap header in cpu byte ordering
+ * @this_arg_index: IEEE80211_RADIOTAP_... index of current arg
+ * @this_arg: pointer to current radiotap arg
+ * @arg_index: internal next argument index
+ * @arg: internal next argument pointer
+ * @next_bitmap: internal pointer to next present u32
+ * @bitmap_shifter: internal shifter for curr u32 bitmap, b0 set == arg present
+ */
+
+struct ieee80211_radiotap_iterator {
+	struct ieee80211_radiotap_header *rtheader;
+	int max_length;
+	int this_arg_index;
+	u8 * this_arg;
+
+	int arg_index;
+	u8 * arg;
+	__le32 *next_bitmap;
+	u32 bitmap_shifter;
+};
+
+extern int ieee80211_radiotap_iterator_init(
+   struct ieee80211_radiotap_iterator * iterator,
+   struct ieee80211_radiotap_header * radiotap_header,
+   int max_length
+);
+
+extern int ieee80211_radiotap_iterator_next(
+   struct ieee80211_radiotap_iterator * iterator);
+
+
 /* from net/wireless.h */
 struct wiphy;
 
net/wireless/Makefile +1 -1
Index: wireless-dev/net/wireless/Makefile
===================================================================
@@ -1,5 +1,5 @@
 obj-$(CONFIG_WIRELESS_EXT) += wext.o
 obj-$(CONFIG_CFG80211) += cfg80211.o
 
-cfg80211-y += core.o sysfs.o
+cfg80211-y += core.o sysfs.o radiotap.o
 cfg80211-$(CONFIG_NL80211) += nl80211.o
net/wireless/radiotap.c new file +236 -0

236 lines not on this page · raw message

maintainer
#4 lore raw

Re: [PATCH Try#8 3/4] cfg80211: Radiotap parser

Hi Andy,

Thanks for the repost.

Quoted 4 lines

+/* Radiotap header iteration
+ * implemented in net/wireless/radiotap.c
+ *
+ * call __ieee80211_radiotap_iterator_init() to init a semi-opaque iterator

Quoted 8 lines

+ * struct ieee80211_radiotap_iterator (no need to init the struct beforehand)
+ * then loop calling __ieee80211_radiotap_iterator_next()... it returns -1
+ * if there are no more args in the header, or the next argument type index
+ * that is present. The iterator's this_arg member points to the start of the
+ * argument associated with the current argument index that is present,
+ * which can be found in the iterator's this_arg_index member. This arg
+ * index corresponds to the IEEE80211_RADIOTAP_... defines.
+ */

I don't think this will show up in the kdoc output, but it sure would be nice. Maybe it could be part of the description of ieee80211_radiotap_iterator as a 'how to use this iterator' section (see kernel-doc-nano-HOWTO.txt, it talks about sections)? Or maybe as kernel-doc for the functions themselves.

Quoted 2 lines

+/**
+ * ieee80211_radiotap_iterator_init - radiotap parser iterator initialization

Oh, you have kerneldoc comments in the source file. Does anyone know which is preferable? I usually put everything into the header file that is not implementation-detail.

net/wireless/radiotap.c line 79

Quoted 2 lines
net/wireless/radiotap.c new file +2 -0
+		 * no need to check again for blowing past stated radiotap
+		 * header length, becuase ieee80211_radiotap_iterator_next
                                    ^^^^^^^

typo

Quoted 1 line

+ * care of alignment handling and extended present fields. interator->this_arg

typo: "interator", also I don't understand why you would want to change this_arg?

johannes

#5 lore raw

Re: [PATCH Try#8 3/4] cfg80211: Radiotap parser

Quoted 23 lines · Johannes Berg

Hi Andy,

Thanks for the repost.

Quoted 4 lines

+/* Radiotap header iteration
+ * implemented in net/wireless/radiotap.c
+ *
+ * call __ieee80211_radiotap_iterator_init() to init a semi-opaque iterator

Quoted 8 lines

+ * struct ieee80211_radiotap_iterator (no need to init the struct beforehand)
+ * then loop calling __ieee80211_radiotap_iterator_next()... it returns -1
+ * if there are no more args in the header, or the next argument type index
+ * that is present. The iterator's this_arg member points to the start of the
+ * argument associated with the current argument index that is present,
+ * which can be found in the iterator's this_arg_index member. This arg
+ * index corresponds to the IEEE80211_RADIOTAP_... defines.
+ */

I don't think this will show up in the kdoc output, but it sure would be nice. Maybe it could be part of the description of ieee80211_radiotap_iterator as a 'how to use this iterator' section (see kernel-doc-nano-HOWTO.txt, it talks about sections)? Or maybe as kernel-doc for the functions themselves.

Quoted 6 lines
Quoted 2 lines

+/**
+ * ieee80211_radiotap_iterator_init - radiotap parser iterator initialization

Oh, you have kerneldoc comments in the source file. Does anyone know which is preferable? I usually put everything into the header file that is not implementation-detail.

We mostly put kernel-doc into source files (i.e., not header files). We use kernel-doc in header files for inline functions, macros, structs, unions, etc., but function kernel-doc blocks are meant to immediately precede their functions.

Signature · 2 lines
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
author
#6 lore raw

Re: [PATCH Try#8 3/4] cfg80211: Radiotap parser

In reply to Johannes Berg

Johannes Berg wrote:

Hi Johannes -

Quoted 4 lines
Quoted 1 line

+ * care of alignment handling and extended present fields. interator->this_arg

typo: "interator", also I don't understand why you would want to change this_arg?

Thanks for the comments which I addressed in try #9.

iterator->this_arg can make sense to increment when you are walking through one of the compound arguments, like the channel one, the comment means you don't have to take care to preserve it during the processing of any argument in your loop.

I did move the function comments into cfg80211 but I didn't prefer it and when I read Randy's take I moved them back.

-Andy

#7 lore raw

PATCH 4/4 mac80211: Monitor mode radiotap-based packet injection

In reply to [email protected]

From: Andy Green <[email protected]>

Try #6
- Accounted for various comments from Johannes Berg
- Radiotap parsing is moved to cfg80211 as requested in a separate patch

Try #5
- De-indent last few indented comments

Try #4
- All from Michael Wu's feedback: further style heresies removed
- took account of radiotap arg alignment requirement. n-byte arg must be placed on n-byte boundary using padding where necessary

Try #3
- moved to Michael Wu's method of tracking if we came in on a monitor interface by using ifindex
- removed older proposed monitor interface tracking method and flags
- style fixes
- removed duped #include that is present in Michael Wu's patch already

Try #2
- took Michael Wu's advice about better tools and basing on wireless-dev
- took Luis Rodriguez's advice about coding style makeover
- took Pavel Roskin's advice about little-endian radiotap

---
 net/mac80211/ieee80211.c |  209 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 199 insertions(+), 10 deletions(-)
net/mac80211/ieee80211.c +199 -10
Index: wireless-dev/net/mac80211/ieee80211.c
===================================================================
@@ -1118,7 +1118,111 @@ ieee80211_tx_h_ps_buf(struct ieee80211_t
 }
 
 
-static void inline
+/* deal with packet injection down monitor interface
+ * with Radiotap Header -- only called for monitor mode interface
+ */
+
+static ieee80211_txrx_result
+__ieee80211_convert_radiotap_to_control_and_remove(
+	struct ieee80211_txrx_data *tx,
+	struct sk_buff *skb, struct ieee80211_tx_control *control)
+{
+	/* this is the moment to interpret and discard the radiotap header that
+	 * must be at the start of the packet injected in Monitor mode
+	 *
+	 * Need to take some care with endian-ness since radiotap
+	 * args are little-endian
+	 */
+
+	struct ieee80211_radiotap_iterator iterator;
+	struct ieee80211_radiotap_header *rthdr =
+		(struct ieee80211_radiotap_header *) skb->data;
+	struct ieee80211_hw_mode *hw_mode=tx->local->hw.conf.mode;
+
+	/* this can fail some sanity checks, drop packet if it does so */
+
+	if (ieee80211_radiotap_iterator_init(&iterator, rthdr, skb->len) < 0)
+		return TXRX_DROP;
+
+	/* default control situation for all injected packets
+	 * FIXME: this does not suit all usage cases, expand to allow control
+	 */
+
+	control->retry_limit = 1; /* no retry */
+	control->key_idx = -1; /* no encryption key */
+	control->flags &= ~(IEEE80211_TXCTL_USE_RTS_CTS |
+			    IEEE80211_TXCTL_USE_CTS_PROTECT);
+	control->flags |= IEEE80211_TXCTL_DO_NOT_ENCRYPT |
+			  IEEE80211_TXCTL_NO_ACK;
+	control->antenna_sel_tx = 0; /* default to default antenna */
+
+	/* for every radiotap entry that is present (returns -ve on end or
+	 * on error)
+	 */
+
+	while (ieee80211_radiotap_iterator_next(&iterator) >= 0) {
+		int i, target_rate;
+
+		/* see if this argument is something we can use */
+
+		switch (iterator.this_arg_index) {
+
+		case IEEE80211_RADIOTAP_RATE:
+			/* radiotap "rate" u8 is in
+			 * 500kbps units, eg, 0x02=1Mbps
+			 * ieee80211 "rate" int is
+			 * in 100kbps units, eg, 0x0a=1Mbps
+			 */
+			target_rate = (*iterator.this_arg) * 5;
+			for (i = 0; i < hw_mode->num_rates; i++) {
+				struct ieee80211_rate *r = &hw_mode->rates[i];
+
+				if (r->rate > target_rate)
+					continue;
+
+				control->rate = r;
+
+				if (r->flags & IEEE80211_RATE_PREAMBLE2)
+					control->tx_rate = r->val2;
+				else
+					control->tx_rate = r->val;
+
+				/* end on exact match */
+				if (r->rate == target_rate)
+					i = hw_mode->num_rates;
+
+			}
+			break;
+
+		case IEEE80211_RADIOTAP_ANTENNA:
+			/* radiotap uses 0 for 1st ant,
+			 * mac80211 is 1 for 1st ant
+			 * absence of IEEE80211_RADIOTAP_ANTENNA
+			 * gives default/diversity
+			 */
+			control->antenna_sel_tx = (*iterator.this_arg) + 1;
+			break;
+
+		case IEEE80211_RADIOTAP_DBM_TX_POWER:
+			control->power_level = *iterator.this_arg;
+			break;
+
+		default:
+			break;
+		}
+
+	}
+
+	/* remove the radiotap header
+	 * rthdr->it_len was sanity-checked against skb->len by iterator init
+	 */
+	skb_pull(skb, le16_to_cpu(rthdr->it_len));
+
+	return TXRX_CONTINUE;
+}
+
+
+static ieee80211_txrx_result inline
 __ieee80211_tx_prepare(struct ieee80211_txrx_data *tx,
 		       struct sk_buff *skb,
 		       struct net_device *dev,
@@ -1126,6 +1230,9 @@ __ieee80211_tx_prepare(struct ieee80211_
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+	struct ieee80211_sub_if_data *sdata;
+	ieee80211_txrx_result res = TXRX_CONTINUE;
+
 	int hdrlen;
 
 	memset(tx, 0, sizeof(*tx));
@@ -1135,7 +1242,32 @@ __ieee80211_tx_prepare(struct ieee80211_
 	tx->sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	tx->sta = sta_info_get(local, hdr->addr1);
 	tx->fc = le16_to_cpu(hdr->frame_control);
+
+	/* set defaults for things that can be set by
+	 * injected radiotap headers
+	 */
+
 	control->power_level = local->hw.conf.power_level;
+	control->antenna_sel_tx = local->hw.conf.antenna_sel_tx;
+	if (local->sta_antenna_sel != STA_ANTENNA_SEL_AUTO && tx->sta)
+		control->antenna_sel_tx = tx->sta->antenna_sel_tx;
+
+	/* process and remove the injection radiotap header */
+
+	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	if (unlikely(sdata->type == IEEE80211_IF_TYPE_MNTR)) {
+		if (__ieee80211_convert_radiotap_to_control_and_remove(
+		    tx, skb, control) == TXRX_DROP) {
+			return TXRX_DROP;
+		}
+		/* we removed the radiotap header after this point,
+		 * we filled control with what we could use
+		 * set to the actual ieee header now
+		 */
+		hdr = (struct ieee80211_hdr *) skb->data;
+		res = TXRX_QUEUED; /* indication it was monitor packet */
+	}
+
 	tx->u.tx.control = control;
 	tx->u.tx.unicast = !is_multicast_ether_addr(hdr->addr1);
 	if (is_multicast_ether_addr(hdr->addr1))
@@ -1152,9 +1284,6 @@ __ieee80211_tx_prepare(struct ieee80211_
 		control->flags |= IEEE80211_TXCTL_CLEAR_DST_MASK;
 		tx->sta->clear_dst_mask = 0;
 	}
-	control->antenna_sel_tx = local->hw.conf.antenna_sel_tx;
-	if (local->sta_antenna_sel != STA_ANTENNA_SEL_AUTO && tx->sta)
-		control->antenna_sel_tx = tx->sta->antenna_sel_tx;
 	hdrlen = ieee80211_get_hdrlen(tx->fc);
 	if (skb->len > hdrlen + sizeof(rfc1042_header) + 2) {
 		u8 *pos = &skb->data[hdrlen + sizeof(rfc1042_header)];
@@ -1162,6 +1291,7 @@ __ieee80211_tx_prepare(struct ieee80211_
 	}
 	control->flags |= IEEE80211_TXCTL_FIRST_FRAGMENT;
 
+	return res;
 }
 
 static int inline is_ieee80211_device(struct net_device *dev,
@@ -1274,7 +1404,7 @@ static int ieee80211_tx(struct net_devic
 	struct sta_info *sta;
 	ieee80211_tx_handler *handler;
 	struct ieee80211_txrx_data tx;
-	ieee80211_txrx_result res = TXRX_DROP;
+	ieee80211_txrx_result res = TXRX_DROP, res_prepare;
 	int ret, i;
 
 	WARN_ON(__ieee80211_queue_pending(local, control->queue));
@@ -1284,15 +1414,26 @@ static int ieee80211_tx(struct net_devic
 		return 0;
 	}
 
-	__ieee80211_tx_prepare(&tx, skb, dev, control);
+	res_prepare = __ieee80211_tx_prepare(&tx, skb, dev, control);
+
+	if (res_prepare == TXRX_DROP) {
+		dev_kfree_skb(skb);
+		return 0;
+	}
+
 	sta = tx.sta;
 	tx.u.tx.mgmt_interface = mgmt;
 	tx.u.tx.mode = local->hw.conf.mode;
 
-	for (handler = local->tx_handlers; *handler != NULL; handler++) {
-		res = (*handler)(&tx);
-		if (res != TXRX_CONTINUE)
-			break;
+	if (res_prepare == TXRX_QUEUED) { /* if it was an injected packet */
+		res = TXRX_CONTINUE;
+	} else {
+		for (handler = local->tx_handlers; *handler != NULL;
+		     handler++) {
+			res = (*handler)(&tx);
+			if (res != TXRX_CONTINUE)
+				break;
+		}
 	}
 
 	skb = tx.skb; /* handlers are allowed to change skb */
@@ -1531,6 +1672,54 @@ static int ieee80211_subif_start_xmit(st
 		goto fail;
 	}
 
+	if (unlikely(sdata->type == IEEE80211_IF_TYPE_MNTR)) {
+		struct ieee80211_radiotap_header * prthdr =
+			(struct ieee80211_radiotap_header *)skb->data;
+
+		/*
+		 * there must be a radiotap header at the
+		 * start in this case
+		 */
+
+		if (unlikely(prthdr->it_version)) {
+			/* only version 0 is supported  */
+			ret = 0;
+			goto fail;
+		}
+
+		skb->dev = local->mdev;
+
+		pkt_data = (struct ieee80211_tx_packet_data *)skb->cb;
+		memset(pkt_data, 0, sizeof(struct ieee80211_tx_packet_data));
+		pkt_data->ifindex = sdata->dev->ifindex;
+		pkt_data->mgmt_iface = 0;
+		pkt_data->do_not_encrypt = 1;
+
+		/* above needed because we set skb device to master */
+
+		/*
+		 * fix up the pointers accounting for the radiotap
+		 * header still being in there.  We are being given
+		 * a precooked IEEE80211 header so no need for
+		 * normal processing
+		 */
+
+		skb_set_mac_header(skb, prthdr->it_len);
+		skb_set_network_header(skb, prthdr->it_len +
+		    sizeof(struct ieee80211_hdr));
+		skb_set_transport_header(skb, prthdr->it_len +
+		    sizeof(struct ieee80211_hdr));
+
+		/*
+		 * pass the radiotap header up to
+		 * the next stage intact
+		 */
+
+		dev_queue_xmit(skb);
+
+		return 0;
+	}
+
 	nh_pos = skb_network_header(skb) - skb->data;
 	h_pos = skb_transport_header(skb) - skb->data;
 
maintainer
#8 lore raw

Re: [PATCH Try#8 4/4] mac80211: Monitor mode radiotap-based packet injection

net/mac80211/ieee80211.c ieee80211_tx_h_ps_buf(struct ieee80211_t · line 1163

Quoted 6 lines
net/mac80211/ieee80211.c +5 -0
+	/* for every radiotap entry that is present (returns -ve on end or
+	 * on error)
+	 */
+
+	while (ieee80211_radiotap_iterator_next(&iterator) >= 0) {

"returns -ve"? Also, this does >= 0 while the docs stated that -1 is returned. Maybe the docs should be updated and the code should be changed to actually return 0 or a negative error code for iterator_next()? I don't see any value in the return code when it's non-negative, but when it's negative there could be some value in determining -EINVAL (invalid header) vs. -ENOENT (when it's the last one) for example.

net/mac80211/ieee80211.c static int ieee80211_subif_start_xmit(st · line 1705

Quoted 6 lines
net/mac80211/ieee80211.c +6 -0
+		/*
+		 * fix up the pointers accounting for the radiotap
+		 * header still being in there.  We are being given
+		 * a precooked IEEE80211 header so no need for
+		 * normal processing
+		 */

Interesting thing I just thought about here. For hardware-based sequence numbers we'll be updating the sequence number before sending it, and for software-based sequence numbers we wouldn't be.

However, for a userspace MLME we really need to update the sequence number, so we'll either want to have a radiotap flag determining whether the sequence number should be updated or not when transmitting a frame or we just update them all the time, even for software-sequence numbers. bcm43xx for example allows to turn off hardware sequence numbers on a per-frame basis, so it'd be able to do both, but I'm not sure we can rely on such functionality hence we'll want to just update sequence numbers all the time...

johannes