Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     Jeff Johnson <jjohnson@codeaurora.org>,
        James Prestwood <prestwoj@gmail.com>
Cc:     linux-wireless@vger.kernel.org,
        linux-wireless-owner@vger.kernel.org
Subject: Re: [RFC 0/1] Allow MAC change on up interface
In-Reply-To: <46810d9dbb674fb8d8fb442f2418868a@codeaurora.org>
References: <20190815185702.30937-1-prestwoj@gmail.com> <46810d9dbb674fb8d8fb442f2418868a@codeaurora.org>
Date:   Fri, 16 Aug 2019 11:56:23 +0200
Message-ID: <877e7dwi0o.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Jeff Johnson <jjohnson@codeaurora.org> writes:

> On 2019-08-15 11:57, James Prestwood wrote:
>>  - Adds a new NL80211_ATTR for including a "random mac" to
>>    CMD_CONNECT. This MAC is passed down the stack and gets set to
>>    the net_device's address.
>
> My initial reaction is that I'd avoid using the term "random".

+1 - from the description I was expecting calls to get_random_bytes() in
the setter function :)

> For some use cases the address may truly be random, but for other use
> cases it may be derived, perhaps in an AP-specific manner. Other terms
> which may be more appropriate are "spoofed mac", "administered mac",
> etc.

"custom mac"?