On Fri, Jan 21, 2022 at 08:26:18AM +0100, Christian Ehrhardt wrote: > > Hi, > > On Fri, Jan 21, 2022 at 12:00:54AM -0700, Theo de Raadt wrote: > > > In addition, I checked the code of dhclient and while it does listen > > > to the RTM_80211INFO messages it will only use them to do a RESTART (drop > > > things it thinks it knows about the interface and re-read all the > > > information) which is a good thing. It will not start sending > > > messages early while the link is still down. > > > > dhclient is being used by fewer and fewer people. Please focus on the > > other route socket listeners, there are many. > > I did grep all of "src" before and added all the patches in > "ports", now. I'm grepping for the RTM_80211INFO constant as > the change only affects when this particular message type is sent. > Any user of the message would have to use this constant somehow, right? > > Apart from wpa_supplicant the only users are: > - dhclient which is fine. > - route prints the message contents in monitor mode but does > not use the message otherwise.
Right. I took another look at this and I agree with your analysis now. With dhclient being phased out, wpa_suppplicant is the only active user of this routing message. Any potential future users can simply adapt to the new behaviour your patch introduces; the only downside I see is that we might generate redundant messages. Which could be handled by userland, or could be eliminated by simply not sending this message when link goes up. The original purpose of this message was indeed to help dhclient. Because dhclient identifies DHCP servers based on IP address, any two wifi networks using the same IP subnet would collide in the lease database without an extra key such as the SSID. The link-state issues I recalled was in fact a different problem: There were drivers which allowed link to go UP before a WPA key was installed in the device. This has been fixed to make dhclient happy. Our the new DHCP daemon does not use this messsage (yet?), it only looks for link state going UP. I don't know if this is a problem that should be fixed or if the existing code works well enough. In any case, new code to handle the message would still need to be written for that daemon. Around the same time dhclient was patched, wpa_supplicant was patched in ports to handle this message as well. Roaming with wpa_supplicant was tested at a ccc congress and it was apparently working at the time. I was not involved in these wpa_supplicant changes; I do not use it, and I do not remember being involved much, if at all, in the testing that was being done. I definitely did not run wpa_supplicant myself. The difference between successful roaming and failed roaming followed by a new association is just a relatively small dip in the availability of link. This could easily be missed during casual testing at a conference. Looking at the kernel and wpa_supplicant code, what you are describing does not look like a new problem to me. The 80211 info routing message has always been sent when link state becomes UP, which only happens once the WPA handshake completes. In case of 802.1x the handshake happens when wpa_supplicant's ioctl triggers ieee80211_keyrun(). I don't see how this could ever have worked, except by accident as you described: Userland's attempt to associate to BSSID zero (or any previous BSSID) might complete a kernel-side handshake against the correct BSSID successfully, at which point wpa_supplicant gets notified and now knows the correct BSSID. Which is of course entirely backwards.
