A number of people have tried to add a wireless interface
(in managed mode) to a bridge and then complained that it
doesn't work. It cannot work, however, because in 802.11
networks all packets need to be acknowledged and as such
need to be sent to the right address. Promiscuous doesn't
help here. The wireless address format used for these
links has only space for three addresses, the
* transmitter, which must be equal to the sender (origin)
* receiver (on the wireless medium), which is the AP in
the case of managed mode
* the recipient (destination), which is on the APs local
network segment
In an IBSS, it is similar, but the receiver and recipient
must match and the third address is used as the BSSID.
To avoid such mistakes in the future, disallow adding a
wireless interface to a bridge.
Felix has recently added a four-address mode to the AP
and client side that can be used (after negotiating that
it is possible, which must happen out-of-band by setting
up both sides) for bridging, so allow that case.
Signed-off-by: Johannes Berg <[email protected]>
---
include/linux/if.h | 1 +
net/bridge/br_if.c | 4 ++++
net/mac80211/cfg.c | 9 ++++++++-
net/mac80211/iface.c | 17 +++++++++++++++--
4 files changed, 28 insertions(+), 3 deletions(-)
--- wireless-testing.orig/include/linux/if.h 2009-11-17 14:18:36.000000000 +0100
+++ wireless-testing/include/linux/if.h 2009-11-17 14:19:04.000000000 +0100
@@ -70,6 +70,7 @@
#define IFF_XMIT_DST_RELEASE 0x400 /* dev_hard_start_xmit() is allowed to
* release skb->dst
*/
+#define IFF_DONT_BRIDGE 0x800 /* disallow bridging this ether dev */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
--- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
+++ wireless-testing/net/bridge/br_if.c 2009-11-17 14:20:03.000000000 +0100
@@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
if (dev->br_port != NULL)
return -EBUSY;
+ /* No bridging devices that dislike that (e.g. wireless) */
+ if (dev->priv_flags & IFF_DONT_BRIDGE)
+ return -EINVAL;
+
p = new_nbp(br, dev);
if (IS_ERR(p))
return PTR_ERR(p);
--- wireless-testing.orig/net/mac80211/cfg.c 2009-11-17 14:21:24.000000000 +0100
+++ wireless-testing/net/mac80211/cfg.c 2009-11-17 14:37:13.000000000 +0100
@@ -106,8 +106,15 @@ static int ieee80211_change_iface(struct
params->mesh_id_len,
params->mesh_id);
- if (params->use_4addr >= 0)
+ if (params->use_4addr >= 0) {
sdata->use_4addr = !!params->use_4addr;
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+
+ if ((sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC) &&
+ !sdata->use_4addr)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ }
if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
return 0;
--- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
+++ wireless-testing/net/mac80211/iface.c 2009-11-17 14:33:25.000000000 +0100
@@ -769,6 +769,11 @@ int ieee80211_if_change_type(struct ieee
sdata->local->hw.conf.channel->band);
sdata->drop_unencrypted = 0;
sdata->use_4addr = 0;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ else
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
return 0;
}
@@ -843,8 +848,16 @@ int ieee80211_if_add(struct ieee80211_lo
params->mesh_id_len,
params->mesh_id);
- if (params && params->use_4addr >= 0)
- sdata->use_4addr = !!params->use_4addr;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ else
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+
+ if (params && params->use_4addr > 0) {
+ sdata->use_4addr = true;
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+ }
mutex_lock(&local->iflist_mtx);
list_add_tail_rcu(&sdata->list, &local->interfaces);
On Tue, 17 Nov 2009 17:43:43 +0100
Johannes Berg <[email protected]> wrote:
> On Tue, 2009-11-17 at 08:37 -0800, Stephen Hemminger wrote:
>
> > But there are people bridging wireless, and hostap even has a mode for
> > that.
>
> But that's the AP side, which this patch doesn't attempt to prevent. It
> just makes no sense to bridge when connected to an AP or part of an
> IBSS.
>
Then how does this work now? And will your change break it?
kvm1
/
====> wlan0 --- bridge-- kvm2
\
kvm3
A number of people have tried to add a wireless interface
(in managed mode) to a bridge and then complained that it
doesn't work. It cannot work, however, because in 802.11
networks all packets need to be acknowledged and as such
need to be sent to the right address. Promiscuous doesn't
help here. The wireless address format used for these
links has only space for three addresses, the
* transmitter, which must be equal to the sender (origin)
* receiver (on the wireless medium), which is the AP in
the case of managed mode
* the recipient (destination), which is on the APs local
network segment
In an IBSS, it is similar, but the receiver and recipient
must match and the third address is used as the BSSID.
To avoid such mistakes in the future, disallow adding a
wireless interface to a bridge.
Felix has recently added a four-address mode to the AP
and client side that can be used (after negotiating that
it is possible, which must happen out-of-band by setting
up both sides) for bridging, so allow that case.
Signed-off-by: Johannes Berg <[email protected]>
---
v2: * change error code as requested by Michael
* disallow changing wireless mode on a bridged iface
Should more (all?) of this be in cfg80211?
include/linux/if.h | 1 +
net/bridge/br_if.c | 4 ++++
net/mac80211/cfg.c | 9 ++++++++-
net/mac80211/iface.c | 22 ++++++++++++++++++++--
4 files changed, 33 insertions(+), 3 deletions(-)
--- wireless-testing.orig/include/linux/if.h 2009-11-17 14:18:36.000000000 +0100
+++ wireless-testing/include/linux/if.h 2009-11-17 14:19:04.000000000 +0100
@@ -70,6 +70,7 @@
#define IFF_XMIT_DST_RELEASE 0x400 /* dev_hard_start_xmit() is allowed to
* release skb->dst
*/
+#define IFF_DONT_BRIDGE 0x800 /* disallow bridging this ether dev */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
--- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
+++ wireless-testing/net/bridge/br_if.c 2009-11-17 15:07:59.000000000 +0100
@@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
if (dev->br_port != NULL)
return -EBUSY;
+ /* No bridging devices that dislike that (e.g. wireless) */
+ if (dev->priv_flags & IFF_DONT_BRIDGE)
+ return -EOPNOTSUPP;
+
p = new_nbp(br, dev);
if (IS_ERR(p))
return PTR_ERR(p);
--- wireless-testing.orig/net/mac80211/cfg.c 2009-11-17 14:21:24.000000000 +0100
+++ wireless-testing/net/mac80211/cfg.c 2009-11-17 14:37:13.000000000 +0100
@@ -106,8 +106,15 @@ static int ieee80211_change_iface(struct
params->mesh_id_len,
params->mesh_id);
- if (params->use_4addr >= 0)
+ if (params->use_4addr >= 0) {
sdata->use_4addr = !!params->use_4addr;
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+
+ if ((sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC) &&
+ !sdata->use_4addr)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ }
if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
return 0;
--- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
+++ wireless-testing/net/mac80211/iface.c 2009-11-17 17:56:08.000000000 +0100
@@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
if (type == sdata->vif.type)
return 0;
+ /* if it's part of a bridge, reject changing type to station/ibss */
+ if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
+ type == NL80211_IFTYPE_STATION))
+ return -EBUSY;
+
/* Setting ad-hoc mode on non-IBSS channel is not supported. */
if (sdata->local->oper_channel->flags & IEEE80211_CHAN_NO_IBSS &&
type == NL80211_IFTYPE_ADHOC)
@@ -769,6 +774,11 @@ int ieee80211_if_change_type(struct ieee
sdata->local->hw.conf.channel->band);
sdata->drop_unencrypted = 0;
sdata->use_4addr = 0;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ else
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
return 0;
}
@@ -843,8 +853,16 @@ int ieee80211_if_add(struct ieee80211_lo
params->mesh_id_len,
params->mesh_id);
- if (params && params->use_4addr >= 0)
- sdata->use_4addr = !!params->use_4addr;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ sdata->dev->priv_flags |= IFF_DONT_BRIDGE;
+ else
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+
+ if (params && params->use_4addr > 0) {
+ sdata->use_4addr = true;
+ sdata->dev->priv_flags &= ~IFF_DONT_BRIDGE;
+ }
mutex_lock(&local->iflist_mtx);
list_add_tail_rcu(&sdata->list, &local->interfaces);
On Tue, Nov 17, 2009 at 02:46:25PM +0100, Johannes Berg wrote:
> A number of people have tried to add a wireless interface
> (in managed mode) to a bridge and then complained that it
> doesn't work. It cannot work, however, because in 802.11
> networks all packets need to be acknowledged and as such
> need to be sent to the right address. Promiscuous doesn't
> help here. The wireless address format used for these
> links has only space for three addresses, the
> * transmitter, which must be equal to the sender (origin)
> * receiver (on the wireless medium), which is the AP in
> the case of managed mode
> * the recipient (destination), which is on the APs local
> network segment
>
> In an IBSS, it is similar, but the receiver and recipient
> must match and the third address is used as the BSSID.
>
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
>
> Felix has recently added a four-address mode to the AP
> and client side that can be used (after negotiating that
> it is possible, which must happen out-of-band by setting
> up both sides) for bridging, so allow that case.
>
> Signed-off-by: Johannes Berg <[email protected]>
ACK -- we get these complaints fairly often...
I don't think I've sent the 4addr stuff to Dave yet. Should I just
take this through my tree?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tuesday 17 November 2009 14:46:25 Johannes Berg wrote:
> --- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
> +++ wireless-testing/net/bridge/br_if.c 2009-11-17 14:20:03.000000000 +0100
> @@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
> if (dev->br_port != NULL)
> return -EBUSY;
>
> + /* No bridging devices that dislike that (e.g. wireless) */
> + if (dev->priv_flags & IFF_DONT_BRIDGE)
> + return -EINVAL;
-EOPNOTSUPP?
That would probably produce a better error message in userspace.
--
Greetings, Michael.
On Tue, 2009-11-17 at 14:42 -0800, Stephen Hemminger wrote:
> > Felix has recently added a four-address mode to the AP
> > and client side that can be used (after negotiating that
> > it is possible, which must happen out-of-band by setting
> > up both sides) for bridging, so allow that case.
> Looks good, maybe true four-address mode support will be available
> more widely, and this will no longer be an issue.
Doubt it, it breaks the current 802.11 standard, and I think 802.1X too
if you use WPA/RSN. Anyway, thanks.
I'll take a look tomorrow if we can do this generically in cfg80211, and
then send a [PATCH] either way.
johannes
On Wed, Nov 18, 2009 at 07:48, Johannes Berg <[email protected]> wrote:
> --- wireless-testing.orig/net/mac80211/iface.c ?2009-11-17 14:20:19.000000000 +0100
> +++ wireless-testing/net/mac80211/iface.c ? ? ? 2009-11-17 17:56:08.000000000 +0100
> @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
> ? ? ? ?if (type == sdata->vif.type)
> ? ? ? ? ? ? ? ?return 0;
>
> + ? ? ? /* if it's part of a bridge, reject changing type to station/ibss */
> + ? ? ? if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? type == NL80211_IFTYPE_STATION))
> + ? ? ? ? ? ? ? return -EBUSY;
Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
like the next test?
Thanks,
--
Julian Calaby
Email: [email protected]
.Plan: http://sites.google.com/site/juliancalaby/
On Tue, 2009-11-17 at 21:59 -0500, John W. Linville wrote:
> > As someone who's been bitten by this, I fully support this change.
> > Still, it makes me wonder: my broadcom-based home-router using the wl.o
> > driver can be set in "client bridge" mode. How does it work?
>
> If I'm not mistaken, that has a bunch of code embedded in it that
> among other things can do a layer-2 version of NAT to rewrite the
> MAC adresses for frames on the air.
Yeah, that's how it works. You can probably achieve the same effect with
the ebtable_nat module in ebtables but I've never even attempted to try
that.
johannes
On Tue, 2009-11-17 at 08:37 -0800, Stephen Hemminger wrote:
> But there are people bridging wireless, and hostap even has a mode for
> that.
But that's the AP side, which this patch doesn't attempt to prevent. It
just makes no sense to bridge when connected to an AP or part of an
IBSS.
johannes
On Tue, 2009-11-17 at 15:04 +0100, Michael Buesch wrote:
> On Tuesday 17 November 2009 14:46:25 Johannes Berg wrote:
> > --- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
> > +++ wireless-testing/net/bridge/br_if.c 2009-11-17 14:20:03.000000000 +0100
> > @@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
> > if (dev->br_port != NULL)
> > return -EBUSY;
> >
> > + /* No bridging devices that dislike that (e.g. wireless) */
> > + if (dev->priv_flags & IFF_DONT_BRIDGE)
> > + return -EINVAL;
>
> -EOPNOTSUPP?
> That would probably produce a better error message in userspace.
Good idea, will wait a bit for other comments and fix this when I send
as [PATCH].
johannes
On Tue, 2009-11-17 at 08:58 -0500, John W. Linville wrote:
> > To avoid such mistakes in the future, disallow adding a
> > wireless interface to a bridge.
> >
> > Felix has recently added a four-address mode to the AP
> > and client side that can be used (after negotiating that
> > it is possible, which must happen out-of-band by setting
> > up both sides) for bridging, so allow that case.
> >
> > Signed-off-by: Johannes Berg <[email protected]>
>
> ACK -- we get these complaints fairly often...
>
> I don't think I've sent the 4addr stuff to Dave yet. Should I just
> take this through my tree?
After ack from Stephen maybe?
johannes
> A number of people have tried to add a wireless interface
> (in managed mode) to a bridge and then complained that it
> doesn't work. It cannot work, however, because in 802.11
[...]
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
As someone who's been bitten by this, I fully support this change.
Still, it makes me wonder: my broadcom-based home-router using the wl.o
driver can be set in "client bridge" mode. How does it work?
Stefan
On Wed, 2009-11-18 at 09:42 +1100, Julian Calaby wrote:
> On Wed, Nov 18, 2009 at 07:48, Johannes Berg <[email protected]> wrote:
> > --- wireless-testing.orig/net/mac80211/iface.c 2009-11-17 14:20:19.000000000 +0100
> > +++ wireless-testing/net/mac80211/iface.c 2009-11-17 17:56:08.000000000 +0100
> > @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
> > if (type == sdata->vif.type)
> > return 0;
> >
> > + /* if it's part of a bridge, reject changing type to station/ibss */
> > + if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
> > + type == NL80211_IFTYPE_STATION))
> > + return -EBUSY;
>
> Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
> like the next test?
Not sure, it's a temporary error and you can fix it by removing it from
the bridge, so it's "busy" in the sense that it is fixed to the current
mode or any other bridging mode by being in the bridge ... it's not that
it doesn't support the mode.
johannes
On Tue, 17 Nov 2009 21:48:18 +0100
Johannes Berg <[email protected]> wrote:
> A number of people have tried to add a wireless interface
> (in managed mode) to a bridge and then complained that it
> doesn't work. It cannot work, however, because in 802.11
> networks all packets need to be acknowledged and as such
> need to be sent to the right address. Promiscuous doesn't
> help here. The wireless address format used for these
> links has only space for three addresses, the
> * transmitter, which must be equal to the sender (origin)
> * receiver (on the wireless medium), which is the AP in
> the case of managed mode
> * the recipient (destination), which is on the APs local
> network segment
>
> In an IBSS, it is similar, but the receiver and recipient
> must match and the third address is used as the BSSID.
>
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
>
> Felix has recently added a four-address mode to the AP
> and client side that can be used (after negotiating that
> it is possible, which must happen out-of-band by setting
> up both sides) for bridging, so allow that case.
>
> Signed-off-by: Johannes Berg <[email protected]>
Looks good, maybe true four-address mode support will be available
more widely, and this will no longer be an issue.
Acked-by: Stephen Hemminger <[email protected]>
On Tue, Nov 17, 2009 at 08:59:03PM -0500, Stefan Monnier wrote:
> > A number of people have tried to add a wireless interface
> > (in managed mode) to a bridge and then complained that it
> > doesn't work. It cannot work, however, because in 802.11
> [...]
> > To avoid such mistakes in the future, disallow adding a
> > wireless interface to a bridge.
>
> As someone who's been bitten by this, I fully support this change.
> Still, it makes me wonder: my broadcom-based home-router using the wl.o
> driver can be set in "client bridge" mode. How does it work?
If I'm not mistaken, that has a bunch of code embedded in it that
among other things can do a layer-2 version of NAT to rewrite the
MAC adresses for frames on the air.
YMMV...
John
--
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
[email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
On Tue, 2009-11-17 at 09:04 -0800, Stephen Hemminger wrote:
> On Tue, 17 Nov 2009 17:43:43 +0100
> Johannes Berg <[email protected]> wrote:
>
> > On Tue, 2009-11-17 at 08:37 -0800, Stephen Hemminger wrote:
> >
> > > But there are people bridging wireless, and hostap even has a mode for
> > > that.
> >
> > But that's the AP side, which this patch doesn't attempt to prevent. It
> > just makes no sense to bridge when connected to an AP or part of an
> > IBSS.
> >
>
> Then how does this work now? And will your change break it?
>
> kvm1
> /
> ====> wlan0 --- bridge-- kvm2
> \
> kvm3
Are you sure 'bridge' isn't NAT-ed to wlan0 like libvirt/etc do by
default? That's about the only way it can possibly work correctly with
wifi.
Dan
On Wed, Nov 18, 2009 at 09:46, Johannes Berg <[email protected]> wrote:
> On Wed, 2009-11-18 at 09:42 +1100, Julian Calaby wrote:
>> On Wed, Nov 18, 2009 at 07:48, Johannes Berg <[email protected]> wrote:
>> > --- wireless-testing.orig/net/mac80211/iface.c ?2009-11-17 14:20:19.000000000 +0100
>> > +++ wireless-testing/net/mac80211/iface.c ? ? ? 2009-11-17 17:56:08.000000000 +0100
>> > @@ -745,6 +745,11 @@ int ieee80211_if_change_type(struct ieee
>> > ? ? ? ?if (type == sdata->vif.type)
>> > ? ? ? ? ? ? ? ?return 0;
>> >
>> > + ? ? ? /* if it's part of a bridge, reject changing type to station/ibss */
>> > + ? ? ? if (sdata->dev->br_port && (type == NL80211_IFTYPE_ADHOC ||
>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? type == NL80211_IFTYPE_STATION))
>> > + ? ? ? ? ? ? ? return -EBUSY;
>>
>> Busy doesn't seem like the right error here ... maybe use -EOPNOTSUPP
>> like the next test?
>
> Not sure, it's a temporary error and you can fix it by removing it from
> the bridge, so it's "busy" in the sense that it is fixed to the current
> mode or any other bridging mode by being in the bridge ... it's not that
> it doesn't support the mode.
Arguably the test following this (ensuring that we don't set ad-hoc
mode on a non-ad-hoc channel) is equally temporary - i.e. both actions
require the user to do something before they'll work again.
But then, the test after that - for whether the interface is running -
returns -EBUSY - and is just as easy to remedy, so........
Thanks,
--
Julian Calaby
Email: [email protected]
.Plan: http://sites.google.com/site/juliancalaby/
On Tue, 17 Nov 2009 15:07:48 +0100
Johannes Berg <[email protected]> wrote:
> On Tue, 2009-11-17 at 15:04 +0100, Michael Buesch wrote:
> > On Tuesday 17 November 2009 14:46:25 Johannes Berg wrote:
> > > --- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
> > > +++ wireless-testing/net/bridge/br_if.c 2009-11-17 14:20:03.000000000 +0100
> > > @@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
> > > if (dev->br_port != NULL)
> > > return -EBUSY;
> > >
> > > + /* No bridging devices that dislike that (e.g. wireless) */
> > > + if (dev->priv_flags & IFF_DONT_BRIDGE)
> > > + return -EINVAL;
> >
> > -EOPNOTSUPP?
> > That would probably produce a better error message in userspace.
But there are people bridging wireless, and hostap even has a mode for
that. Especially people are bridging to wireless when the other interfaces
are VMs.
On Tue, Nov 17, 2009 at 03:04:52PM +0100, Michael Buesch wrote:
> On Tuesday 17 November 2009 14:46:25 Johannes Berg wrote:
> > --- wireless-testing.orig/net/bridge/br_if.c 2009-11-17 14:19:17.000000000 +0100
> > +++ wireless-testing/net/bridge/br_if.c 2009-11-17 14:20:03.000000000 +0100
> > @@ -390,6 +390,10 @@ int br_add_if(struct net_bridge *br, str
> > if (dev->br_port != NULL)
> > return -EBUSY;
> >
> > + /* No bridging devices that dislike that (e.g. wireless) */
> > + if (dev->priv_flags & IFF_DONT_BRIDGE)
> > + return -EINVAL;
>
> -EOPNOTSUPP?
> That would probably produce a better error message in userspace.
Yes, good point.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, 2009-11-17 at 09:04 -0800, Stephen Hemminger wrote:
> Then how does this work now? And will your change break it?
>
> kvm1
> /
> ====> wlan0 --- bridge-- kvm2
> \
> kvm3
What's the type of wlan0? If it's managed, i.e. connected to an AP,
it /doesn't/ actually work now, which is my point.
johannes
Johannes Berg <johannes@...> writes:
> To avoid such mistakes in the future, disallow adding a
> wireless interface to a bridge.
Hello,
after the latest git pull my Linux AP stopt working
because the system is not allowed to add the wlan0
interface to a bridge.
I bisected the problem and ended up here.
So my question is, what is the right way to go after
this patch, to bridge the wireless with the wired
network interface on the AP, if bridging of the wlan
interface isn't allowed anymore?
Routing isn't an option here, because the two interfaces
should form one common boadcast domain.
It have worked fine all the time and the hostapd
documantaion at the linuxwireless.org
(http://linuxwireless.org/en/users/Documentation/hostapd#Configuring_hostapd)
describes how to bridge both interfaces on the AP, too.
And from now on all that should be wrong?
Sorry, I am confused.
On Fri, 2009-12-11 at 13:18 +0000, Markus Baier wrote:
> So I will remove the wlan0 line from bridge section
> of the gentoo net rc-script and hope that hostapd
> will take over that task.
Well you do have to configure it to do that, but that should be one line
in the hostapd config.
johannes
On Fri, 2009-12-11 at 12:39 +0000, Markus Baier wrote:
> Johannes Berg <johannes@...> writes:
>
> > To avoid such mistakes in the future, disallow adding a
> > wireless interface to a bridge.
>
> Hello,
> after the latest git pull my Linux AP stopt working
> because the system is not allowed to add the wlan0
> interface to a bridge.
You're mistaken. You _can_ still bridge an AP interface, it just needs
to be in AP mode. You should be using hostapd to control the bridging.
johannes
Hi, thanks for the fast reply
Ok, that is my fault.
At the moment I bridge the interfaces at boot time
before the start of the hostapd daemon.
So I will remove the wlan0 line from bridge section
of the gentoo net rc-script and hope that hostapd
will take over that task.
Tanks,
Markus