On Fri, 2018-01-05 at 22:04 +0100, Marcel Holtmann wrote:
Hi Dan,I am in favor of address randomization even while it has limited affect, but at least for background scanning it is useful. However doing this via RTNL is causing a weird layer violation and all sorts of potential races and issues. This needs to be done with full awareness of cfg80211 and thus via nl80211. So iwd should do it. And iwd should just expose an on/off switch for WiFi Privacy.TL;DR: the policy of which MAC address to use (and when) is flexible and present in NetworkManager configuration. And it's more then a simple randomize on/off switch. === A smaller reason is, that some people have strong opinions and consider important which bits of the address to scramble (and choose a well known manufacturer OUI)[1]. I personally don't agree with the importance of such considerations, but I'd like NetworkManager to be the first choice for people with this particular need -- regardless of whether this need is real or only perceived. In NM you can configure how the bits are scrambled very flexible. Both while scanning[2] and while being associated[3]. More interesting is, I don't only want to have a random MAC address while scanning, but also while being associated. My permanent MAC address should never ever be reveiled. But a new random MAC address on each new association isn't exactly what you want either, because then I get a new IP address from DHCP each time and have to redo captive portal login. So, I want for each of my Wi-Fi profiles a different, stable MAC address. Actually, for public networks like a hotel, I want to use a stable MAC address for a limited amount of time. The example in [4] show how to do that in NM. ===I have nothing against an option that says generate a new MAC address for this SSID and keep using it from that time forward.If I understand correctly, you agree that the MAC address depends on the profile.It is a bit counterproductive if nl80211 doesn’t allow to specify the MAC address for association. Since powering down WiFi, changing the address and powering back up is something that I am strictly against. So if these things are what people really want, then neither NM nor iwd should actually do the heavy lifting for it. It should be done by the wireless stack in the kernel.Ok, whatever works best.That said iwd should cope Ok with the MAC address changing behind its back if it receives the RTNL notification (RTM_NEWLINK) if it isn't connected. It always updates it's copy of the address on a RTM_NEWLINK so the race condition shouldn't be present I suppose.I would think so too. NM change the MAC address via RTNL only while scanning, early during activation, and late during deactivation. As the wireless daemon does/should not autoactivate the device against NM's wish and NM determines that the device is deactivated only after an event from iwd. Hence, there shouldn't be a race of NM interfering while being connected. The race is only while scanning and iwd should just cope with that. Alternatively/additionally, a SetMacAddress() D-Bus call would avoid any race and allow to leave the decision which address to user to somebody closer to the user.It will not be as simple as that. You need to leave iwd with the decision making for connecting to known WiFi networks. It just isn’t as dumb as wpa_supplicant and from a NM perspective, you should be doing as little as you do with BlueZ or oFono. This means iwd needs to be told what to do and not just an address. It doesn’t matter if it is via a D-Bus call or RTNL. iwd remembers known networks and will connect to them if they are in range, roam automatically and also switch networks if it makes sense. That means any randomization policy would have to be executed inside iwd and not outside. As stated above, if you want different MAC addresses per SSID, then that needs to be inside iwd. So many things in the wpa_supplicant design led to “hacks” outside to add features and that really has to stop. It is not maintainable and the corner cases and race condition this architecture causes is just crazy.For NM, at each moment not all its connection profiles are candidate for connecting automatically. The list of which profiles can be autoactivated depends on NM internal state, for example - is the profile even configured to allow autoactivation? - is the user owning the connection logged in (if it's restricted to a user)? - if the profile requires secrets, is somebody previledged around to potentially provide them? - was the connection previously manually disconnected by the user (which marks it as blocked from autoconnecting again) - did a previous connection attempt fail, e.g. no DHCP lease. If it failed $configurable times, it will be blocked for a few minutes. With supplicant, NM intersects the list of autoconnect candidates with the list from the scan-list, and decides which to (auto) activate. As far as supplicant is concerned, this is not happening automatically, and there is no race. If I understand you, the reason to let iwd automatically pick a network, is because iwd knows better. But in case there are multiple autoconnect candidates that could be activated, then NM chooses the candidate which - has the highest autoconnect priority (configurable) - was used the least long ago. Indeed, NM doesn't consider the signal strength and other Wi-Fi properties. It's a missing feature. How is iwd choosing automatically? Choosing based on signal strength and encryption parameters would be a nice feature, but what about non- Wi-Fi related factors. How will iwd allow NM to contribute to that decision?Note that choosing based solely on signal strength can be problematic. It works great if you are somewhere that has only one AP you've connected to before. But the moment you have multiple different SSIDs that you've connected to before, it starts to have issues. An example case was the old Red Hat (or was it Mozilla, I forget, they were right down the street from each other) office in Mountain View, which was just upstairs from a Starbucks. Depending on where you were in the office, Starbuck's APs could be stronger than the office ones. These days even "public" APs have strong encryption with automatic login (HotSpot 2.0, EAP-SIM, etc) too. --- Looking at the iwd code, it appears to: 1) only autoconnect to networks that have been successful at least once (see comment in network.c::network_rankmod()) 2) BSSs are ranked according to factors in scan.c::scan_bss_compute_rank() which is heavily biased towards signal strength. After that, better encryption, 5G, and low utilization (read from an IE) is preferred. 3) then the BSS is added to its network object; network objects are tracked in a list and the most recently connected networks since IWD has been running are first; the rest are in reverse-order-seen (see network_info_get()). 4) when generating the autoconnect list, the BSS's rank from #2 is multiplied by a "rankmod" number (<=1) that depends on where the BSS's network is in the list from #3 (device.c::process_bss()). So BSSs that were previously connected to have a lower rank, and BSSs that haven't been connected to yet this IWD run could be even lower. However, since the BSSs have ranks themselves, this modifier appears to allow situations where IWD would switch from SSID A to SSID B, even if A was still visible, when there is a much-stronger SSID B AP. I could be wrong of course. But this would break expectations around how NM currently works, where it holds on to the current SSID until the connection is broken. Perhaps this is desirable, maybe it allows the dual-channel AP situation where for example you are on 5GHz SSID A and move to another room, so A becomes low signal, but the 2.4GHz SSID B is now much stronger so IWD reconnects to that one. However, this could result in an IP address change depending on how your AP works, which would break existing connections. Which is one reason NM doesn't normally switch between SSIDs. I'm sure Marcel will correct anything I've gotten wrong above.a lot of these can be changed or fine-tuned while we are making iwd better. However the big point is that iwd knowns about the known networks and stores them. So we need to work with basic premise of this. Same as BlueZ knowns its PAN devices and oFono knows its SIM cards and APNs. That really has to be the assumption first and foremost.
That BlueZ remembers PAN devices makes sense, because these devices were paired outside of NetworkManager, using bluetooth tools. BlueZ/oFono autonoumously connects? I didn't think that is the case, it it? AFAIS, it's always NetworkManager which initiates the activation.
And yes, I know wpa_supplicant dealt everybody a bad hand and told you to deal with it. However we need to change this mantra towards something clean and modern. Especially since there are so many WiFi extensions that will allow you to make decision that wpa_supplicant will never give you access to. So lets figure out what is needed and tune around that.
For the IP address part, I will assume that iwd will actually start doing DHCP itself soon. That is just needed if you look at some of the features that tell you about IP address during association or the brain-dead things like P2P. We are toying with this, but I almost certain this will go in this direction. Similar on how cellular modems actually do it. The IP address is a property of the WiFi daemon and not the daemon that manages the network connections.
With WWan/ModemManager, pppoe/pppd, VPNs, the IP addressing is also negotiated outside of NM. Also, supplicant supports DHCP ( https://w1.fi/cgit/hostap/tree/src/ap/fils_hlp.c#n150 ) -- although NM doesn't support that. It's a missing Wi-Fi feature, but I don't see a fundamental issue with NM+supplicant+FILS). But while these components negotiate IP addresses one way or another, they only report the address/routes to NM, and NM might them. Would iwd actively configure addresses/routes? If not, that is fine and not different from e.g. WWAN. I think iwd configuring addresses is wrong. Because this affects routing, which very much determines the system-wide behavior and needs to interplay with the interfaces. For example, in NetworkManager you can: - Configure ipv4.route-metric. For example, if you connect to your home network both via cable and Wi-Fi, (configurably) cable will be preferred. Or if you activate WWAN and Wi-Fi at the same time, the default- route gets a metric based on the device priority (configurably). (in some cases, the route-metric might even be determined the moment when starting associating. In combination with iwd autonomously connecting, you couldn't even configure the desired route-metric in the iwd profile). - configure ipv4.never-default: controls whether the interface will get the default route. - configure additional manual routes for that interface. If iwd and NM both configure routes, this is racy. - Configure ipv4.route-table. An uncommon feature, where you can put the routes from that interface in a separate routing table for policy routing. - protect routes on other interfaces so that a malicious DHCP server cannot hijack traffic (https://bugzilla.gnome.org/show_bug.cgi?id=749376 ). While this is not implemented yet and hard to get right conceptually, it would be a great feature.
When it comes to signal strength and cases that you get bumped off the SSID, then that is what can happen. It is especially sad if the AP will not use neighbor cell reporting to allow you to jump onto the next AP. But that is life and it really all depends on the speed of DHCP to get you back onto your network, but that feeds into my comment above where DHCP has to become part of the WiFi daemon. The other part is that iwd really has all the information to know your network. It knows when it saw them last, connected last and eventually even what your surrounding SSIDs were. For example even you can not connect to your home neighbors encrypted WiFi, the pure existent of it around you, means you might want to connect to your home SSID and preferably _quickly_ (last known channel) for it and connect. This is knowledge and use of this knowledge that really only works with iwd and fiddling any of this through wpa_supplicant is crazy. And some hardware has actually offload capabilities for background scanning around the concept of neighboring SSIDs.
I don't understand how this takes into account other factors that that seem very important to me. If NM disconnects from one BSSID, it might want to re-connect to the same or another. It's unclear how iwd would be able to handle the difference, if it doesn't allow to specify which BSSID to connect to.
Please keep in mind that iwd is far away from having all the features we envisioned. It is getting there and NM really needs to move towards trusting iwd. It is the only way we can improve the WiFi experience in desktop Linux.
It's not about trusting. It's about how NM can use iwd's API to implement use-cases that are useful. Maybe not useful in the car, but on a notebook. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part