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
Previous revision
addressrandomization [2020/03/27 16:46]
James Prestwood
addressrandomization [2020/03/27 17:18] (current)
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. This solves both the timing cost and the race conditions. This has been implemented,​ but met with opposition from the maintainers:​
 +https://​marc.info/?​l=linux-wireless&​m=156762443831647&​w=2
 +
 +A similar solution could also be implemented for RTNL, where-as the above patches are only in nl80211. The RTNL path was not even pursued because that subsystem is quite old and invasive changes are difficult to get upstreamed.
 +
 +Another solution would be to include some kind of cookie associated with RTNL requests. This would allow IWD to determine **who** caused an interface to go down. This would eliminate the race conditions, but the timing cost would still exist.
  
addressrandomization.1585327603.txt.gz ยท Last modified: 2020/03/27 16:46 by James Prestwood