netdev - Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Nov 2009 09:50:49 +1100
From:	Julian Calaby <julian.calaby@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	netdev <netdev@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Felix Fietkau <nbd@...nwrt.org>
Subject: Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces

On Wed, Nov 18, 2009 at 09:46, Johannes Berg <johannes@...solutions.net> wrote:
> On Wed, 2009-11-18 at 09:42 +1100, Julian Calaby wrote:
>> On Wed, Nov 18, 2009 at 07:48, Johannes Berg <johannes@...solutions.net> 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: julian.calaby@...il.com
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html