When the DHCPv6 lease received from the server contains multiple
addresses, dhclient generates a new BOUND event for each of
them. Instead of overwriting the previous IP6 configuration for each
BOUND event, we should try to detect if the new configuration belongs
to the same lease and merge its addresses with the existing one in
such case.
This allows NetworkManager to configure multiple addresses on an
interface via DHCPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=681764https://bugzilla.redhat.com/show_bug.cgi?id=1244293
(cherry picked from commit 1d6e8e8da7)
Some versions of Android's DHCP server send option 43 (Vendor specific
information) with value "ANDROID_METERED" in Wi-Fi hotspot mode.
Mark the NMIP4Config as metered when such option is received.
(cherry picked from commit 1e39b2320d)
This adds support for DHCP option 43 (Vendor Specific Information) to
the internal DHCP client. The option carries an opaque object of n
octets, interpreted by vendor-specific code on the clients and
servers.
(cherry picked from commit 3c2f4a17f9)
We kill the process based on the PID from the pidfile. This can be
our own child process so we must use nm_utils_kill_child_sync()
instead of nm_utils_kill_process_sync().
(cherry picked from commit c61c71a168)
kill(pid,sig) can return success for zombie processes. This
caused nm_utils_kill_process_sync() to hang indefinitely.
Fix it by also checking the process state.
(cherry picked from commit 69c98a336e)
Add nm_utils_setpgid() as a g_spawn*() child setup function for
calling setpgid(), and use it where appropriate rather than
reimplementing it every time.
(cherry picked from commit fb792af7cb)
Replace the pthread_sigwait()-based signal handling with
g_unix_signal_add()-based handling, and get rid of all the
now-unnecessary calls to nm_unblock_posix_signals() when spawning
subprocesses.
As a bonus, this also fixes the "^C in gdb kills NM too" bug.
(cherry picked from commit c5b3e93792)
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
(cherry picked from commit b8b1a01d96)
Fixes build on Ubuntu 12.04.
systemd/src/libsystemd-network/dhcp-network.c: In function '_bind_raw_socket':
systemd/src/libsystemd-network/dhcp-network.c:75:17: error: 'BPF_XOR' undeclared (first use in this function)
systemd/src/libsystemd-network/dhcp-network.c:75:17: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [libsystemd_nm_la-dhcp-network.lo] Error 1
(cherry picked from commit 3811a68389)
The actual logging implementation is not supposed to be called
directly, because there are macros that capture the call site
information __FILE__, __LINE__, and G_STRFUNC.
Rename the function to make clear that this is the actual
implementation.
(cherry picked from commit 211d241ab0)
Conflicts:
src/dhcp-manager/systemd-dhcp/nm-sd-adapt.h
A gnu extension to printf adds the format specifier "%m"
to print @errno. To preserve the error number until the
point where the logging statement is constructed, pass
it as an additional argument to _nm_log().
This is not (yet) used from NM internal code. But systemd is adding
similar functionality to its logging functions. Add the same also to
nm-logging, to support systemd's usage of "%m".
(cherry picked from commit 5162426d41)
Before, when having a test with nmtst_init_assert_logging(),
the caller was expected to setup logging separately according
to the log level that the test asserts against.
Since 5e74891b58, the logging
level can be reset via NMTST_DEBUG also for tests that
assert logging. In this case, it would be useful, if the test
would not overwrite the logging level that is set externally
via NMTST_DEBUG.
Instead, let the test pass the logging configuration to
nmtst_init_assert_logging(), and nmtst will setup logging
-- either according to NMTST_DEBUG or as passed in.
This way, setting the log level works also for no-expect-message
tests:
NMTST_DEBUG="debug,no-expect-message,log-level=TRACE" $TEST
(cherry picked from commit b6d3b98655)
dhclient only supports fqdn.fqdn for server DDNS updates with
DHCPv6. And even though the underlying DHCP options that fqdn.fqdn
controls allow non-qualified hostnames on the wire, dhclient does
not. So we must require a fully-qualified name for DHCPv6.
Second, while no-client-updates seems like it should be "off", doing
that apparently makes dhclient set the "O" flag to 1 which appears to
be a bug, and results in the server not doing the DDNS update. So
we must stop setting that option too.
Found by: Alexander Groß
(cherry picked from commit 677cee0f23)
==7745== 37 (+37) bytes in 1 (+1) blocks are definitely lost in loss record 2,679 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45B097: set_property (nm-dhcp-client.c:851)
==7745== by 0x7CBF688: object_set_property (gobject.c:1415)
==7745== by 0x7CBF688: g_object_new_internal (gobject.c:1808)
==7745== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==7745== by 0x7CC14D0: g_object_new (gobject.c:1617)
==7745== by 0x45FF9F: client_start (nm-dhcp-manager.c:253)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
(cherry picked from commit c26ef29a47)
==7745== 11 (+11) bytes in 1 (+1) blocks are definitely lost in loss record 408 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45C188: nm_dhcp_client_start_ip4 (nm-dhcp-client.c:417)
==7745== by 0x460147: client_start (nm-dhcp-manager.c:268)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
==7745== by 0x456467: nm_device_activate_stage3_ip_config_start (nm-device.c:4801)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
(cherry picked from commit 76430f9cca)
First, configure.ac's grep was wrong and wasn't setting DHCPCD_SUPPORTS_IPV6,
which caused dhcpcd to acquire a DHCPv6 address when NM didn't think that
was going to happen, and thus DHCP options couldn't be parsed.
Second, even if that does happen, don't just assert and quit, but set the
DHCP state to failed.
https://bugzilla.gnome.org/show_bug.cgi?id=743700
(cherry picked from commit 511a7395bf)
Previously, we would only pass one argument @loc to _nm_log()
which was set to G_STRLOC.
That has the disadvantage, that for every logging line the binary
contains an individual string __FILE__:__LINE__.
By splitting up @loc into @file and @line, we reduce the number
of strings in the NetworkManager binary by about 50k.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
(cherry picked from commit e62aa4165f)
When dhclient trieds to request a previous lease and the server NAKs that
lease, dhclient emits the EXPIRE state. dhcpcd has also been known to emit
the 'nak' state for the same reason.
(systemd's DHCP client code does not push a NAK up to NetworkManager, but
jumps to the REBOOT state instead, so it is unaffected by this issue.)
NetworkManager saw the expire during IP configuration and treated that as
full activation failure. The connection would be restarted, the same lease
requested, and the same NAK delivered, over and over. Before a lease is
acquired, there is (by definition) no lease to expire, so these events
should be ignored.
We do, however, still want to handle abnormal failures, which is why
this patch splits the EXPIRE case from the FAIL case and handles them
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=739482
The previous nm-dhcp-systemd code for logging the lease expiry time,
and exporting that value to D-Bus was clamping the value to
G_MAXUINT32-1, but that's unnecessary on x86_64, and incorrect on x86
(since time_t is signed).
Correctly adding a value to the current time and not overflowing seems
to be more-or-less impossible without having separate cases for 4- and
8-byte time_t. Since this was basically just for logging purposes
anyway, just log the number of seconds rather than the timestamp, and
then we don't have to worry about sizeof(time_t).
An sd_dhcp_lease will always have an associated address, netmask, and
lifetime, so we don't have to check for errors when fetching them.
(The systemd code will fill in a default netmask if the server didn't
provide one; nm-dhcp-systemd's code to do that itself was redundant
and unused.)
Also, log the expiration time and NTP servers, for consistency with
everything else.
If asked to read a file that doesn't exist, sd_dhcp_lease_load()
returns 0 (success) without setting the out lease argument. So we need
to check both the return status and the lease before proceeding.
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Things explode on i386 when marshalling a 32-bit value when a 64-bit one is
expected:
Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:242
242 movdqu %xmm0, (%edx)
Missing separate debuginfos, use: debuginfo-install nss-mdns-0.10-15.fc21.i686
(gdb) bt
#0 0xffffffff in __memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:242
#1 0xffffffff in g_hash_table_remove_all_nodes (__len=<optimized out>, __ch=0, __dest=<optimized out>)
at /usr/include/bits/string3.h:84
#2 0xffffffff in g_hash_table_remove_all_nodes (hash_table=hash_table@entry=0x82ee250<error reading variable: Cannot access memory at address 0x8dbaacd6>, notify=notify@entry=1) at ghash.c:481
#3 0xffffffff in g_hash_table_unref (hash_table=0x82ee250<error reading variable: Cannot access memory at address 0x8dbaacd6>) at ghash.c:1042
#4 0xffffffff in _g_type_boxed_free (type=136861824, value=0x82ee250) at gtype.c:4262
#5 0xffffffff in boxed_proxy_value_free (value=0xbfffe8ec) at gboxed.c:209
#6 0xffffffff in g_value_unset (value=value@entry=0xbfffe8ec) at gvalue.c:272
#7 0xffffffff in g_signal_emit_valist (instance=instance@entry=0x82492b8, signal_id=signal_id@entry=125, detail=detail@entry=0, var_args=<optimized out>, var_args@entry=0xbfffea4c "\030\342.\bL#") at gsignal.c:3338
#8 0xffffffff in g_signal_emit (instance=0x82492b8, signal_id=125, detail=0) at gsignal.c:3365
#9 0x0809c05d in handle_event (proxy=0xb5d012e8 [DBusGProxy], options=0x82eb640 = {...}, user_data=0x82492b8)
at dhcp-manager/nm-dhcp-listener.c:146
#10 0xffffffff in g_cclosure_marshal_VOID__BOXED (closure=0x82bf270, return_value=0x0, n_param_values=2, param_values=0x82c60c0, invocation_hint=0xbfffec68, marshal_data=0x0) at gmarshal.c:1120
#11 0xffffffff in marshal_dbus_message_to_g_marshaller () at /lib/libdbus-glib-1.so.2
#15 0xffffffff in <emit signal received:org-freedesktop-nm_dhcp_client-Event on instance 0xb5d012e8 [DBusGProxy]> (instance=0xb5d012e8, signal_id=19, detail=915) at gsignal.c:3365
#12 0xffffffff in g_closure_invoke (closure=0x82bf270, return_value=return_value@entry=0x0, n_param_values=n_param_values@entry=3, param_values=param_values@entry=0xbfffecc0, invocation_hint=invocation_hint@entry=0xbfffec68) at gclosure.c:768
#13 0xffffffff in signal_emit_unlocked_R (node=node@entry=0x8263660, detail=detail@entry=915, instance=0xb5d012e8, emission_return=emission_return@entry=0x0, instance_and_params=0xbfffecc0) at gsignal.c:3553
#14 0xffffffff in g_signal_emit_valist (instance=instance@entry=0xb5d012e8, signal_id=signal_id@entry=19, detail=detail@entry=915, var_args=0xbfffee34 "\340\370.\b\004",
var_args@entry=0xbfffee2c "\340\370.\b\300\303/\b\340\370.\b\004") at gsignal.c:3309
#16 0xffffffff in dbus_g_proxy_manager_filter () at /lib/libdbus-glib-1.so.2
#17 0xffffffff in dbus_connection_dispatch () at /lib/libdbus-1.so.3
#18 0xffffffff in message_queue_dispatch () at /lib/libdbus-glib-1.so.2
#19 0xffffffff in g_main_context_dispatch (context=0x8246720) at gmain.c:3111
#20 0xffffffff in g_main_context_dispatch (context=context@entry=0x8246720) at gmain.c:3710
#21 0xffffffff in g_main_context_iterate (context=0x8246720, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#22 0xffffffff in g_main_loop_run (loop=0x8246798) at gmain.c:3975
#23 0x08070c09 in main (argc=1, argv=0xbffff2b4) at main.c:479
(gdb)
PIDs use native word width, a gint seems more suitable than gint32 or gint64.
https://bugzilla.gnome.org/show_bug.cgi?id=739861
When quitting, the Manager asks each device to spawn the interface helper,
which persists and manages dynamic address on the interface after NetworkManager
is gone. If the dynamic address cannot be maintaned, the helper quits and
the interface's address may be removed when their lifetime runs out.
To keep the helper as simple as possible, NetworkManager passes most of the
configuration on the command-line, including some properties of the device's
current state, which are necessary for the helper to maintain DHCP leases
or IPv6 SLAAC addresses.
Really only used by systemd because it doesn't have as good lease
handling, but it's also necessary if we switch DHCP clients mid-stream
(which we'll be doing later) since the new DHCP client won't
have a lease file for the current IP address, and thus has nowhere
to pull the current IP address from to request the same address
from the DHCP server.
