Add support for Fedora's dhclient's built-in RFC3442 classless static
routes format.
Since the Fedora format uses the same name as the dhcpcd format, we
need to refactor a bunch of the code to ensure we can distinguish
between the types. Do this at runtime now by consolidating the
classless static routes parsing code into the DHCP Client base class
and rework the unit tests so that we can test all variations of the
classless static route parsing code at the same time.
This also fixes a bug with the dhcpcd classless static route
gateway handling that would return the wrong gateway address.
Many thanks to Jiri Popelka from Red Hat for the initial patch
and explanations.
Everyone uses pm-utils still for sleep/wake support, and that's
traditionally how NM was put to sleep and woken up. But pm-utils
uses dbus-send without --print-reply so dbus-send quits immediately
after sending the message. That doesn't give NM enough time to
get the senders UID and thus validate the request, so the request
gets denied, and sometimes NM stays asleep after the machine is
woken up.
Instead, don't get the sender's UID and try to authorize it, but
just let the request go through. Rely on D-Bus permissions to
make sure that only root can call sleep/wake methods.
Groups may come later, but they are also quite a bit more complicated
because getting the groups a user is in may require network access
if that user is backed by LDAP. And it gets worse because you have
no idea that the glibc calls like getgrouplist(3) are backed by
the network and may take an arbitrary amount of time to complete.
Punt that.
If the supplicant dies a number of times within a short period of
time, make it go sit in the corner for a bit instead of continuously
trying to start it and have it die again.
Instead of just exposing a "running" value, instead make a meta
"available" value that's a combination of whether the supplicant
is actually running plus whether we want to talk to it right now
or not.
interface_add() could get called from two places: by the wifi/eth
device class when activating (which if the supplicant isn't yet
running will D-Bus activate it) and from the NameOwnerChanged
handler for the wpa_supplicant dbus service smgr_running_cb().
So if the supplicant wasn't running, nm_supplicant_interface_new()
would call interface_add() to bring the supplicant to life via
activation, then go on and create priv->iface_proxy. When the
supplicant appeared and D-Bus sent the NameOwnerChanged,
smgr_running_cb() would also call interface_add(), creating a
second priv->iface_proxy. The first one got lost and lived after
its parent NMSupplicantInterface was killed, and could still
respond to signals over the bus.
Prevent that by adding another state, STARTING, that indicates
that we've already started talking to the supplicant. Also be
extra paranoid about disconnecting signal handlers on the proxy.
config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii. So wherever we use those, we need
to make sure config.h is included.
Try to preserve custom hostnames (ie, anything not a localhost* variant,
the current hostname, or the previous hostname) when rewriting the
127.0.0.1/::1 localhost mapping lines.
G_SLICE debugging uncovered a use-after-free when freeing the
batched user connection settings callback list. We don't
actually care about the DBusPendingCalls anyway, so just make
the list a counter and simplify the code in the process.
NM-added mappings for active IP addresses were not getting properly
removed when the address disappeared of NM quit, because the bits
of code that determine whether or not /etc/hosts should change were
not taking the disappearance of the IP address into account, and
were leaving the file unchanged.
To fix that, if there is no default IP address, but there are NM-added
IP address entries in /etc/hosts, make sure we update /etc/hosts and
remove them.
We only really need one state for the supplicant interface which
simplifies handling in the Wifi and Wired device classes quite a
bit. It also simplifies the supplicant interface class too.
One behavioral change in the device classes is not running the
supplicant interface state changes from an idle; we'll have to
see if that causes problems. ISTR long ago that processing the
state change signals directly caused some issues, but we've
significantly reworked somethings since then so we may be able
to get away with this now.
Move GObject stuff to the bottom to reduce prototype abuse and
remove unneeded prefixes from stuff that's private to the class
itself. We also don't need the 'supplicant-manager' or 'device'
properties since they weren't used anywhere.
Move GObject stuff to the bottom to reduce prototype abuse and
remove unneeded prefixes from stuff that's private to the class
itself. We also don't need the 'supplicant-manager' or 'device'
properties since they weren't used anywhere.