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>
- use a more efficient implementation for prefix_to_netmask
- fix netmask_to_prefix to behave consistently in case of
invalid netmask
- remove unused duplicated functions from NetworkManagerUtils.c
- add test functions
Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771
When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.
In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.
Add a more-testable framework for doing the connection matching to
handle this.
If the interface who's IP configuration is being captured has the default
route, then read DNS servers from resolv.conf into the NMIP[4|6]Config.
This allows NetworkManager to repopulate resolv.conf if anything changes.
For example, if the system does not define a persistent hostname, then
when a device which has generated a connection activates, a hostname
lookup will be performed. The results of that lookup may change resolv.conf,
and thus NetworkManager must rewrite resolv.conf. Without capturing
DNS information at startup when generating connections, an empty
resolv.conf would be written.
Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.
Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
ifcfg-rh didn't let you unmanage an InfiniBand device by hardware
address because it was recording the hardware address with uppercase
letters, while nm_match_spec_hwaddr() required lowercase. Fix this by
making nm_match_spec_hwaddr() match case-insensitively (and remove the
manual lowercasing that several other places were doing to work around
this.)
keyfile didn't let you unmanage an InfiniBand device by hardware
address because it only accepted ARPHRD_ETHER hardware addresses. Fix
that by using nm_utils_hwaddr_valid() instead.
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.)
This function gets used for both /proc/sys (ie, sysctl) and for
sysfs attributes. There are two issues with it:
1) most sysctl values don't care about a trailing LF, but some
sysfs attributes (infiniband) do; so we always have to add the
trailing LF. Just move that into the function to ensure that
callers don't forget to add it.
2) neither sysfs or sysctl support partial writes, while the
existing function did partial writes. Practically, both the
write handlers for sysfs and sysctl should always handle all
the data, but if they don't, partial writes are wrong. So
instead, try three times to write all the data.
