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
Last revision Both sides next revision
addressrandomization [2020/03/27 16:46]
James Prestwood
addressrandomization [2020/03/27 16:58]
James Prestwood
Line 39: Line 39:
 === Scenario #1 === === Scenario #1 ===
 <​code>​ <​code>​
-IWD                   ​RTNL ​          ​External Process+IWD                   ​RTNL ​              ​External Process
  ​| ​                     | <​--------- Power Down |  ​| ​                     | <​--------- Power Down |
  | Power Down -------->​ |                       |  | Power Down -------->​ |                       |
Line 53: Line 53:
 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. 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.
  
 +=== Scenario #2 ===
 +<​code>​
 +IWD                   ​RTNL ​              ​External Process
 + ​| ​                     |                       |
 + | Power Down -------->​ |                       |
 + | Success <​----------- |                       |
 + ​| ​                     | <​----------- Power Up |
 + ​| ​                     | ----------->​ Success ​ |
 + | Change MAC -------->​ |                       |
 + | Failed <​----------- ​ |                       |
 +</​code>​
 +
 +In the above example an external process brings the interface up after IWD powers it down, but before changing the MAC. This would result in the MAC change operation failing, resulting in a failed connection attempt. Ultimately this is recoverable and issuing another connect command should work. This is quite unlikely since any external process shouldn'​t be trying to bring an interface up that is already up.
  
 +==== Solutions ====
 +There are several solutions which have been looked at, all of which require kernel changes. The optimal solution would be to allow the adapters MAC address to be changed without powering down.
addressrandomization.txt ยท Last modified: 2020/03/27 17:18 by James Prestwood