mac80211: No echo TX pkt to Monitor interfaces for injection

Block of code at the end of ieee80211_tx_status() seems to exist in order to echo tx packets down Monitor mode interfaces with a synthesized radiotap preamble describing the outcome of the transmission.

The effect it has with injected packets is that two copies of each injected packet appears on the soft Monitor mode interface it was injected down, one with a correct radiotap header reflecting what was injected, and one with a bogus 0x0b length radiotap header. This behaviour was seen on iwl3945 and rt73usb.

This patch adds a new attribute to ieee80211_tx_control's flags field, IEEE80211_TXCTL_NO_SOFT_MONITOR_ECHO, which is set for injected packets. The code to add a new radiotap header and echo the packet down monitor mode interfaces is now conditional on this attribute not being set.

---

 include/net/mac80211.h   |    1 +
 net/mac80211/ieee80211.c |    5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)

index 17a4dd7..6bf8f7b 100644
@@ -192,6 +192,7 @@ struct ieee80211_tx_control {
 #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_NO_SOFT_MONITOR_ECHO (1<<10)
 	u32 flags;			       /* tx control flags defined
 						* above */
 	u8 retry_limit;		/* 1 = only first attempt, 2 = one retry, .. */

index 7dda339..b094274 100644
@@ -1309,6 +1309,7 @@ __ieee80211_tx_prepare(struct ieee80211_txrx_data *tx,
 								TXRX_DROP) {
 			return TXRX_DROP;
 		}
+		control->flags |= IEEE80211_TXCTL_NO_SOFT_MONITOR_ECHO;
 		/*
 		 * we removed the radiotap header after this point,
 		 * we filled control with what we could use

@@ -4850,6 +4851,9 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
 
 	rthdr->data_retries = status->retry_count;
 
+	if (status->control.flags & IEEE80211_TXCTL_NO_SOFT_MONITOR_ECHO)
+		goto out_no_echo;
+
 	read_lock(&local->sub_if_lock);
 	monitors = local->monitors;
 	list_for_each_entry(sdata, &local->sub_if_list, list) {

@@ -4885,6 +4889,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
 	}
  out:
 	read_unlock(&local->sub_if_lock);
+ out_no_echo:
 	if (skb)
 		dev_kfree_skb(skb);
 }

Ah. Now I see why this is happening. It's because any packet you send into the monitor interface from userspace is already redirected back to userspace by upper levels... Hmm. It *seems* this patch is correct, but it changes the semantics slightly: previously, you would see transmitted packets with their transmit indication (whether it was acked etc) and now you do not get that for injected packets. Could we instead somehow get the upper layers to not redirect that and fix the radiotap header?

johannes

With the patch, injected packets have the same Monitor mode footprint with hard or soft monitoring (you see the injected radiotap stuff) because the synthesized "tx report" packet doesn't exist in the real world shown by hard monitoring.

Acutually I think where it might all be heading is Michael Buesch's method of selecting between hard and soft Monitor mode based on IFF_PROMISC. Maybe stuff like the user MLE plan wants to hear about TX reports, it's only interested in a context it is trying to associate to, maybe it would be happy with the filtered soft Monitor (this would deal with the objection about increased power consumption for unfiltered user MLE hardware promisc too)... apps that truly want hard Monitor don't want the TX reports...

If that is where we are headed then it deprecates this patch, you actually want the TX report in soft monitor (only) which is the current situation... we just need to get to the place that tcpdump (which sets IFF_PROMISC for the duration) never ever sees soft Monitor...

-Andy

I don't see why there's a distinction between hard and soft monitor mode. To me, hard monitor mode is basically "show me everything you can" while soft is "best effort". Soft monitor mode also makes no sense while no other interface is operating.

The synthesized 'tx report packet' isn't that; the only synthesized thing is the radiotap header, the rest of the packet is what we actually sent and were thus unable to capture ourselves.

Ah. I see. You're thinking of hard/soft monitor as something totally different than it is. Soft monitor really is only a hack for pseudo-softmac hardware that doesn't allow you to capture control packets while another interface is operating.

johannes

I also think it makes no sense to have a dependency on what Monitor mode provides based on the other virtual interfaces, unless the hardware cannot live up to the various demands at the same time. (What hardware has this problem that it can't run a Managed interface with hardware promisc Rx?)

Yes, that is true.

Well it has leaked out of that raison d'etre and oozed into being what you get on any secondary virtual interface in Monitor mode.

Still I was suggesting maybe it does have another reason for existing, the application of the usermode MLME might fit well with the filtered aspect of it and the existing "TX report echos".

-Andy

That's exactly the point though. Some hardware cannot do it and that's why it exists. Not sure what hardware, probably Intel stuff with their great firmware...

I don't think you get that with bcm43xx since that allows monitor_during_oper. I'm guessing that zd1211 should also support it but just doesn't set the flag.

johannes

Regardless of whether my approach (just posted) will be accepted, this patch cannot go in: it stops injected packets from showing up on all monitor interfaces but the one they were injected into. If my IFF_NO_MIRROR approach is rejected then we'll have to make this a bit more elaborate by storing the injection device ifindex in the info instead of just a flag.

johannes

Yep, fair enough.

-Andy