* Re: [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
[not found] ` <20080612053323.GC4919-mgr6C1c9aYeHXe+LvDLADg@public.gmane.org>
@ 2008-06-12 18:10 ` Luis Carlos Cobo
0 siblings, 0 replies; 11+ messages in thread
From: Luis Carlos Cobo @ 2008-06-12 18:10 UTC (permalink / raw)
To: Jouni Malinen
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
johannes-cdvu00un1VgdHxzADdlk8Q,
bridge-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Linux Netdev List
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1213255570.3871.8.camel@johannes.berg>]
* Re: [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
[not found] ` <1213255570.3871.8.camel@johannes.berg>
@ 2008-06-12 18:19 ` Luis Carlos Cobo
2008-06-12 18:20 ` Johannes Berg
0 siblings, 1 reply; 11+ messages in thread
From: Luis Carlos Cobo @ 2008-06-12 18:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, shemminger, j, bridge, Linux Netdev List
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
2008-06-12 18:19 ` Luis Carlos Cobo
@ 2008-06-12 18:20 ` Johannes Berg
[not found] ` <1213294852.3730.31.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Johannes Berg @ 2008-06-12 18:20 UTC (permalink / raw)
To: Luis Carlos Cobo; +Cc: linux-wireless, shemminger, j, bridge, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
> 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
@ 2008-06-11 23:18 luisca
2008-06-12 18:13 ` Stephen Hemminger
0 siblings, 1 reply; 11+ messages in thread
From: luisca @ 2008-06-11 23:18 UTC (permalink / raw)
To: netdev; +Cc: shemminger, j, johannes, bridge, linux-wireless
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 <luisca@cozybit.com>
---
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
2008-06-11 23:18 luisca
@ 2008-06-12 18:13 ` Stephen Hemminger
0 siblings, 0 replies; 11+ messages in thread
From: Stephen Hemminger @ 2008-06-12 18:13 UTC (permalink / raw)
To: luisca; +Cc: netdev, j, johannes, bridge, linux-wireless
On Wed, 11 Jun 2008 16:18:20 -0700
luisca@cozybit.com 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 <luisca@cozybit.com>
> ---
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [RFC] Do not activate promiscuous mode on wlan interfaces for bridging.
@ 2008-06-11 23:18 luisca
0 siblings, 0 replies; 11+ messages in thread
From: luisca @ 2008-06-11 23:18 UTC (permalink / raw)
To: netdev; +Cc: shemminger, j, johannes, bridge, linux-wireless
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 <luisca@cozybit.com>
---
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-06-12 19:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1213232760.6645.24.camel@localhost>
[not found] ` <20080612053323.GC4919@jm.kir.nu>
[not found] ` <20080612053323.GC4919-mgr6C1c9aYeHXe+LvDLADg@public.gmane.org>
2008-06-12 18:10 ` [RFC] Do not activate promiscuous mode on wlan interfaces for bridging Luis Carlos Cobo
[not found] ` <1213255570.3871.8.camel@johannes.berg>
2008-06-12 18:19 ` Luis Carlos Cobo
2008-06-12 18:20 ` Johannes Berg
[not found] ` <1213294852.3730.31.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-06-12 18:34 ` Luis Carlos Cobo
2008-06-12 18:44 ` Johannes Berg
[not found] ` <1213296250.3730.33.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2008-06-12 18:53 ` Luis Carlos Cobo
2008-06-12 18:59 ` Johannes Berg
2008-06-12 19:01 ` Johannes Berg
2008-06-11 23:18 luisca
2008-06-12 18:13 ` Stephen Hemminger
-- strict thread matches above, loose matches on Subject: below --
2008-06-11 23:18 luisca
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).