NMSettings would try to create an NMDefaultWiredConnection for any
NMDeviceWired subclass, and there was some code to deal with
InfiniBand in the code. But nm_default_wired_connection_new() required
the hwaddr length to be ETH_ALEN, so InfiniBand would never have
worked (and probably shouldn't have, since people generally don't want
the auto-default behavior on servers anyway). And we certainly never
intended for this code to apply to bridges and bonds. So fix it to
only apply to ethernet devices, and remove the vestigial
InfiniBand-related code.
Most of the various nm_foo_manager_get/new() calls never return NULL,
so just g_assert() that fact rather than logging a separate error
message for each one.
Rather than passing specific bits of data to NMDHCPManager and
NMDnsManager, just let them call nm_config_get() and then get the data
themselves.
Also, remove the GError argument from nm_dhcp_manager_new(), since the
function never returned NULL. This in turn means there is no longer
any need for a distinction between nm_dhcp_manager_new() and
nm_dhcp_manager_get(), so remove the former.
Add NMConfigDevice, which is mostly just a wrapper around
nm_device_get_hw_address() and nm_device_spec_match_list(), and
implement it in NMDevice. This will be used for config options that
match devices. (We can't use NMDevice directly for dependency
reasons.)
There is no reason to configure the connectivity-check options from
the command line rather than from the config file. Keep the options,
for backward-compatibility, but remove them from the man page and hide
them from --help.
The list of log domains in the --log-domains documentation had gotten
out of date. Fix this by adding nm_logging_all_domain_to_string()
(and, for completeness, nm_logging_all_levels_to_string()), and use
those to fill in the help string.
Rather than having main.c parse them and then hand them all to
nm_config_new(), just let nm-config provide its own GOptionEntry
array to merge in with main's.
It's a singleton that always exists. Callers shouldn't have to
refcount it.
Also, move its cleanup code from dispose() to finalize(), and remove
some unnecessary checks in it.
gcc 4.8.0 has a new warning that triggers on
static void
compute_hash (NMDnsManager *self, guint8 buffer[HASH_LEN])
{
...
memset (buffer, 0, sizeof (buffer));
...
}
because "sizeof (buffer)" is *not* HASH_LEN, it's sizeof(guint8*). The
memset() was not necessary anyway since the g_checksum_get_digest()
after it will always end up filling in buffer, so just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=697041
When the default leasefile location got moved from distro-specific
dhclient locations to a single NM-specific location, that apparently
broke scripts and external tools that depended on the old location,
like dract netbooting.
During a netboot, DHCP is started from the initramfs and gets a
lease, and the leasefile lives in the initramfs. When the real
system is started, and the rootfs switches from the initramfs to
the actual rootfs, something needs to copy the leasefiles over to
where NetworkManager can find them. For dracut at least, various
dracut scripts were doing this, and copying to the old location
in /var/lib/dhclient or /var/lib/dhcp. Which means NM can no
longer find them, and proceeds to acquire a new DHCP lease when
taking over the existing connection, rather than renewing the
existing lease. This can lead to loss of network connectivity
and thus the netboot process fails.
If no leasefile for the connection in the new location exists,
look in the old locations and copy that leasefile over to the new
location.
MM won't always be present, and if it's not, your logs will fill up
with warnings about MM not being able to be launched. And when
running with systemd, you'll get a different class of errors like:
<warn> error poking ModemManager: GDBus.Error:org.freedesktop.systemd1.LoadFailed:
Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or
directory. See system logs and 'systemctl status
dbus-org.freedesktop.ModemManager1.service' for details.
and I'm tired of chasing and special-casing all the launch-failed
errors that D-Bus and systemd use.
Plus, we have dynamic log level changing via the D-Bus interface so if
people need to debug this, just chaning the log level will tell you
what's wrong.
The PPP interface may be gone already, especially if the connection
was terminated by the PPP peer. It's pointless to warn in these
cases since getitng the final stats is best-effort anyway.
Not all systems have machine-id in /etc, some still have it in /var/lib/dbus/
especially if they aren't using systemd. Furthermore, if we don't have
any machine-id file (like in the future, if we don't have a messaebus
daemon running) fall back to a random DUID as a last resort.
Like if the dbus daemon restarts; in this case the connection has changed
and the new connection doesn't have the filter installed, and libdbus
aborts when we try to remove a filter that doesn't exist on the connection.
Fix that by re-adding the filter when the connection changes.
Just like we don't fail IPv4 if DHCP fails to get DNS servers,
don't fail IPv6 if we've already got an RA and for some reason
DHCPv6 fails. otherconf/info-only DHCP is not mandatory, and
lack of results thus should not fail the entire IPv6 config,
since DNS servers can also be passed in the RA.
RFC4861:
1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such information
are DNS-related information or information on other
servers within the network.
As with the other connection-matching methods, move the loop and the
device-independent bits into NMDevice. By reusing
nm_device_check_connection_compatible(), this means that most device
types now no longer need any type-specific code for this.
https://bugzilla.gnome.org/show_bug.cgi?id=693684
nm_device_connection_match_config() sounded more generic than it
really was; rename it to nm_device_find_assumable_connection(), which
is what it really does.
There was also a lot of redundancy/cut+paste in the subclass
implementations of connection_match_config(); Improve things by moving
the looping-over-connections code into NMDevice itself, and also doing
the general-device-compatibility and IP-config checking there, leaving
the device subclasses to just verify L2 properties. Which most of them
aren't doing...
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Since NMDevice has a generic get_hw_address() method now, it can do
nm_device_spec_match_list() itself (for everything except ethernet,
which needs to match against s390 subchannels too).
https://bugzilla.gnome.org/show_bug.cgi?id=693684
nm_device_connection_match_config() on an ethernet connection could
succeed for a device that was in the connection's
mac-address-blacklist, but then NM would immediately fail to activate
the connection because nm_device_connection_compatible() would check
the blacklist and return FALSE. Fix the former to match the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=693684
in hw_take_down()
usb 1-3: USB disconnect, device number 6
modem-manager[547]: <info> (tty/ttyACM0): released by modem /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3
<info> (tty/ttyACM0): released by modem /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3
<info> (ttyACM0): device state change: disconnected -> unmanaged (reason 'removed') [30 10 36]
<info> (ttyACM0): cleaning up...
<info> (ttyACM0): taking down device.
nm_system_iface_set_up: assertion `ifindex > 0' failed
0 means "turn off connectivity checking", so we can't use that to
determine whether or not the interval has already been set by
command-line options or not. Instead, store the interval
internally as a signed int and use -1 to mean "not yet set".
Second, validate input values for interval to ensure they can't
be less than 0 or more than G_MAXINT.
