GNOME.org
 

Re: How does IWD handle setting MAC address?

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]