Johannes, On Fri, 2019-09-13 at 14:14 -0700, James Prestwood wrote: > On Fri, 2019-09-13 at 23:01 +0200, Johannes Berg wrote: > > On Fri, 2019-09-13 at 13:56 -0700, James Prestwood wrote: > > > Hi, > > > > > > On Fri, 2019-09-13 at 22:48 +0200, Johannes Berg wrote: > > > > On Fri, 2019-09-13 at 12:59 -0700, James Prestwood wrote: > > > > > Add a new feature bit signifying that the wireless hardware > > > > > supports > > > > > changing the mac address while the underlying net_device is > > > > > UP. Note > > > > > that this is slightly different from IFF_LIVE_ADDR_CHANGE as > > > > > additional > > > > > restrictions might be imposed by the hardware. Typical > > > > > restrictions > > > > > are: > > > > > - No connection is active on this interface, e.g. > > > > > carrier is > > > > > off > > > > > - No scan is in progress > > > > > - No offchannel operation is in progress > > > > > > > > Hmm, what do you need this patch for? > > > > > > > > IFF_LIVE_ADDR_CHANGE should be sufficient to discover it? > > > > > > Because userspace needs to know if this is supported? > > > IFF_LIVE_ADDR_CHANGE is a private flag... AFAIK userspace has no > > > way of > > > obtaining this. > > > > Oh, annoying. > > > > But that doesn't really mean that nl80211 is an appropriate place > > to > > advertise it, IMHO? > > The intention of the flag was not soley related to > CMD_CONNECT/CMD_AUTHENTICATE. Its an indication that the > hardware/driver supports a live address change. If you don't want it > here could you suggest a better location for it? Could we continue this discussion? Is there some other way you can think of to let userspace know that this feature is supported rather than an ext feature? Thanks, James > > > > > And in nl80211 you'd need the flag for if you actually have the > > "change > > MAC address during connect" attribute. > > > > johannes > > > >
