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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
