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
#0 0x00007f6c3aed34e9 in g_logv (log_domain=0x7f6c3ea7341c "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff0a33fb60) at gmessages.c:989
#1 0x00007f6c3aed363f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007f6c3e8ead4f in nm_device_get_iface (self=0x0) at devices/nm-device.c:502
#3 0x00007f6c3e904f59 in nm_device_slave_notify_release (self=0x7f6c3fb48e60, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:1618
#4 0x00007f6c3e8ed69f in nm_device_release_one_slave (self=0x7f6c3fb22670, slave=0x7f6c3fb48e60, configure=1, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:968
#5 0x00007f6c3e904bf7 in slave_state_changed (slave=0x7f6c3fb48e60, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=NM_DEVICE_STATE_REASON_REMOVED, self=0x7f6c3fb22670)
at devices/nm-device.c:1368
#6 0x00007f6c39829d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#7 0x00007f6c398296bc in ffi_call (cif=cif@entry=0x7fff0a340070, fn=0x7f6c3e9049d0 <slave_state_changed>, rvalue=0x7fff0a33ffe0, avalue=avalue@entry=0x7fff0a33ff60) at ../src/x86/ffi64.c:522
#8 0x00007f6c3b1bfad8 in g_cclosure_marshal_generic (closure=0x7f6c3fb5c8c0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#9 0x00007f6c3b1bf298 in g_closure_invoke (closure=0x7f6c3fb5c8c0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff0a340270, invocation_hint=invocation_hint@entry=0x7fff0a340210)
at gclosure.c:777
#10 0x00007f6c3b1d135d in signal_emit_unlocked_R (node=node@entry=0x7f6c3faf5d10, detail=detail@entry=0, instance=instance@entry=0x7f6c3fb48e60, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff0a340270) at gsignal.c:3586
#11 0x00007f6c3b1d90f2 in g_signal_emit_valist (instance=instance@entry=0x7f6c3fb48e60, signal_id=signal_id@entry=64, detail=detail@entry=0, var_args=var_args@entry=0x7fff0a3404a8) at gsignal.c:3330
#12 0x00007f6c3b1d98f8 in g_signal_emit_by_name (instance=0x7f6c3fb48e60, detailed_signal=0x7f6c3ea70f83 "state-changed") at gsignal.c:3426
#13 0x00007f6c3e8f894f in _set_state_full (self=0x7f6c3fb48e60, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:7486
#14 0x00007f6c3e8f0706 in nm_device_state_changed (self=0x7f6c3fb48e60, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:7623
#15 0x00007f6c3e8f808b in nm_device_set_unmanaged (self=0x7f6c3fb48e60, flag=NM_UNMANAGED_INTERNAL, unmanaged=1, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6652
#16 0x00007f6c3e9943d0 in remove_device (manager=0x7f6c3fb20150, device=0x7f6c3fb48e60, quitting=0, allow_unmanage=1) at nm-manager.c:752
#17 0x00007f6c3e995c29 in platform_link_cb (platform=0x7f6c3fa7a870, ifindex=73, plink=0x7fff0a341260, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL, user_data=0x7f6c3fb20150) at nm-manager.c:2182
#18 0x00007f6c39829d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#19 0x00007f6c398296bc in ffi_call (cif=cif@entry=0x7fff0a340bc0, fn=0x7f6c3e995b60 <platform_link_cb>, rvalue=0x7fff0a340b30, avalue=avalue@entry=0x7fff0a340ab0) at ../src/x86/ffi64.c:522
#20 0x00007f6c3b1bfad8 in g_cclosure_marshal_generic (closure=0x7f6c3fb14cf0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#21 0x00007f6c3b1bf298 in g_closure_invoke (closure=0x7f6c3fb14cf0, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff0a340dc0, invocation_hint=invocation_hint@entry=0x7fff0a340d60)
at gclosure.c:777
#22 0x00007f6c3b1d135d in signal_emit_unlocked_R (node=node@entry=0x7f6c3fa76f00, detail=detail@entry=0, instance=instance@entry=0x7f6c3fa7a870, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff0a340dc0) at gsignal.c:3586
#23 0x00007f6c3b1d90f2 in g_signal_emit_valist (instance=instance@entry=0x7f6c3fa7a870, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff0a341018) at gsignal.c:3330
#24 0x00007f6c3b1d98f8 in g_signal_emit_by_name (instance=0x7f6c3fa7a870, detailed_signal=0x7f6c3ea5f1fa "link-changed") at gsignal.c:3426
#25 0x00007f6c3e92412a in announce_object (platform=0x7f6c3fa7a870, object=0x7f6c3fbb6fd0, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1625
#26 0x00007f6c3e92b0f9 in event_notification (msg=0x7f6c3fa946f0, user_data=0x7f6c3fa7a870) at platform/nm-linux-platform.c:1986
#27 0x00007f6c3c35812f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141
#28 recvmsgs (cb=0x7f6c3fa7a620, sk=0x7f6c3fa7a710) at nl.c:952
#29 nl_recvmsgs_report (sk=0x7f6c3fa7a710, cb=0x7f6c3fa7a620) at nl.c:1003
#30 0x00007f6c3c3584f9 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027
#31 0x00007f6c3e929dca in event_handler (channel=0x7f6c3fa78810, io_condition=G_IO_IN, user_data=0x7f6c3fa7a870) at platform/nm-linux-platform.c:4127
#32 0x00007f6c3aecc2a6 in g_main_dispatch (context=0x7f6c3fa68490) at gmain.c:3066
#33 g_main_context_dispatch (context=context@entry=0x7f6c3fa68490) at gmain.c:3642
#34 0x00007f6c3aecc628 in g_main_context_iterate (context=0x7f6c3fa68490, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#35 0x00007f6c3aecca3a in g_main_loop_run (loop=0x7f6c3fa68550) at gmain.c:3907
#36 0x00007f6c3e8e9fff in main (argc=1, argv=0x7fff0a341c88) at main.c:483
https://bugzilla.gnome.org/show_bug.cgi?id=741651
The out_keyfile, out_routefile, and out_route6file args were just
based on trivial calls to utils.h functions, and could just as easily
be done by the caller directly. So do that.
Don't pass &keyfile, &routefile, and &route6file if we aren't going to
use the return value.
Don't pass &unmanaged if we aren't going to check it. (And when we do
check it, don't g_free() it if we've asserted that it's NULL.)
Instead of having connection_from_file() return a flag telling its
caller whether to log a warning or not, just have it log the warning
(or not) itself.
Rather than having the "real" users of connection_from_file() have to
pass a dozen NULL arguments, add a separate
connection_from_file_test() for use by test-ifcfg-rh. (Likewise, since
no test cases care about ignore_error, remove that argument from
connection_from_file_test().)
If NM IPv6LL wasn't enabled then there is no need to bounce disable_ipv6
to tell the kernel to re-enable kernel IPv6LL, because kernel IPv6LL
is already enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=740702
If we have NM running, adding a route with metric 20 might conflict
and cause NM to remove the route.
Choose a different (higher) metric that is less likely to cause a
conflict.
We want to export the IP configuration of interfaces when they have some, but
the kernel doesn't care if they are IFF_UP or not. Neither should NetworkManager,
so don't force devices IFF_UP just because we're assuming their IP config.
Externally created software devices would be managed/assumed immediately
upon creation, which includes setting them IFF_UP and possibly turning
on NM-managed IPv6LL.
With this commit, expected behavior for external software devices is:
1) created: unmanaged state, no further action
2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP
3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP
3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED
This branch ensures that external software devices are not set IFF_UP
by NetworkManager when they are discovered. It additionally ensures that
they are not set IFF_UP during connection assumption. They may be set
IFF_UP later through specific user action.
https://bugzilla.gnome.org/show_bug.cgi?id=725647https://bugzilla.redhat.com/show_bug.cgi?id=1030947
INTERNAL is actually a nop right now because the only thing that
sets it is suspend/resume, which is covered by the preceding
manager_sleeping() call. But we may use this more in the future,
so add it while we're here.
Devices that are unmanaged because their parent is unmanaged
probably shouldn't assume connections either, per 4e105c50.
logind might need the network for login information, and apparently
it fails hard if the network isn't up, and apparently it doesn't
recover when the network does come up. Since NM doesn't actually
care about suspend/resume until logind is running anyway, don't
auto-launch it. Just wait until it shows up.
While we're at it, make proxy creation async.
https://bugzilla.gnome.org/show_bug.cgi?id=741572
Error: NEGATIVE_RETURNS (CWE-394): [#def8]
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:139: negative_return_fn: Function "fork()" returns a negative number.
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:139: var_assign: Assigning: signed variable "pgid" = "fork".
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:163: negative_returns: "pgid" is passed to a parameter that cannot be negative.
Error: NEGATIVE_RETURNS (CWE-394): [#def9]
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:302: negative_returns: A negative constant "-1" is passed as an argument to a parameter that cannot be negative.
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:81:2: neg_sink_parm_call: Passing "sig" to "nm_utils_kill_child_async", which cannot accept a negative number.
NetworkManager-1.1.0/src/NetworkManagerUtils.c:448:2: neg_sink_parm_call: Passing "sig" to "kill", which cannot accept a negative number.
Error: CHECKED_RETURN (CWE-252): [#def21]
NetworkManager-0.9.11.0/src/settings/plugins/ifcfg-rh/plugin.c:676: check_return: Calling "stat("/etc/hostname", &file_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.]
Error: CHECKED_RETURN (CWE-252): [#def20]
NetworkManager-0.9.11.0/src/devices/nm-device.c:5037: check_return: Calling "g_spawn_async" without checking return value (as is done elsewhere 12 out of 13 times).
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
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
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
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: CONSTANT_EXPRESSION_RESULT
src/NetworkManagerUtils.c:1978: same_on_both_sides: "(v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B) != (v1->diff_result & NM_SETTING_DIFF_RESULT_IN_B)" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical operand of if.
