Re: [RFC 1/1] net: move IFF_LIVE_ADDR_CHANGE to public flag

[James Prestwood <prestwoj@gmail.com>]

Forgot to CC Johannes.

Thanks

On Thu, 2022-08-04 at 12:23 -0700, James Prestwood wrote:
> On Thu, 2022-08-04 at 11:43 -0700, Jakub Kicinski wrote:
> > On Thu,  4 Aug 2022 10:43:07 -0700 James Prestwood wrote:
> > > By exposing IFF_LIVE_ADDR_CHANGE to userspace it at least gives
> > > an
> > > indication that we can successfully randomize the address and
> > > connect. In the worst case address randomization can be avoided
> > > ahead of time. A secondary win is also time, since userspace can
> > > avoid a power down unless its required which saves some time.
> > 
> > It's not a generic thing tho, it's most of an implicit argument 
> > to eth_mac_addr(). Not all netdevs are Ethernet.
> > 
> > The semantics in wireless are also a little stretched because
> > normally
> > if the flag is not set the netdev will _refuse_ (-EBUSY) to change
> > the
> > address while running, not do some crazy fw reset.
> 
> Sorry if I wasn't clear, but its not nl80211 doing the fw reset
> automatically. The wireless subsystem actually completely disallows a
> MAC change if the device is running, this flag isn't even checked.
> This
> means userspace has to bring the device down itself, then change the
> MAC.
> 
> I plan on also modifying mac80211 to first check this flag and allow
> a
> live MAC change if possible. But ultimately userspace still needs to
> be
> aware of the support.
> 
> > 
> > Perhaps we should wait for Johannes to return form vacation but my
> > immediate reaction would be to add a knob (in wireless?) that
> > controls
> > whether the reset dance is allowed.
> 
> Ok sounds good. Lets see what Johannes has to say.
>