No need to allocate a temporary "base" variable. Just
search for the last '/' ourselves.
All the special handling that g_path_get_basename() does,
for example handling empty filenames and removing trailing
slashes, is not needed.
Thereby fix not to return empty names such as from "ifcfg-".
This reverts commit 35988ec633.
Since commit ffe0fde235,
wireless_connection_from_ifcfg() accepts a missing @error argument.
Revert this commit because the caller then can control whether to
log the error by providing @error.
Merged all session tracking modules into one source file and simplified
it substantially. Now systemd-logind and ConsoleKit support can be built
in at the same time and both are detected at runtime. This is useful on
source based as well as binary distributions.
Original patch written by Fabio Erculiani <lxnay@sabayon.org>, modified
by Pavel Šimerda <psimerda@redhat.com> and Thomas Haller <thaller@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=686997
Acked-By: Thomas Haller <thaller@redhat.com>
There's no need to call `nm_session_monitor_get()` individually for each
call to `nm_auth_is_subject_in_acl()`.
Acked-By: Thomas Haller <thaller@redhat.com>
wireless_connection_from_ifcfg() did not support being called without
error argument.
#0 0x00007fe4fa2204e9 in g_logv (log_domain=0x7fe4f0597060 "NetworkManager-ifcfg-rh", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff1c7aaf00) at gmessages.c:989
#1 0x00007fe4fa22063f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007fe4f057eec3 in wireless_connection_from_ifcfg (file=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", ifcfg=0x7fe4fec6f730, error=0x0) at reader.c:3431
#3 0x00007fe4f057e2b6 in connection_from_file_full (filename=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", network_file=0x7fe4f05976aa "/etc/sysconfig/network", test_type=0x0, out_unhandled=0x7fff1c7ab1f8,
error=0x0, out_ignore_error=0x7fff1c7ab174) at reader.c:4750
#4 0x00007fe4f057db80 in connection_from_file (filename=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", out_unhandled=0x7fff1c7ab1f8, error=0x0) at reader.c:4834
#5 0x00007fe4f057b4a6 in nm_ifcfg_connection_new (source=0x0, full_path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", error=0x0) at nm-ifcfg-connection.c:119
#6 0x00007fe4f0579c1d in _internal_new_connection (self=0x7fe4fec6cd00, path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", source=0x0, error=0x0) at plugin.c:136
#7 0x00007fe4f0579256 in connection_new_or_changed (self=0x7fe4fec6cd00, path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", existing=0x0, out_old_path=0x7fff1c7ab458) at plugin.c:265
#8 0x00007fe4f0578f61 in read_connections (plugin=0x7fe4fec6cd00) at plugin.c:462
#9 0x00007fe4f0578839 in get_connections (config=0x7fe4fec6cd00) at plugin.c:497
#10 0x00007fe4fdc9affb in nm_system_config_interface_get_connections (config=0x7fe4fec6cd00) at settings/nm-system-config-interface.c:143
#11 0x00007fe4fdc9764f in load_connections (self=0x7fe4fec6ca40) at settings/nm-settings.c:201
#12 0x00007fe4fdc96d74 in nm_settings_new (error=0x7fff1c7abb18) at settings/nm-settings.c:1802
#13 0x00007fe4fdc37146 in main (argc=1, argv=0x7fff1c7abcd8) at main.c:415
Fixes: 356849f70c
Fixes: 12bfaf5a8d
When userspace IPv6LL capability is compiled into NetworkManager,
during deactivation NM will toggle userspace IPv6LL in some cases.
This causes link change events in the platform, which show up
in nm-device.c::device_link_changed().
When an EXTERNAL_DOWN interface was activated, the EXTERNAL_DOWN
flag was never cleared even if the device was set IFF_UP or if
a connection was activated via D-Bus (which explicitly sets the
device up).
Second, the device_link_changed() code changed device state
whether or not IFF_UP had actually changed, it simply looked at
the current value.
Together, this caused the first activation of an EXTERNAL_DOWN
device to succeed, but the EXTERNAL_DOWN flag was never cleared
even though the activation set the device IFF_UP. When a second
activation request came in, the device was moved to DISCONNECTED
state and IPv6LL genmode was reset, causing device_link_changed()
to run. Since the device had EXTERNAL_DOWN and IFF_UP were still
set, nm_device_set_unmanaged_flag() code was triggered to clear
EXTERNAL_DOWN, which resulted in a state transition to UNAVAILABLE
with a reason of CONNECTION_ASSUMED. This caused the second
activation request to fail because UNAVAILABLE devices cannot
activate connections by definition.
The fix has three parts:
1) Only change EXTERNAL_DOWN if IFF_UP actually changes, to prevent
spurious changes when something other than IFF_UP changes
2) Only clear EXTERNAL_DOWN when IFF_UP changes while the device
is UNMANAGED, since any state higher than UNMANAGED implies that
either an activation request was received (and thus the device
should be managed) or IFF_UP was set
3) Clear EXTERNAL_DOWN (without triggering state changes) when
any state higher than UNAVAILABLE is entered, since this implies
that a connection is activating or the device is no longer
IFF_UP
fixes:NetworkManager_Test108_testcase_303655
https://bugzilla.gnome.org/show_bug.cgi?id=741742
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
