add two functions nm_ip4_config_get_direct_route_for_host()
and nm_ip6_config_get_direct_route_for_host() to check if we have
a direct (non-gw) route to a certain host.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=738590
This utility function is for killing other processes.
Contrary to nm_utils_kill_child_*() which is for killing
and reaping child processes.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
Instead of having basically the same code in a bunch of different
place to find helper programs, just have one place do it. Yes, this
does mean that the same sequence of paths is searched for all helpers
(so for example, dnsmasq will no longer be found first in /usr/local)
but I think consistency is the better option here.
https://bugzilla.gnome.org/show_bug.cgi?id=734131
Make all mac-address properties (including NMSettingBluetooth:bdaddr,
NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be
strings, using _nm_setting_class_transform_property() to handle
translating to/from binary form when dealing with D-Bus.
Update everything accordingly for the change, and also add a test for
transformed setting properties to test-general.
NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the
same code to generate a default interface name. Move it into
nm_utils_complete_generic().
For NMDeviceWifi and NMDeviceWimax, the printf format string for
nm_utils_complete_generic() was created based on ssid/nsp. Since
these input strings are untrusted, this is a serious bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add nm_utils_hwaddr_matches(), for comparing hardware addresses for
equality, allowing either binary or ASCII hardware addresses to be
passed, and handling the special rules for InfiniBand hardware
addresses automatically. Update code to use it.
Lots of old code used struct ether_addr to store hardware addresses,
and ether_aton() to parse them, but more recent code generally uses
guint8 arrays, and the nm_utils_hwaddr_* methods, to be able to share
code between ETH_ALEN and INFINIBAND_ALEN cases. So update the old
code to match the new. (In many places, this ends up getting rid of
casts between struct ether_addr and guint8* anyway.)
(Also, in some places, variables were switched from struct ether_addr
to guint8[] a while back, but some code still used "&" when referring
to them even though that's unnecessary now. Clean that up.)
g_error() does not return, but clang seems not to understand that
and gives the following warning.
make[4]: Entering directory `./NetworkManager/src'
CC NetworkManagerUtils.lo
NetworkManagerUtils.c:1584:1: error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Ethernet-like interfaces aren't the only type of interfaces that can
run IPv6 but the rdisc code only returns an address if the interface's
hardware address is 6 bytes.
Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own
specifications for constructing IPv6 addresses and we should honor
those.
So instead of expecting a MAC address, let each device subclass
generate an Interface Identifier and use that for rdisc instead.
NMConfig accepted no-auto-default and ignore-carrier lists with
untagged specs (ie, interface names not prefixed with
"interface-name:" and hardware addresses not prefixed with "mac:").
Move that handling into nm_match_spec_interface_name() and
nm_match_spec_hwaddr() instead.
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
This functionality is now provided by nm_connection_normalize().
Contrary to nm_utils_normalize_connection(), nm_connection_normalize()
is in libnm-util and available to clients as well.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If we had a connection with IPv6.method = ignore, we simply ignored IPv6. So
we should assume this connection even if there is an SLAAC address on the
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1083196
We can only allow possible match if all the differences are exceptions.
Before, we accepted the connection if an exception was found, but it is wrong
because there may be another difference (that is fatal).
No need to allocate a dynamic buffer in most of the cases.
And extended test cases to test with/without white space
and leading zeros.
Signed-off-by: Thomas Haller <thaller@redhat.com>
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f"
BOOTPROTO=none
IPADDR="10.0.0.2"
PREFIX="24"
GATEWAY="10.0.0.1"
HWADDR="52:54:00:12:34:56"
TYPE=Ethernet
NAME="ens3"
This ifcfg file results in connection.interface-name=ens3.
However, device-generated connection didn't set interface-name property.
Fix that by setting interface-name property when generating a connection. Also
allow matching connections if interface-name is not set in a connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1077743
When an existing connection profile has IPv6 method 'ignore', NM doesn't simply
care about IPv6. Thus we should allow matching such a profile to devices with
just a link-local address.
The example can be a simple configuration like this:
/etc/sysconfig/network-scripts/ifcfg-ens3:
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="aa17d688-a38d-481d-888d-6d69cca781b8"
BOOTPROTO=dhcp
HWADDR="52:54:00:32:77:59"
TYPE=Ethernet
NAME="ens3"
https://bugzilla.redhat.com/show_bug.cgi?id=1073824
If IPv4 configuration did not succeed or the device has no IPv4 addresses
when NM restarts, it will detect the existing device configuration as
'disabled'. This can happen when a bridge has no slaves and thus cannot
perform IPv4 addressing because it has no carrier (since bridge carrier
status depends on slave carriers). When NM starts or restarts, it
sees the bridge has no IPv4 address and assumes the IPv4 method is
'disabled'. This creates a new connection, which blocks any slave
connections from activating if they specify their master via UUID
(since the bridge's active connection is generated).
Fix this by allowing matches from 'disabled' to 'auto' if the device
has no carrier, and there are no other differences between the
original and the candidate connections.
Make it more clear, what the current monotonic_timestamp is and
what's it's offset to CLOCK_BOOTTIME.
Signed-off-by: Thomas Haller <thaller@redhat.com>
