(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
Signed-off-by: Luis Carlos Cobo <[email protected]>
---
net/bridge/br_if.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index c2397f5..155bd90 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -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.
On Thu, 2008-06-12 at 11:34 -0700, Luis Carlos Cobo wrote:
> On Thu, 2008-06-12 at 20:20 +0200, Johannes Berg wrote:
> > Is this a mac80211 driver? When are you activating promisc?
>
> 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.
But in response to what mac80211 command are you sending the promisc
mode to the hw?
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.
Is this a mac80211 driver? When are you activating promisc?
johannes
On Thu, 2008-06-12 at 11:53 -0700, Luis Carlos Cobo wrote:
> On Thu, 2008-06-12 at 20:44 +0200, Johannes Berg wrote:
> > But in response to what mac80211 command are you sending the promisc
> > mode to the hw?
>
> In the function associated to .configure_filter (struct ieee80211_ops)
> in the driver, when (*new_flags & (FIF_PROMISC_IN_BSS))
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
On Thu, 2008-06-12 at 20:59 +0200, Johannes Berg wrote:
> On Thu, 2008-06-12 at 11:53 -0700, Luis Carlos Cobo wrote:
> > On Thu, 2008-06-12 at 20:44 +0200, Johannes Berg wrote:
> > > But in response to what mac80211 command are you sending the promisc
> > > mode to the hw?
> >
> > In the function associated to .configure_filter (struct ieee80211_ops)
> > in the driver, when (*new_flags & (FIF_PROMISC_IN_BSS))
>
> 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.
In fact, if it stops the firmware from ACKing packets you want to never
enable it if you have any interfaces at all.
johannes
On Wed, Jun 11, 2008 at 06:06:00PM -0700, Luis Carlos Cobo wrote:
> 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.
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.. ;-)
> Please let me know what you think of this patch and whether it could interfere
> with any functionality.
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.
> + * 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.
This is not strictly speaking correct. 4-address frame format (WDS) can
be used in other (non-AP) modes, too. Anyway, they do not require the
interface to be in promiscuous mode since addr1 of the frames is the
unicast address of the receiving device regardless of the original
destination address.
--
Jouni Malinen PGP id EFC895FA
On Thu, 2008-06-12 at 20:20 +0200, Johannes Berg wrote:
> Is this a mac80211 driver? When are you activating promisc?
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.
> 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.
[...]
> 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.
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
Thank you very much for your comments Jouni.
On Thu, 2008-06-12 at 08:33 +0300, Jouni Malinen wrote:
> 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.. ;-)
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.
> This is not strictly speaking correct. 4-address frame format (WDS) can
> be used in other (non-AP) modes, too. Anyway, they do not require the
> interface to be in promiscuous mode since addr1 of the frames is the
> unicast address of the receiving device regardless of the original
> destination address.
Agreed, will reword that.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
On Thu, 2008-06-12 at 20:44 +0200, Johannes Berg wrote:
> But in response to what mac80211 command are you sending the promisc
> mode to the hw?
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.
On Wed, 11 Jun 2008 16:18:20 -0700
[email protected] wrote:
> 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
>
> Signed-off-by: Luis Carlos Cobo <[email protected]>
> ---
> net/bridge/br_if.c | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index c2397f5..155bd90 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -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);
>
NACK too much of a one off hack. If the device can't do promiscuous or bridging
properly, it should solve the problem there. Otherwise you will have to fix all
other uses of promiscuous as well.
On Thu, 2008-06-12 at 09:26 +0200, Johannes Berg wrote:
> 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.
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.