Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
NMSettingIP[46]Config let you associate a gateway with each address,
and the writable settings backends record that information. But it
never actually gets used: NMIP4Config and NMIP6Config only ever use
the first gateway, and completely ignore any others. (And in the
common usage of the term, an interface can only have one gateway
anyway.)
So, stop pretending that multiple gateways are meaningful; don't
serialize or deserialize gateways other than the first in the
'addresses' properties, and don't read or write multiple gateway
values either.
Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.
(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
Missing initializers together with automatic cleanup seem to annoy GCC's
-Werror=maybe-uninitialized, breaking the --enable-more-warnings=error
builds.
We must also remove -Waggregate-return from m4/compiler-warnings.m4 because systemd
uses aggregate return (correctly) in a couple cases, and we cannot keep single-level
makefiles and override aggregate-return only for the systemd sub-library.
This client currently only supports DHCPv4 because the base systemd code
does not yet fully support DHCPv6.
The systemd code was modified to add "#if 0 /* NM_IGNORED */"
around lines that cause problems for compilation or code that is
not actually used in the library.
An adaptation layer (nm-sd-adapt) was added for glue between
systemd functions and NetworkManager, but changes to the actual
systemd code have been kept to a minimum.
The sd_event/sd_event_source functions of systemd have been
re-implemented on top of the GLib main loop.
client->secs wasn't getting set in the REBOOT state, causing
an assertion. REBOOT should work the same way as INIT, per
RFC 2131:
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
REBOOT is necessary because many DHCP servers (especially on
home routers) do not hand back the same IP address when in
response to a DISCOVER packet, even if the same client ID is used.
The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired. Clean it up properly so we're
not still listening and responding to events on it.
Non-ethernet interface types use different client identifier formats,
plus when doing DHCPv4 and DHCPv6 on the same interface, the client
identifier should be related per RFC 4361. Thus let the caller
override the existing MAC-based client identifier if necessary.
The plugin can indicate that this connection can persist across link
changes and other connectivity dropouts by passing this option
back in the SetConfig() calls.
If the VPN re-enters the STARTING state to indicate that it has
disconnected from the VPN server and is trying to reconnect, change
the VPN connection's state to indicate that connectivity may be
limited. Wait for the VPN to provide updated IP configuration
information from the reconnect to change back to the ACTIVATED
state.
This property will indicate that the user wishes the VPN connection
to stay active until explicitly disconnected, even across link changes
or other interruptions.
They are defined as gint32 but are assigned a guint32 value and
then immediately passed back to the caller of _address_get_lifetime()
as guint32. They can never be negative, and may receive values
greater than G_MAXINT32, so they should be unsigned.
When the DHCP server address is not on the same subnet, we used
to add a /32 route to the server IP address via the gateway.
Do not add this route, if we already got a direct route from DHCP.
https://bugzilla.gnome.org/show_bug.cgi?id=738590
Signed-off-by: Thomas Haller <thaller@redhat.com>
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
/general/nm_utils_kill_child: **
GLib:ERROR:test-general-with-expect.c:105:test_nm_utils_kill_child_sync_do: Did not see expected message NetworkManager-DEBUG: *kill child process 'test-s-1-1' (*): waiting up to 500 milliseconds for process to terminate normally after sending SIGTERM (15)...
Aborted
The first test case assumes the child does not go away immediately after being
delivered a TERM signal. Add some delay to its teardown code path, so that NM
will set up the timeout the test expects.
This way the compiler issues a warning when accidently
switching the level and domain arguments when logging.
Make LOGD_ALL and LOGD_DEFAULT members of the enum instead
defining them. Previously the LOGD_ALL define included all
the defined domains, hence this is no functional change.
Also define the logging domain aliases as enum members (instead
of preprocessor defines).
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMIP4Configs and NMIP6Configs are never supposed to contain a default
route, and thus nm_platform_ip6_route_sync() should never have to deal
with one. Unfortunately, if it *does* get passed a default route, it
will add it even if it was already there. This will result in an
RTM_NEWROUTE notification, which will cause NMPlatform to emit
ip6-route-changed, which will result in NMDevice doing some work and
then calling nm_ip6_config_commit(), which will result in NMIP6Config
passing the same list of routes to nm_platform_ip6_route_sync() again,
including the default route, which will cause NMPlatform to add the
route again...
(Something eventually causes this cycle to get broken, but it starts
up again the next time NM receives an RA.)
Fix this by having the route_sync() functions never add/modify the
default route (They were already not deleting it.)
If the router sends an RA with an RDNSS or DNSSL lifetime of "0", that
means to immediately stop using the corresponding server/domain name.
NMLNDPRDisc knew this, but messed up its handling of it, and so if
this happened, it might end up sending out an RS to get new data every
0 seconds...
(Noticed while investigating bgo 735325, though it turned out to be
irrelevant there.)
