* NL80211_SCAN_FLAG_RANDOM_ADDR ?
@ 2019-04-11 22:30 Denis Kenzior
2019-04-11 23:19 ` Ben Greear
2019-04-12 9:26 ` Sergey Matyukevich
0 siblings, 2 replies; 8+ messages in thread
From: Denis Kenzior @ 2019-04-11 22:30 UTC (permalink / raw)
To: linux-wireless
Hi,
I've been poking around at how this flag is used and I noticed this
check in net/wireless/nl80211.c:
nl80211_check_scan_flags()
if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
int err;
if (!(wiphy->features & randomness_flag) ||
(wdev && wdev->current_bss))
return -EOPNOTSUPP;
The above disallows the use of RANDOM_ADDR for scans while connected.
The nl80211.h uapi header seems to concur:
"@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports
using a random MAC address during scan (if the device is unassociated);"
However, if I create a P2P Device (in addition to the default STA
device), the kernel happily lets me scan on the wdev while the STA
interface is connected.
sudo iw phy0 interface add p2p type __p2pdev
sudo iw wdev 0x2 p2p start
sudo iw wdev 0x2 scan randomize
So the immediate question I have is, should the RANDOM_ADDR flag indeed
be limited to unassociated STA interfaces? It would seem the hardware
is capable randomizing even when connected? Please educate me :)
Regards,
-Denis
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-11 22:30 NL80211_SCAN_FLAG_RANDOM_ADDR ? Denis Kenzior @ 2019-04-11 23:19 ` Ben Greear 2019-04-11 23:20 ` Ben Greear 2019-04-12 9:26 ` Sergey Matyukevich 1 sibling, 1 reply; 8+ messages in thread From: Ben Greear @ 2019-04-11 23:19 UTC (permalink / raw) To: Denis Kenzior, linux-wireless On 4/11/19 3:30 PM, Denis Kenzior wrote: > Hi, > > I've been poking around at how this flag is used and I noticed this check in net/wireless/nl80211.c: > > nl80211_check_scan_flags() > > if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { > int err; > > if (!(wiphy->features & randomness_flag) || > (wdev && wdev->current_bss)) > return -EOPNOTSUPP; > > > The above disallows the use of RANDOM_ADDR for scans while connected. The nl80211.h uapi header seems to concur: > > "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports using a random MAC address during scan (if the device is unassociated);" > > However, if I create a P2P Device (in addition to the default STA device), the kernel happily lets me scan on the wdev while the STA interface is connected. > > sudo iw phy0 interface add p2p type __p2pdev > sudo iw wdev 0x2 p2p start > sudo iw wdev 0x2 scan randomize > > So the immediate question I have is, should the RANDOM_ADDR flag indeed be limited to unassociated STA interfaces? It would seem the hardware is capable > randomizing even when connected? Please educate me :) You can be sure that each driver/hardware has its own bugs and limitations related to this. Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not ACK probe responses sent back to an MAC address that is not that of the station itself. And changing the mac of a station would require complete re-association AFAIK. That is likely just one of the many issues. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-11 23:19 ` Ben Greear @ 2019-04-11 23:20 ` Ben Greear 2019-04-12 1:26 ` Denis Kenzior 0 siblings, 1 reply; 8+ messages in thread From: Ben Greear @ 2019-04-11 23:20 UTC (permalink / raw) To: Denis Kenzior, linux-wireless On 4/11/19 4:19 PM, Ben Greear wrote: > On 4/11/19 3:30 PM, Denis Kenzior wrote: >> Hi, >> >> I've been poking around at how this flag is used and I noticed this check in net/wireless/nl80211.c: >> >> nl80211_check_scan_flags() >> >> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { >> int err; >> >> if (!(wiphy->features & randomness_flag) || >> (wdev && wdev->current_bss)) >> return -EOPNOTSUPP; >> >> >> The above disallows the use of RANDOM_ADDR for scans while connected. The nl80211.h uapi header seems to concur: >> >> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports using a random MAC address during scan (if the device is unassociated);" >> >> However, if I create a P2P Device (in addition to the default STA device), the kernel happily lets me scan on the wdev while the STA interface is connected. >> >> sudo iw phy0 interface add p2p type __p2pdev >> sudo iw wdev 0x2 p2p start >> sudo iw wdev 0x2 scan randomize >> >> So the immediate question I have is, should the RANDOM_ADDR flag indeed be limited to unassociated STA interfaces? It would seem the hardware is capable >> randomizing even when connected? Please educate me :) > > You can be sure that each driver/hardware has its own bugs and limitations related to this. > > Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not ACK probe responses > sent back to an MAC address that is not that of the station itself. And changing the mac of a station > would require complete re-association AFAIK. That is likely just one of the many issues. I should add: If you really want to scan in this manner, you could just create a new station vdev with random addr and have it do the scanning, then delete it when done? The original station will continue on its way unmolested. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-11 23:20 ` Ben Greear @ 2019-04-12 1:26 ` Denis Kenzior 2019-04-12 2:15 ` Ben Greear 0 siblings, 1 reply; 8+ messages in thread From: Denis Kenzior @ 2019-04-12 1:26 UTC (permalink / raw) To: Ben Greear, linux-wireless Hi Ben, On 04/11/2019 06:20 PM, Ben Greear wrote: > On 4/11/19 4:19 PM, Ben Greear wrote: >> On 4/11/19 3:30 PM, Denis Kenzior wrote: >>> Hi, >>> >>> I've been poking around at how this flag is used and I noticed this >>> check in net/wireless/nl80211.c: >>> >>> nl80211_check_scan_flags() >>> >>> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { >>> int err; >>> >>> if (!(wiphy->features & randomness_flag) || >>> (wdev && wdev->current_bss)) >>> return -EOPNOTSUPP; >>> >>> >>> The above disallows the use of RANDOM_ADDR for scans while connected. >>> The nl80211.h uapi header seems to concur: >>> >>> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports >>> using a random MAC address during scan (if the device is unassociated);" >>> >>> However, if I create a P2P Device (in addition to the default STA >>> device), the kernel happily lets me scan on the wdev while the STA >>> interface is connected. >>> >>> sudo iw phy0 interface add p2p type __p2pdev >>> sudo iw wdev 0x2 p2p start >>> sudo iw wdev 0x2 scan randomize >>> >>> So the immediate question I have is, should the RANDOM_ADDR flag >>> indeed be limited to unassociated STA interfaces? It would seem the >>> hardware is capable randomizing even when connected? Please educate >>> me :) >> >> You can be sure that each driver/hardware has its own bugs and >> limitations related to this. >> >> Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not >> ACK probe responses >> sent back to an MAC address that is not that of the station itself. >> And changing the mac of a station >> would require complete re-association AFAIK. That is likely just one >> of the many issues. Yes, I understand that some hardware would not support this. But the question is does this check belong at the nl80211 layer (e.g. no hardware can do this) vs somewhere at the driver layer + additional feature bit as needed. > > I should add: If you really want to scan in this manner, you could just > create a new station vdev with > random addr and have it do the scanning, then delete it when done? The > original station will continue on > its way unmolested. > So you mean something like: sudo iw phy0 interface add sta2 type station sudo iw dev sta2 scan randomize command failed: Network is down (-100) sudo ifconfig sta2 up SIOCSIFFLAGS: Device or resource busy I guess I'm running into this: valid interface combinations: * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1, total <= 3, #channels <= 2 Or did you mean something else? Regards, -Denis ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-12 1:26 ` Denis Kenzior @ 2019-04-12 2:15 ` Ben Greear 0 siblings, 0 replies; 8+ messages in thread From: Ben Greear @ 2019-04-12 2:15 UTC (permalink / raw) To: Denis Kenzior, linux-wireless On 04/11/2019 06:26 PM, Denis Kenzior wrote: > Hi Ben, > > On 04/11/2019 06:20 PM, Ben Greear wrote: >> On 4/11/19 4:19 PM, Ben Greear wrote: >>> On 4/11/19 3:30 PM, Denis Kenzior wrote: >>>> Hi, >>>> >>>> I've been poking around at how this flag is used and I noticed this check in net/wireless/nl80211.c: >>>> >>>> nl80211_check_scan_flags() >>>> >>>> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { >>>> int err; >>>> >>>> if (!(wiphy->features & randomness_flag) || >>>> (wdev && wdev->current_bss)) >>>> return -EOPNOTSUPP; >>>> >>>> >>>> The above disallows the use of RANDOM_ADDR for scans while connected. The nl80211.h uapi header seems to concur: >>>> >>>> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports using a random MAC address during scan (if the device is unassociated);" >>>> >>>> However, if I create a P2P Device (in addition to the default STA device), the kernel happily lets me scan on the wdev while the STA interface is connected. >>>> >>>> sudo iw phy0 interface add p2p type __p2pdev >>>> sudo iw wdev 0x2 p2p start >>>> sudo iw wdev 0x2 scan randomize >>>> >>>> So the immediate question I have is, should the RANDOM_ADDR flag indeed be limited to unassociated STA interfaces? It would seem the hardware is capable randomizing even when connected? Please educate me :) >>> >>> You can be sure that each driver/hardware has its own bugs and limitations related to this. >>> >>> Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not ACK probe responses >>> sent back to an MAC address that is not that of the station itself. And changing the mac of a station >>> would require complete re-association AFAIK. That is likely just one of the many issues. > > Yes, I understand that some hardware would not support this. But the question is does this check belong at the nl80211 layer (e.g. no hardware can do this) vs somewhere at the driver layer + additional feature bit as needed. > >> >> I should add: If you really want to scan in this manner, you could just create a new station vdev with >> random addr and have it do the scanning, then delete it when done? The original station will continue on >> its way unmolested. >> > > So you mean something like: > sudo iw phy0 interface add sta2 type station > sudo iw dev sta2 scan randomize > command failed: Network is down (-100) > sudo ifconfig sta2 up > SIOCSIFFLAGS: Device or resource busy > > I guess I'm running into this: > > valid interface combinations: > * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1, > total <= 3, #channels <= 2 > > Or did you mean something else? You got my meaning, I guess your driver cannot support it. It should work with ath10k, at least the versions I use. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-11 22:30 NL80211_SCAN_FLAG_RANDOM_ADDR ? Denis Kenzior 2019-04-11 23:19 ` Ben Greear @ 2019-04-12 9:26 ` Sergey Matyukevich 2019-04-12 15:00 ` Denis Kenzior 1 sibling, 1 reply; 8+ messages in thread From: Sergey Matyukevich @ 2019-04-12 9:26 UTC (permalink / raw) To: Denis Kenzior; +Cc: linux-wireless@vger.kernel.org > I've been poking around at how this flag is used and I noticed this > check in net/wireless/nl80211.c: > > nl80211_check_scan_flags() > > if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { > int err; > > if (!(wiphy->features & randomness_flag) || > (wdev && wdev->current_bss)) > return -EOPNOTSUPP; > > > The above disallows the use of RANDOM_ADDR for scans while connected. > The nl80211.h uapi header seems to concur: > > "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports > using a random MAC address during scan (if the device is unassociated);" > > However, if I create a P2P Device (in addition to the default STA > device), the kernel happily lets me scan on the wdev while the STA > interface is connected. > > sudo iw phy0 interface add p2p type __p2pdev > sudo iw wdev 0x2 p2p start > sudo iw wdev 0x2 scan randomize > > So the immediate question I have is, should the RANDOM_ADDR flag indeed > be limited to unassociated STA interfaces? It would seem the hardware > is capable randomizing even when connected? Please educate me :) Hello Denis, IIUC, this feature could be introduced to support Android Compatibility Definition Document (CDD). Those documents are available at the following page: https://source.android.com/compatibility/cdd For instance, in the latest CDD randomized scan requirements are described in the section 7.4.2. It looks like current high level nl80211 API follows those recommendations. Probably it has been implemented with STA use-case in mind, that is why you can use that flag for P2P connection. But, as Ben pointed out, actual application of this flag may depend on implementation in firwmare and hardware. Regards, Sergey ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-12 9:26 ` Sergey Matyukevich @ 2019-04-12 15:00 ` Denis Kenzior 2019-04-12 21:21 ` Arend Van Spriel 0 siblings, 1 reply; 8+ messages in thread From: Denis Kenzior @ 2019-04-12 15:00 UTC (permalink / raw) To: Sergey Matyukevich; +Cc: linux-wireless@vger.kernel.org Hi Sergey, On 04/12/2019 04:26 AM, Sergey Matyukevich wrote: >> I've been poking around at how this flag is used and I noticed this >> check in net/wireless/nl80211.c: >> >> nl80211_check_scan_flags() >> >> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) { >> int err; >> >> if (!(wiphy->features & randomness_flag) || >> (wdev && wdev->current_bss)) >> return -EOPNOTSUPP; >> >> >> The above disallows the use of RANDOM_ADDR for scans while connected. >> The nl80211.h uapi header seems to concur: >> >> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports >> using a random MAC address during scan (if the device is unassociated);" >> >> However, if I create a P2P Device (in addition to the default STA >> device), the kernel happily lets me scan on the wdev while the STA >> interface is connected. >> >> sudo iw phy0 interface add p2p type __p2pdev >> sudo iw wdev 0x2 p2p start >> sudo iw wdev 0x2 scan randomize >> >> So the immediate question I have is, should the RANDOM_ADDR flag indeed >> be limited to unassociated STA interfaces? It would seem the hardware >> is capable randomizing even when connected? Please educate me :) > > Hello Denis, > > IIUC, this feature could be introduced to support Android Compatibility > Definition Document (CDD). Those documents are available at the > following page: https://source.android.com/compatibility/cdd Thanks for the reference. It looks like a 'At a minimum you should/must do this' type of document. It doesn't look like it precludes the use of randomization when connected? > > For instance, in the latest CDD randomized scan requirements are described > in the section 7.4.2. It looks like current high level nl80211 API follows > those recommendations. Probably it has been implemented with STA use-case > in mind, that is why you can use that flag for P2P connection. But, as > Ben pointed out, actual application of this flag may depend on > implementation in firwmare and hardware. > Sure, understood. But this is exactly the point of my question. Is the check at the global level correct? Or should it be relaxed in case there is hardware out there that can randomize probe requests while connected? From my test it would seem this is possible? Or put another way, besides hardware limitations, are there reasons why you would not want to randomize probe request address when connected? Regards, -Denis ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ? 2019-04-12 15:00 ` Denis Kenzior @ 2019-04-12 21:21 ` Arend Van Spriel 0 siblings, 0 replies; 8+ messages in thread From: Arend Van Spriel @ 2019-04-12 21:21 UTC (permalink / raw) To: Denis Kenzior, Sergey Matyukevich; +Cc: linux-wireless@vger.kernel.org On 4/12/2019 5:00 PM, Denis Kenzior wrote: > Or put another way, besides hardware limitations, are there reasons why > you would not want to randomize probe request address when connected? I was hoping to find your answer using 'git blame'. You might already have tried that. The wdev->current_bss check was added by the commit below: commit ad2b26abc157460ca6fac1a53a2bfeade283adfa Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Jun 12 21:39:05 2014 +0200 cfg80211: allow drivers to support random MAC addresses for scan Add the necessary feature flags and a scan flag to support using random MAC addresses for scan while unassociated. The configuration for this supports an arbitrary MAC address value and mask, so that any kind of configuration (e.g. fixed OUI or full 46-bit random) can be requested. Full 46-bit random is the default when no other configuration is passed. Also add a small helper function to use the addr/mask correctly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Unfortunately it does not answer your question. My memory is lacking quite a bit but I think at the time it was not considered useful to have random mac address for scan while being associated. Your permanent mac address would be flying around anyway. Regards, Arend ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-04-12 21:21 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-04-11 22:30 NL80211_SCAN_FLAG_RANDOM_ADDR ? Denis Kenzior 2019-04-11 23:19 ` Ben Greear 2019-04-11 23:20 ` Ben Greear 2019-04-12 1:26 ` Denis Kenzior 2019-04-12 2:15 ` Ben Greear 2019-04-12 9:26 ` Sergey Matyukevich 2019-04-12 15:00 ` Denis Kenzior 2019-04-12 21:21 ` Arend Van Spriel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox