On Mon, 2018-01-15 at 09:42 +0100, Marcel Holtmann wrote: > Hi Thomas, > > > > > > > > > > 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. > > > > actually with iwd you can also use iwd tools to connect your WiFi, > > you do not need to go through NM. And we need to support that kind > > of interaction as well. > > > > As I said before, I full realize that wpa_supplicant made you do > > everything, but with iwd that is no longer needed. For example you > > can have a dead simple UI element that just trigger WPS based > > connection. You do that via iwd and then move on with life. NM will > > pick up the new known network and its connection. Everybody will be > > happy. > > > > iwd is different than wpa_supplicant and it is a change for the > > better :) > > > > > > 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. > > > > Routes is a clear no. That is never part of the interface itself. > > For the IP address that is something we need to discuss. So far we > > have stayed away assigning IP addresses in the technology daemon > > and just told the managing entity above what these were or to run > > DHCP. > > > > So we think that DHCP needs to be in iwd (and for P2P that means > > client+server). We also arrived at the conclusion that BlueZ and > > oFono should do DHCP by themselves if no static IP addresses can be > > read. For DHCP to function nicely and efficiently however it is > > important that the IP address also gets configured on the > > interface. So I think that eventually we need to move towards that > > technology daemon controls the interface and its addresses. > > > > This needs a bit more thinking and research on who configures the > > IP, but the DHCP part is clearly moving into iwd. > > > > > 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). > > > > The route metric is clearly part of NM. That should not be in > > control of a technology daemon. > > > > > - configure ipv4.never-default: controls whether the interface > > > will > > > get the default route. > > > > See no problem here. Since iwd would never touch any routes. > > > > > - configure additional manual routes for that interface. If iwd > > > and > > > NM both configure routes, this is racy. > > > > No interest in routes. > > > > > - Configure ipv4.route-table. An uncommon feature, where you can > > > put the routes from that interface in a separate routing table > > > for > > > policy routing. > > > > Same as above, no interest in routes. > > > > > - 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. > > > > See also no conflict there. > > > > As I said, the routes and all its details is really not iwd > > business. So we are clear and agree on that. The IP address itself > > and its configuration is something where my current thinking is > > that this is owned by the technology daemon. And yes, I realize the > > issue with IP conflicts and overlaps. This needs a bit more > > thinking and looking into what RTNL actually provides and lets you > > control. > > actually I take this back a little. Having spent the weekend reading > up on VRF and policy routing, I think that iwd should actually > maintain the routes for its wlan0 interface (including default route > or other routes learned via DHCP). However it should do that in a > separate routing table. I think that NM should tell iwd what routing > table id it wants it to use and then iwd owns the IP configuration of > its wlan0 interface and manages routes for wlan0 in the given routing > table with that id. > > Having the routes in a separate routing table then gives NM an easy > way to utilize the, either with routing policy rules or with VRF. > While the VRF and the l3mdev + cgroups seems to be super powerful if > you want to say have one app go via LTE and the other via WiFi. Or > even confine a Miracast app into the P2P network. Just some ideas to > think about.
Slightly off-topic, but if the technology daemons are moving towards doing DHCP themselves, then they'll need additional: Management knobs: 1) use a static IP address & prefix if requested by the user, rather than DHCP 2) Allow the user to configure specific DHCP options to send to the DHCP server (client ID, FQDN hostname, etc) API 1) provide the list of DHCP options back to a connection manager for things like DNS, search domains, proxy configuration, and custom DHCP options sent by the server Do you also think that the technology daemons should handle IPv6 addressing as well, including DHCPv6 if SLAAC indicates the M/O bits? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
