The options hash is never used except for BOUND events, so don't
bother caching it in the DHCP client object. Just pass it along
with the BOUND state change, like the IP configuration object.
Previously the tests required that a NMDHCPClient object was
created, but all that's really being tested is the DHCP option
parsing and that doesn't need a client object now that the
option parsing has been split out.
Also, the options test wasn't in src/dhcp-manager/, so put it there.
Lastly, the test ran for both dhclient and dhcpcd, but the code
executed for both cases was the same, so there's no reason to keep
running the test for both clients.
More robust against ifname changes, plus we save some strcmps().
For the most part, the interface name should be informational
only and unused for actual control logic.
Instead of using a separate signal for it, just drop and release
the client object when it reaches terminate states like TIMEOUT,
FAIL, and DONE. The 5 second removal signal timeout appears to
no longer be necessary, since the running child process is killed
synchronously.
Modify code so that listeners remove state change signal handlers
before stopping the client. Which means we can remove the 'emit_state'
argument from nm_dhcp_client_set_state().
DHCP failure should just clean up the client in all cases. This
also has the benefit of removing the signal handler for the DHCP
client's state-change signal before telling the client to terminate,
which will simplify some DHCP code later.
No reason to have two signals for the same thing. Previously, the
TIMEOUT signal was used for the internal overall DHCP transaction
bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from
the DHCP client itself that something had timed out. But in both
cases the results should be the same, so just collapse the
stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
The existing DHC_* states are pretty specific to dhclient, and aren't
useful for more generalized DHCP. NetworkManager wasn't using many
of the states anyway, and doesn't need to differentiate between
states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states
into the ones we really care about.
'address' was not initialized, so using address.ifindex was not
going to work.
==6777== Conditional jump or move depends on uninitialised value(s)
==6777== at 0x44A6DB: check_cache_items (nm-linux-platform.c:1510)
==6777== by 0x44AA4F: announce_object (nm-linux-platform.c:1586)
==6777== by 0x44A59A: refresh_object (nm-linux-platform.c:1666)
==6777== by 0x44A676: check_cache_items (nm-linux-platform.c:1517)
==6777== by 0x44A812: announce_object (nm-linux-platform.c:1566)
==6777== by 0x44D957: handle_udev_event (nm-linux-platform.c:3964)
==6777== by 0x3BAFC125A7: g_closure_invoke (gclosure.c:777)
==6777== by 0x3BAFC2465C: signal_emit_unlocked_R (gsignal.c:3586)
==6777== by 0x3BAFC2C3E1: g_signal_emit_valist (gsignal.c:3330)
==6777== by 0x3BAFC2C69E: g_signal_emit (gsignal.c:3386)
==6777== by 0x3D93A03BE3: ??? (in /usr/lib64/libgudev-1.0.so.0.1.3)
==6777== by 0x3BAF8521D5: g_main_context_dispatch (gmain.c:3066)
Always requesting this appears to cause some devices to ignore
DHCP requests, like the ZTE 823D, ZTEMF93E, Alcatel W800Z.
dhclient probably knows better than NM when to request the
server's ID, so leave that up to dhclient. We don't do anything
interesting with it anyway.
nm-version.h was getting disted, making srcdir!=builddir work for
tarball builds, but not for git builds.
Also, remove "-I${top_builddir}/include" from all Makefile.ams, since
there's nothing generated in include/ any more.
NetworkManager.h, NetworkManagerVPN.h, and nm-version.h are part of
the libnm-util API, so move them to libnm-util.
include/ still contains headers that are strictly NM-internal (eg,
nm-glib-compat.h).
Even if administrator-configured hostname (/etc/hostname) takes precedence
over other hostname configurations, we don't take "localhost", "localhost6",
"localhost.localdomain", "localhost6.localdomain6" as such. These values might
be set by some tools (like installer). But that's not right and we compensate
for that. It doesn't make much sense that an admimistrator would set these
values manually (intentionally), because leaving /etc/hostname empty will
result in "localhost" hostname anyway (set by systemd).
https://bugzilla.redhat.com/show_bug.cgi?id=1110436
The kernel adds these for various operations; they are short-lived,
added often, and not useful to NetworkManager. Ignore them. This
prevents NetworkManager from continuously updating the IPv6 config
and emitting state changes to clients via D-Bus for useless changes.
Quite possibly these logging lines hit before we setup nm-logging
initially and before NM main() calls nm_logging_syslog_openlog().
This is because NM first needs to read the configuration, before setting
up logging.
Note however, that nm-logging is robust against both.
If nm_logging_setup() was not yet called, it will automatically setup
"DEFAULT","INFO".
If nm_logging_syslog_openlog() was not yet called, it will redirect
logging to g_log() -- which basically ends up at g_warning() again.
Still this is useful in case when hitting those lines *afterwards*.
Especially, later when we support reloading of configuration.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The interface is owned by the parent NMDeviceBt and is not independently
usable. If not ignored, NM tries to assume a connection on the bnep
interface and messes the Bluetooth connection up.
The addition of Bluez5 support mistakenly broke support for Bluez4 property
change events. Bluez4 uses a custom D-Bus interface that we must explicitly
handle.
This caused NM to ignore BT devices immediately after pairing, since the UUIDs
only show up through a custom Bluez4 PropertyChanged even when pairing is
complete. Only then do we finally know priv->capabilities, and only then is
the NMBluezDevice usable.
We only want to treat a veth device as ethernet if (a) NM is running
inside a container, and (b) the veth in question is the "inside" end
of the veth, not the outside. Unfortunately, we don't have good
heuristics for this at the moment, so just ignore veths for now.
https://bugzilla.gnome.org/show_bug.cgi?id=731014
No need to keep references of the singleton and take an additional ref
when accessing nm_firewall_manager_get().
Especially, since the firewall manager instance was nowhere passed in from
externally, it doesn't even sense for some vague testing purporse. Not to
mention, that there are no tests that actually inject a firewall manager stub.
Signed-off-by: Thomas Haller <thaller@redhat.com>
An assertion in nm_dhcp4_config_get_dbus_path() has been actually fixed
by 3d6936b2cc (hopefully for all cases).
But still I think we should check _config here instead of _client.
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>
An activating device may have an IP config that is unrelated to
the current activation (for example if it comes from capturing
the existing config when NM is started), and that config might
not have a gateway, which would have NM ignore that the device
is activating until after DHCP.
https://bugzilla.gnome.org/show_bug.cgi?id=726400
[thaller@redhat.com: move variables inside if-block]
Signed-off-by: Thomas Haller <thaller@redhat.com>
When starting, the initally loaded addresses were not fixed to have
absolute lifetimes.
This also leads to a crash due to failed assertion[1], when having
already expired addresses during NetworkManager start.
[1] backtrace:
#0 0x00007f39db91ec39 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f39db920348 in __GI_abort () at abort.c:89
#2 0x00007f39dc35a0ed in _g_log_abort () at gmessages.c:255
#3 0x00007f39dc377c97 in g_assertion_message (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", message=message@entry=0x7f39e13828b0 "assertion failed: (a_preferred <= a_valid && a_valid > 0 && a_preferred > 0)") at gtestutils.c:2278
#4 0x00007f39dc377cfa in g_assertion_message_expr (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", expr=expr@entry=0x7f39e007f4e8 "a_preferred <= a_valid && a_valid > 0 && a_preferred > 0") at gtestutils.c:2293
#5 0x00007f39e0004608 in _init_ip_address_lifetime (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1144
#6 0x00007f39e0004ae4 in init_ip6_address (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1216
#7 0x00007f39e000a75e in ip6_address_get_all (platform=<optimized out>, ifindex=3) at platform/nm-linux-platform.c:3342
#8 0x00007f39e0032729 in nm_ip6_config_capture (ifindex=ifindex@entry=3, capture_resolv_conf=capture_resolv_conf@entry=0, use_temporary=use_temporary@entry=NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN) at nm-ip6-config.c:303
#9 0x00007f39dffee8fa in update_ip_config (self=0x7f39e1380300, initial=<optimized out>) at devices/nm-device.c:5841
#10 0x00007f39dffef52a in nm_device_capture_initial_config (dev=<optimized out>) at devices/nm-device.c:5869
#11 0x00007f39e003e74e in get_existing_connection (manager=manager@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300) at nm-manager.c:1576
#12 0x00007f39e003edb2 in add_device (self=self@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300, generate_con=<optimized out>) at nm-manager.c:1826
#13 0x00007f39e003f503 in platform_link_added (reason=<optimized out>, plink=0x7f39e1372340, ifindex=3, self=0x7f39e132b150) at nm-manager.c:2205
#14 platform_link_cb (platform=<optimized out>, ifindex=3, plink=0x7f39e1372340, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2220
#15 0x00007f39da868d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#16 0x00007f39da8686bc in ffi_call (cif=cif@entry=0x7fff7f8a2a40, fn=0x7f39e003f360 <platform_link_cb>, rvalue=0x7fff7f8a29b0, avalue=avalue@entry=0x7fff7f8a2930) at ../src/x86/ffi64.c:522
#17 0x00007f39dc84aad8 in g_cclosure_marshal_generic (closure=0x7f39e1368080, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#18 0x00007f39dc84a298 in g_closure_invoke (closure=0x7f39e1368080, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff7f8a2c40, invocation_hint=invocation_hint@entry=0x7fff7f8a2be0)
at gclosure.c:777
#19 0x00007f39dc85c35d in signal_emit_unlocked_R (node=node@entry=0x7f39e12c16c0, detail=detail@entry=0, instance=instance@entry=0x7f39e12c30a0, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff7f8a2c40) at gsignal.c:3586
#20 0x00007f39dc8640f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff7f8a2e20) at gsignal.c:3330
#21 0x00007f39dc8643af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3386
#22 0x00007f39e000e24c in nm_platform_query_devices () at platform/nm-platform.c:330
#23 0x00007f39e0040f30 in nm_manager_start (self=0x7f39e132b150) at nm-manager.c:4207
#24 0x00007f39dffe53ab in main (argc=1, argv=0x7fff7f8a3468) at main.c:657
Regression introduced by commit 8310a039d8.
https://bugzilla.gnome.org/show_bug.cgi?id=732472
Signed-off-by: Thomas Haller <thaller@redhat.com>
