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
Error: VARARGS (CWE-237): [#def19]
NetworkManager-0.9.11.0/src/NetworkManagerUtils.c:1748: va_init: Initializing va_list "args".
NetworkManager-0.9.11.0/src/NetworkManagerUtils.c:1758: missing_va_end: va_end was not called for "args".
Fixes: 9a08d8602c
Broken by 25387cd1ff
When an activation request comes in via D-Bus for a slave, the
slave device's priv->master is set in stage1 in master_ready_cb().
Then nm_device_bring_up() is called on the slave, which triggers
link_changed_cb() and device_link_changed(). That then executes
this code:
if (priv->master)
nm_device_enslave_slave (priv->master, self, NULL);
which enslaves the slave, but due to the NULL will not configure
the slave.
This code was only meant to be run for externally triggered
master/slave changes.
NetworkManager[30304]: <info> (virbr0): bridge port virbr0-nic was detached
NetworkManager[30304]: (devices/nm-device.c:962):nm_device_release_one_slave: runtime check failed: (reason == NM_DEVICE_STATE_REASON_NONE)
NetworkManager[30304]: <info> (virbr0-nic): released from master virbr0
If the slave is removed, then the master is already cleaned up so NM
doesn't need to do anything. 5dd48f fixed that but forgot to update
the !configure case, causing the warning but no other problems.
Fixes: 5dd48f7527
If we have ENABLE_GTK_DOCS, but not BUILD_SETTING_DOCS, nm-settings.5
nm-settings-keyfile.5 and nm-settings-ifcfg-rh.5 would not be installed.
(It happened on RHEL 7 build, due to missing BuildRequires: pygobject3-base)
When the device decides it needs re-auth during IP config and returns
to the NEED_AUTH state, make sure we clean up any half-done IP operations
since they will be re-started after auth is completed and the
IP_CONFIG state is re-entered.
https://bugzilla.gnome.org/show_bug.cgi?id=741342
Takes about 3x as long to build with gcc 4.8, but gcc 4.9
is supposed to speed that up considerably.
Name Before After Saved
-------------------------------------
NetworkManager 1734744 1689728 3%
libnm 1263536 808816 36%
nm-iface-helper 931136 906496 3%
libnm-util 441264 437168 1%
libnm-glib 297064 292960 2%
https://bugzilla.gnome.org/show_bug.cgi?id=741140
platform/nm-linux-platform.c: In function 'setup':
platform/nm-linux-platform.c:4364:2: error: 'object' undeclared (first use in this function)
object = nl_cache_get_first (priv->link_cache);
^
Fixes 2b8060b9b3
This reverts commit efd09845c4.
It turns out that the socket space might not be the only buffer that may get
too full. 128K ought to be enough for it and we should resynchronize with the
kernel now if needed.
Kernel can return ENOBUFS in variety of reasons. If that happens, we know we've
lost events and should pick up kernel state.
Simple reproducer that triggers an ENOBUFS condition no matter how big our
netlink socket buffer is:
ip link add bridge0 type bridge
for i in seq $(0 1023); do ip link add dummy$i type dummy; \
ip link set dummy$i master bridge0; done
ip link del bridge0
We assume that in nm_nl_cache_search() and correctly set that in
get_kernel_object(), but we rtnl_link_alloc_cache() can initialize the cache
with devices of other families.
The consequence is that we don't notify when the bridge changes to IFF_UP as we
fail to match and remove the old downed object from the cache:
nm_device_bring_up(): [0xf506c0] (bridge0): bringing up device.
nm_platform_link_set_up(): link: setting up 'bridge0' (12)
link_change_flags(): link: change 12: flags set 'up' (1)
get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
log_link(): signal: link added: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
(bridge0): device not up after timeout!
(bridge0): preparing device
If we didn't start IPv4 and IPv6, but they're allowed to fail, progress
the activation without failing it. Also, progress assumed connections to
check-ip with whatever configuration that is available.
https://bugzilla.redhat.com/show_bug.cgi?id=1141264
VPN connections always return true for nm_connection_need_secrets(), but the
documented behavior of GetSecrets() is just to return any secrets we have
(otherwise nmcli c --show-secrets would not be useful for VPN connections).
Since f32075d2fc, we remove the kernel
added IPv4 device route, and re-add it with appropriate metric.
This could potentially replace existing, conflicting routes. Be more
careful and only take any action when we don't have a conflicting
route and when we add the address for the first time.
The motivation for this was libreswan which might install a VPN route
for a subnet that we also have configured on an interface. But the route
conflict could happen easily for other reasons, for example if you
configure a conflicting route manually.
Don't replace the device route if we have any indication that
a conflict could arise.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
This also avoids warnings with -O2 -Wstrict-overflow (gcc-4.8.3):
make[4]: Entering directory `./NetworkManager/callouts'
CC libtest_dispatcher_envp_la-nm-dispatcher-utils.lo
nm-dispatcher-utils.c: In function 'construct_ip6_items':
nm-dispatcher-utils.c:283:8: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (i != 0)
^
nm-dispatcher-utils.c: In function 'construct_ip4_items':
nm-dispatcher-utils.c:144:8: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (i != 0)
^
nm-dispatcher-utils.c:168:8: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (i != 0)
^
https://bugzilla.gnome.org/show_bug.cgi?id=741168
Motivated by avoiding compiler warning with -O2 -Wstrict-overflow (gcc-4.8.3):
make[4]: Entering directory `./NetworkManager/libnm-core'
CC nm-utils.lo
../libnm-core/nm-utils.c: In function 'nm_utils_hwaddr_valid':
../libnm-core/nm-utils.c:2725:14: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (length == 0 || length > NM_UTILS_HWADDR_LEN_MAX)
^
../libnm-core/nm-utils.c: In function 'nm_utils_hwaddr_canonical':
../libnm-core/nm-utils.c:2755:14: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (length == 0 || length > NM_UTILS_HWADDR_LEN_MAX)
^
https://bugzilla.gnome.org/show_bug.cgi?id=741168
We wait for each deletion to complete, so the connections were getting
removed from the connections array as we edited it (unlike with the
old transfer-container GSList-based code). Fix this by copying the
slaves out into their own list first.
Before we would just call verify() and only return valid connections
without attempting to fix them.
It is better to use normalize(), because that function is especially there to
accept and repair deprecated configurations that would no longer verify().
This changes behavior in the way that the function now accepts connections
that would have been rejected before.
Since commit b88715e05b normalize() also
adds a missing UUID. Hence this also affects the DBUS method 'AddConnection'
in that it now accepts connections without UUID. Previously, clients were
required to set a UUID for the new connection, now NM core can create a random
one if no UUID is set.
https://bugzilla.gnome.org/show_bug.cgi?id=740813
Coverity:
Defect type: CONSTANT_EXPRESSION_RESULT
/src/NetworkManagerUtils.c:726: result_independent_of_operands: "18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */ < (gulong)sleep_duration_msec * 1000UL" is always false regardless of the values of its operands. This occurs as the logical first operand of '?:'.
because either GSM or CDMA is present. It is checked just above.
Coverity:
Defect type: DEADCODE
src/devices/bluetooth/nm-device-bt.c:312: dead_error_line: Execution cannot reach this statement: "fallback_prefix = dcgettext...".
Coverity:
Defect type: UNINIT
src/NetworkManagerUtils.c:1906: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1879: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1852: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
src/NetworkManagerUtils.c:1825: uninit_use_in_call: Using uninitialized value "tp.tv_nsec" when calling "monotonic_timestamp_get".
Coverity: Defect type: SWAPPED_ARGUMENTS
clients/tui/newt/nmt-newt-section.c:328: swapped_arguments: The positions of arguments in the call to "nmt_newt_widget_size_request" do not match the ordering of the parameters: * "&border_height" is passed to "width" * "&border_width" is passed to "height"
