From: "Jakub Kiciński" <moorray3@wp.pl>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Felix Fietkau <nbd@openwrt.org>,
linux-wireless@vger.kernel.org,
Helmut Schaa <helmut.schaa@googlemail.com>,
nietrywialneprzejscie@gmail.com
Subject: Re: [RFC 4/5] mac80211: enforce address verification on monitors
Date: Tue, 11 Jun 2013 15:01:29 +0200 [thread overview]
Message-ID: <20130611150129.0413f67d@north> (raw)
In-Reply-To: <1370951175.8356.17.camel@jlt4.sipsolutions.net>
On Tue, 11 Jun 2013 13:46:15 +0200, Johannes Berg wrote:
>On Fri, 2013-06-07 at 18:42 +0200, Jakub Kiciński wrote:
>
>> Now I can start two hostapd on those interfaces and
>> everything works just fine.
>>
>> # iw dev wlan0-1 set type monitor
>> # ip link set dev wlan0-1 address 00:00:fa:22:7c:00
>> # iw dev wlan0-1 set type managed
>> # ip link
>> 75: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>> link/ether 00:4f:6a:06:57:90 brd ff:ff:ff:ff:ff:ff
>> 76: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>> link/ether 00:00:fa:22:7c:00 brd ff:ff:ff:ff:ff:ff
>>
>> If I start hostapd on both interfaces now the one on wlan0-1
>> will not work correctly (hw won't ack frames).
>>
>> Also I think it's possible to change active flag on a monitor
>> while it's down (check in net/mac80211/cfg.c:75 only applies
>> to interfaces that are up):
>
> I think we should "just" move ieee80211_verify_mac() into do_open().
> Semantically anyway, I'm clearly handwaving a bit. But I would argue
> that you can set any MAC address that you like, as long as you don't
> bring the interface up, hence the verification really shouldn't be done
> when you assign the address but when you bring it up.
I've considered this initially. Two reasons that made me
think the current approach is cleaner are:
- it's nice when user gets the error during the action that
puts system in inconsistent state not some time later. I
personally hate to get vague EBUSY and have to figure out
what's wrong.
- suppose there are two interfaces, both down with
incompatible addresses. User adds third ifc, what address
should we assign to it?
Besides who would care what address does passive monitor
have? ;)
> Consider also this. Say you have this scenario:
>
> address mask: 00:00:00:00:00:03
> wlan0: 02:00:00:00:00:00
> wlan1: 02:00:00:00:00:01
>
> Now you want to change to
> wlan0: 03:00:00:00:00:00
> wlan1: 03:00:00:00:00:01
>
> It seems that right now you can't do this at all, which also seems
> wrong.
Right but I believe user would understand what is the problem
here and just remove and recreate one of the interfaces. They
have to be down to change MAC addr anyway.
Obviously this change is no matter for a big discussion. I
already feel like stealing your time a bit, because only
rt2x00 cares about this stuff anyway (I think). So please
let me know if my reasoning convinces you and if not I will
be happy to rewrite this the way you suggest.
-- kuba
next prev parent reply other threads:[~2013-06-11 13:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-07 13:36 [RFC 0/5] Fix mac addr enforcement on monitor interfaces Jakub Kicinski
2013-06-07 13:36 ` [RFC 1/5] mac80211: introduce __ieee80211_assign_perm_addr Jakub Kicinski
2013-06-07 13:36 ` [RFC 2/5] mac80211: return new mac address as soon as possible Jakub Kicinski
2013-06-07 13:36 ` [RFC 3/5] mac80211: always default to address compatible with mask Jakub Kicinski
2013-06-07 13:36 ` [RFC 4/5] mac80211: enforce address verification on monitors Jakub Kicinski
2013-06-07 13:49 ` Felix Fietkau
2013-06-07 14:04 ` Jakub Kiciński
2013-06-07 14:26 ` Felix Fietkau
2013-06-07 16:42 ` Jakub Kiciński
2013-06-11 11:46 ` Johannes Berg
2013-06-11 13:01 ` Jakub Kiciński [this message]
2013-06-11 15:14 ` Johannes Berg
2013-06-11 19:13 ` Jakub Kiciński
2013-06-07 13:36 ` [RFC 5/5] mac80211: assign right mac addr to active monitors Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130611150129.0413f67d@north \
--to=moorray3@wp.pl \
--cc=helmut.schaa@googlemail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@openwrt.org \
--cc=nietrywialneprzejscie@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).