User Tools

Site Tools


addressrandomization

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
addressrandomization [2020/03/27 16:22]
James Prestwood
addressrandomization [2020/03/27 16:46]
James Prestwood
Line 22: Line 22:
 AddressOverride=11:​22:​33:​44:​55:​66 AddressOverride=11:​22:​33:​44:​55:​66
 </​code>​ </​code>​
 +
 +===== Caveats =====
 +
 +The networking subsystem has several caveats which limit the efficiency of MAC address randomization,​ as well as introduce potential race conditions. Both of these shortfalls come down to the fact that the adapter must be powered down to change the MAC address.
 +
 +==== The time cost ====
 +During testing it was found that it takes at least 300ms to power the adapter down, change the MAC, and power it back up. Since these new options were added on a per-network basis this delay more or less triples IWD's average connection time. This is a problem with any software using the RTNL subsystem for operations like this. There is even a note in the Android ([[https://​source.android.com/​devices/​tech/​connect/​wifi-mac-randomization|documentation]]):​
 +
 +''​Note:​ You may experience up to a three-second delay when connecting to a network due to the driver flushing saved scan results when the interface goes down. If this is the case, check with your silicon partners to resolve the issue.''​
 +
 +We have only measured this delay on a few cards, so its not out of the question that some cards may have a much longer delay. If you are seeing excessive delays we ask you to reach out on the mailing list or IRC.
 +
 +==== Race conditions ====
 +Since IWD is asynchronous and it takes some time to complete a MAC address change there is a potential for race conditions. This is an unfortunate consequence of the way RTNL was designed, at least in terms of powering the adapter. We have identified two potential race conditions which are unlikely to ever happen, but still possible. These scenarios involve an external process doing operations on the interface IWD manages.
 +
 +=== Scenario #1 ===
 +<​code>​
 +IWD                   ​RTNL ​          ​External Process
 + ​| ​                     | <​--------- Power Down |
 + | Power Down -------->​ |                       |
 + | Success <​----------- | --------->​ Success ​   |
 + ​| ​                     |                       |
 + | Change MAC -------->​ |                       |
 + | Success <​----------- |                       |
 + ​| ​                     |                       |
 + | Power Up ---------->​ |                       |
 + | Success <​----------- |                       |
 +</​code>​
 +
 +In the above example an external process brought the interface down just before IWD did. RTNL does not consider two down operations an error so it returns success on both. IWD does get a notification that the interface went down, but assumes this was its own doing. The MAC change operation continues and ultimately the interface is brought back up. To the external process (e.g. a user doing ''​ifconfig wlan0 down''​) it would appear as if their command had no effect as the interface would still be in an up state.
 +
 +
addressrandomization.txt ยท Last modified: 2020/03/27 17:18 by James Prestwood