Instead of creating most routes with metric 0 and then fixing them
just before applying them, create the routes with the correct metric
in the first place (so that NMIP4Config and NMIP6Config don't have to
try to guess whether "metric 0" means "unset" or "actually metric 0").
It's only used to keep the DHCPManager up-to-date with hostname changes,
and that can be accomplished in much less code by just having NMManager
set a hostname on the DHCPManager itself.
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
These settings are mostly unused. Do not pass them when starting the client,
instead only pass the argument that is actually used (dhcp_client_id).
This simplifies the code later, when we delay starting of DHCP6 clients --
because there is no need to clone the setting.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At a later point, we will have to make a copy of @dhcp_anycast_addr to start
the client asynchronously. Although the length of the guint8 array *should*
always be 6 byte (being a MAC address), it's nicer to just pass on the
GByteArray instance instead, which knows how many byte are actually
set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When we kill a client, we usually get a DHCP event afterwards that cannot
be associated with the client anymore (because we forgot about its PID).
Do not log a warning in that case, but only a debug message.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We kill the dhcp process synchronously, so waiting for up to 3 seconds
is really painful. Instead, give the client only 0.5 to terminate before
sending SIGKILL.
The proper solution would be to kill it asynchronously and dhcp manager
making sure that it does not start a new instance before the old process
was killed.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
In information-only mode (where RA is providing addresses), DHCPv6
may not give an address. NetworkManager was adding a blank one
anyway, which is invalid. Don't do that.
Some ISP's provide leases from central servers that are on different
subnets that the address offered. If the host does not configure the
interface as the default route, the dhcp server may not be reachable
via unicast, and a host specific route is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=721767https://bugzilla.redhat.com/show_bug.cgi?id=983325
Signed-off-by: Thomas Haller <thaller@redhat.com>
Follow RFC 3442 to set network prefix based on address class.
However, still uses host routing if the target address is not a
network address (ie host part not zero).
https://bugzilla.gnome.org/show_bug.cgi?id=721771
Signed-off-by: Thomas Haller <thaller@redhat.com>
dhcpcd v5.99 and later automatically enabled IPv6 behavior unless
specifically disabled. This is undesirable for two reason:
1) dhcpcd sends IPv4 Router Solicitations, which NetworkManager
handles itself, so there's no need to do it twice. NetworkManager
knows better than dhcpcd whether IPv6 is supposed to be used for
that interface or not.
2) Some devices don't react well to IPv6 when they aren't expecting
it. For example, older Qualcomm Gobi-based devices will listen
for Router Solicitations and attempt to set up IPv6, but if other
settings are not done correctly, or the firmware doesn't actually
support it, the firmware will then crash. So simply upgrading your
dhcpcd from 5.x to 6.x magically stops WWAN working for these
devices.
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
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
53e55aab36 mistakenly moved the address
prefix without moving the memset() to initialize the address. Make
sure the address is initialized before trying to do anything with it.
Calling g_file_test with a NULL path causes valgrind to complain.
NetworkManager[24512]: <debug> [1377884547.687536] [dhcp-manager/nm-dhcp-dhclient.c:482] create_dhclient_config(): (em1): no existing dhclient configuration to merge
==24512== Syscall param access(pathname) points to unaddressable byte(s)
==24512== at 0x3F976E7627: access (in /usr/lib64/libc-2.17.so)
==24512== by 0x4EDA556: g_file_test (in /usr/lib64/libglib-2.0.so.0.3600.3)
==24512== by 0x49BB69: create_dhclient_config (nm-dhcp-dhclient.c:364)
==24512== by 0x49CC39: ip4_start (nm-dhcp-dhclient.c:671)
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
Add hidden command line option --run-from-build-dir; with that, helpers
like nm-avahi-autoipd.action and nm-dhcp-helper will be called from the
build tree instead of libexecdir, which allows testing without having to
install first.
Helper paths are now stored in global variables instead of macros, and
get modified with that new option.
https://bugzilla.gnome.org/show_bug.cgi?id=698752
