Do not activate promiscuous mode on wlan interfaces for bridging.

(Sorry if you received this mail multiple times, my email client had problems with the Cc's)

I have come across a 802.11 device that stops acknowledging frames addressed to it when in promiscuous mode. The device can act as an AP with hostapd. However, when the interface is attached to a bridge the lack of acknowledgments makes the device non-functional as an AP.

It seems that it is not really necessary to activate promiscuous mode when attaching a wlan interface to a bridge, and it causes unnecessary processing overhead to any wlan device.

Case 1: Ethernet to ethernet
----------------------------

A <----> BRIDGE <----> B

The bridge needs to set promiscuous mode on both interfaces.

Case 2: Ethernet to 802.11 through AP
-------------------------------------

A <----> BRIDGE/AP -)) ((- B

The ethernet interface needs to be in promiscuous mode so that frames from A to B are received by the bridge and then forwarded.

However, the wlan interface does _not_ need to be a promiscuous mode. A 802.11 frame from B to A will have:

ToDS
RA = BSSID = MAC_AP
TA = SA = MAC_B
DA = MAC_A

Frames are naturally addressed to the AP, so the wlan interface does not need to be in promiscuous mode. Activating promiscuous mode would actually force the device to deal with many frames it does not really have to deal with.

Case 3: Ethernet to 802.11 through IBSS / Managed STAs
------------------------------------------------------

A <----> BRIDGE/IBSS_STA_B -)) ((- IBSS_STA_C

or

A <----> BRIDGE/STA -)) ((- AP

In this case the frames on the wireless segment will not be naturally addressed to the bridge, so activating promiscuous mode on the wireless interface would be necessary for the bridge to work. However there are three problems here:

First as Jouni Malinen states [1], this would not comply with 802.11 standard, which does not allow to use as SA a MAC address other than our own. If we do it anyway, we will have to look for 802.11 ACKs to the MAC address we bridge to control frame retransmissions. I do not think any device does this.

Second, such a bridge would be responsible for sending 802.11 ACKs for any 802.11 frame addressed to a MAC in the ethernet segment it bridges to. As acking is usually implemented at MAC level I do not think any device supports this.

Third, on the managed STA case, the STA would have to fake an association with the AP for A (and every other node in the ethernet segment it bridges to). While doable, it adds unnecessary ugly complexity.

Even with these problems the bridging might "work", but every frame on the wlan segment from/to the bridged ethernet will have to be retransmitted the maximum number of times since acks would not work properly.

Given this three cases, the best would be to consider case 3 to be not supported (it is indeed not supported, AFAIK), and apply the patch below.

Please let me know what you think of this patch and whether it could interfere with any functionality.

Nomenclature
RA = receiver address
TA = transmitter address
SA = source address
BSSID = basic service set identifier
<----> = Ethernet link
-)) ((- = 802.11 link

[1]: http://marc.info/?l=linux-wireless&m=117881727809631&w=2

---
 net/bridge/br_if.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

index c2397f5..155bd90 100644
@@ -135,7 +135,8 @@ static void del_nbp(struct net_bridge_port *p)
 
 	sysfs_remove_link(br->ifobj, dev->name);
 
-	dev_set_promiscuity(dev, -1);
+	if (!dev->ieee80211_ptr)
+		dev_set_promiscuity(dev, -1);
 
 	spin_lock_bh(&br->lock);
 	br_stp_disable_port(p);

@@ -389,7 +390,15 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
 		goto err2;
 
 	rcu_assign_pointer(dev->br_port, p);
-	dev_set_promiscuity(dev, 1);
+	/*
+	 * 802.11 interfaces working as Access Points do not need to be set to
+	 * promiscuous mode for bridging, as every frame is addressed to them.
+	 *
+	 * Bridging of 802.11 interfaces which are not in AP mode is not
+	 * supported.
+	 */
+	if (!dev->ieee80211_ptr)
+		dev_set_promiscuity(dev, 1);
 
 	list_add_rcu(&p->list, &br->port_list);
 

1.5.4.3



-- 
Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

Yes, agreed, IEEE 802.11 interfaces should not be changed into "monitor mode" that receives all frames on the channel for normal bridging. Whether the "promiscuous mode" is really a suitable name for this mode is another question, though, since there are more ways to be promiscuous in wireless networks than wired.. ;-)

Its desired goal sounds reasonable. I'm not sure whether dev->ieee80211_ptr is guaranteed to be set with all drivers and all configurations, though. Anyway, this should not break normal IEEE 802.11 bridging cases.

Jouni Malinen                                            PGP id EFC895FA

Thank you very much for your comments Jouni.

Indeed, but the bridge sets promiscuous mode, not monitor. This means that the device will receive every frame within its configured BSS whether it is addressed to it or not. For an AP actually this mode should make no difference, since every frame not coming from the AP is addressed to the AP.

Agreed, will reword that.

Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

[...]

All your description makes a lot of sense, but I don't see why altering the bridge code is necessary. In mac80211, we decided that the "promisc" bit only means to capture all frames in the current BSS (remember that in ethernet there is no way to capture frames from different LAN segments) and hence an AP would not behave differently in promisc mode at all since, by definition, it sees all BSS traffic.

What exactly is happening when you run into this problem?

johannes

You are right, within the BSS every frame is going to be addressed to the AP anyway, so we should not receive more or less frames when activating promiscuous mode.

When activating promiscuous mode in this device, it stops acknowledging frames, and this impairs the association process. The other solution would be to ignore the promiscuous mode commands (i.e. never send the command to the device) for interfaces in AP mode. If this is the only device showing this behavior, maybe that would be the best solution.

Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

Is this a mac80211 driver? When are you activating promisc?

johannes

Yes, libertastf (adaptation of the libertas driver to use a thin firmware and mac80211), you can check it out at

git://dev.laptop.org/users/javier/libertastf.git

Still want to polish it a bit before submitting.

Promiscuous mode is being activated when attaching the interface to a bridge, in the lines included in the patch on the first mail in the thread.

Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

But in response to what mac80211 command are you sending the promisc mode to the hw?

johannes

In the function associated to .configure_filter (struct ieee80211_ops) in the driver, when (*new_flags & (FIF_PROMISC_IN_BSS))

Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

But it is a "real promisc" mode not restricted to the BSS? Maybe the solution is to just not promote promisc-in-bss to real-promisc when AP mode is active.

johannes

In fact, if it stops the firmware from ACKing packets you want to never enable it if you have any interfaces at all.

johannes