All of lore.kernel.org
 help / color / mirror / Atom feed
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 21:13:44 +0200	[thread overview]
Message-ID: <20130611211344.2251cf8f@north> (raw)
In-Reply-To: <1370963652.8356.51.camel@jlt4.sipsolutions.net>

On Tue, 11 Jun 2013 17:14:12 +0200, Johannes Berg wrote:
>
>>> 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?
>
> Right now you can assign the same addresses to multiple interfaces and
> then you can't bring them up. This happens for example if there are no
> more addresses to assign.

I didn't realise that. I will move the check into do_open() path as
suggested then.

  -- kuba 

  reply	other threads:[~2013-06-11 19:13 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
2013-06-11 15:14               ` Johannes Berg
2013-06-11 19:13                 ` Jakub Kiciński [this message]
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=20130611211344.2251cf8f@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.