| Message ID | 20190913195908.7871-1-prestwoj@gmail.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | [1/2] nl80211: Add LIVE_ADDR_CHANGE feature | expand |
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? johannes
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. Thanks, James > > johannes >
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? And in nl80211 you'd need the flag for if you actually have the "change MAC address during connect" attribute. johannes
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? > > And in nl80211 you'd need the flag for if you actually have the > "change > MAC address during connect" attribute. > > johannes >
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 > > > >
Hi, > > > 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? I guess RTNL would be the right place? This can hardly be specific to wireless, the flag comes from elsewhere. johannes
Hi Johannes, On Tue, 2019-10-01 at 11:14 +0200, Johannes Berg wrote: > Hi, > > > > > 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? > > I guess RTNL would be the right place? This can hardly be specific to > wireless, the flag comes from elsewhere. I do see where your coming from, and maybe the answer is both RTNL and NL80211? In this context a NL80211 flag would mean something different than only putting a flag into RTNL. The NL80211 flag means this device supports changing the MAC while running and not offchannel/scanning. Which is what -EBUSY would mean in this context. Managing the offchannel/scanning work is only possible with a NL80211 application. An RTNL only application has no idea about scanning/offchannel work, so it has no way of knowing what -EBUSY means in the wireless device context, or a way to prevent this from happening (stopping scanning or offchannel before changing the MAC). Now, another example would be an RTNL application that only cares about non-wireless devices (like ethernet), and in this case it could benefit from some type of RTNL specific flag and not care about a NL80211 flag. Since there is no such application that cares about this RTNL flag (since it doesn't exist) I would say that adding NL80211 flag is the way to go. If someone wants to add an RTNL flag I would say that is appropriate too. But in terms of this feature, a NL80211 flag is really what fits best since the changes are wireless specific. Thanks, James > > johannes >
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index bf7c4222f512..0ceb945a08fb 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -5481,6 +5481,14 @@ enum nl80211_feature_flags { * @NL80211_EXT_FEATURE_SAE_OFFLOAD: Device wants to do SAE authentication in * station mode (SAE password is passed as part of the connect command). * + * @NL80211_EXT_FEATURE_LIVE_ADDR_CHANGE: Device can perform a MAC address + * change without having to bring the underlying network device down + * first. For example, in station mode this can be used to vary the + * origin MAC address prior to a connection to a new AP for privacy + * or other reasons. Note that certain driver specific restrictions + * might apply, e.g. no scans in progress, no offchannel operations + * in progress, and no active connections. + * * @NUM_NL80211_EXT_FEATURES: number of extended features. * @MAX_NL80211_EXT_FEATURES: highest extended feature index. */ @@ -5526,6 +5534,7 @@ enum nl80211_ext_feature_index { NL80211_EXT_FEATURE_EXT_KEY_ID, NL80211_EXT_FEATURE_STA_TX_PWR, NL80211_EXT_FEATURE_SAE_OFFLOAD, + NL80211_EXT_FEATURE_LIVE_ADDRESS_CHANGE, /* add new features before the definition below */ NUM_NL80211_EXT_FEATURES,
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 Signed-off-by: James Prestwood <prestwoj@gmail.com> --- include/uapi/linux/nl80211.h | 9 +++++++++ 1 file changed, 9 insertions(+)