We don't want the kernel to do IPv6 addrconf, but we do want it to
notice the non-router-related fields in the RA (eg, Retrans Timer) and
update the interface state to reflect them. So instead of turning off
accept_ra, we leave it turned on, and turn off accept_ra_defrtr,
accept_ra_rtr_pref, and accept_ra_pinfo instead.
Remove the "silent_on_error" flag from nm_platform_sysctl_get(), and
make both get() and set() log at debug level on ENOENT and error level
on all other errors, always.
Also ensure that we don't sometimes write "failed to set 'x' to 'y':
Success" when a partial write occurs.
get_best_ip4_device() and get_best_ip6_device() iterate over
the list of devices to find the device with the default route.
The order of iteration is arbitrarly choosen.
Before, if two devices had the same priority, it would choose
the first one. Change it so that the device which currently has
the default route keeps it -- until it gets deactivated or a higher
priorty device gets connected.
Signed-off-by: Thomas Haller <thaller@redhat.com>
e19f48ec was incomplete; it failed to handle device disconnections.
NMDevice will clear its internal activation request *before*
emitting the state change, which meant that when the
NMActRequest processes the DISCONNECTED state change, the:
if (NM_ACTIVE_CONNECTION (nm_device_get_act_request (device)) != active)
return;
statement triggered and the DISCONNECTED state change was not
processed.
Instead of having NMDevice keep the activation request alive over
the entire DISCONNECTED state transition, which may have much
greater implications, handle the special-case locally in the
NMActRequest code itself.
connection_parser.c: In function 'make_ip4_setting':
connection_parser.c:660:33: error: 'method' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!is_static_block && strstr (method, "dhcp")) {
connections.c: In function ‘load_cmd_line_edit_lib’:
connections.c:5744:17: error: ‘module’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_module_close (module);
Signed-off-by: Thomas Haller <thaller@redhat.com>
reader.c: In function 'parse_infiniband_p_key':
reader.c:3947:5: error: 'id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
id = (id | 0x8000);
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Really implement the DEACTIVATING state this time. This now allows easy
"pre-down" hooks whenever we choose to implement that.
Next, fix a crash during re-activation where a pending activation request
mis-interpreted device state changes from a previous activation request
that was deactivating.
When a new activation request comes in and the device is already
activated, two NMActRequests will exist for the device in parallel.
The old one handles de-activation of the device and is then disposed,
while the new one waits until the device is de-activated and then
takes over and starts the new activation.
Both requests are watching device state, and the new request may
mis-interpret the de-activation states and clean up its device pointer,
leading to assertion failures when the new activation starts.
To fix this (and because NMVPNConnection *does* always want to see
de-activation events from the device) remove the code that tries to
ignore de-activation from NMActiveConnection's device state handler.
Instead, have NMActRequest skip any reaction to device state changes
unless it is the current activation request on the device. The VPN
code always wants to see the device's state, so it doesn't need this
check.
If a device is already activated, queue the new activation to allow
the transition through the DEACTIVATING state.
---
Also remove the "HACK" bits in nm_device_deactivate(). This hack was
added on 2007-09-25 in commit 9c2848d. At the time, with user settings
services, if a client created a connection and requested that NM
activate it, NM may not have read the connection from the client over
D-Bus yet. So NM created a "deferred" activation request which waited
until the connection was read from the client, and then began activation.
The Policy watched for device state changes and other events (like
it does now) and activated a new device if the old one was no longer
valid. It specifically checked for deferred activations and then
did nothing. However, when the client's connection was read, then
nm-device.c cleared the deferred activation bit, leading to a short
period of time where the device was in DISCONNECTED state but there
was no deferred activation, because the device only changes state to
PREPARE from the idle handler for stage1. If other events happened
during this time, the policy would tear down the device that was
about to be activated. This early state transition to PREPARE
worked around that.
We need to remove it now though, because (a) the reason for its
existence is no longer valid, and (b) _device_activate() may now
be called from inside nm_device_state_changed() and thus it cannot
change to a new state inside the function.
If the firewall didn't know about the interface, don't log errors
about it because there's nothing NM can do. Also, sometimes NM
sends the not-IP interface, like when disconnecting WWAN when the
PPP interface is already gone.
Such a failure can happen easily, because we now request an initial dump
to get AF_INET6 addresses in order to check for extended ifa flags support.
This is not critical, so downgrade the error log.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Without this patch, the following two commands fail:
nmcli connection modify em1 connection.master
nmcli connection modify em1 connection.master ""
Signed-off-by: Thomas Haller <thaller@redhat.com>
Actually, get_ip_ifindex() should always return 0 or > 0. Just in case,
be extra careful and modify the conditions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a regression introduced in 5074898591.
The while loop did only refetch the cached value (because the glib main loop
was blocked and only the cached device flags were checked).
Also, instead on relying of g_usleep(), wait until a maximum time of waiting
is expired. The duration of g_usleep() might not be very accurate.
Also, do no longer check the cached device state before setting the
device flag. The cache might be out of date, so we just set the flag.
https://bugzilla.gnome.org/show_bug.cgi?id=724363
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make sure NMPlatformGreProperties->path_mtu_discovery is always TRUE
or FALSE, even if the value from the kernel is "2" or "16" or
something. (This makes it consistent with what we do for other boolean
netlink properties.)
If the kernel doesn't tag a modem's ethernet interface with
DEVTYPE=wwan then NetworkManager has no idea that's a modem
(and cannot be used until connected via the control port).
Since DEVTYPE=wwan devices get ignored by NM, so should these
interfaces when NM knows they are modems.
That got broken at some point for ModemManager1, because the
data port isn't read until the modem is connected. NM only
looked for and removed the data-port-as-ethernet-device when
the modem was added, long before the MM1 data port was found.
ModemManager does provide a list of ports owned by the modem
though, which we can use at modem addition time to remove
an ethernet device that is controled by the modem.
Auth requests only happen during activation and there's no need to
request secrets at any other time. Ensure that the device state
won't change to NEED_AUTH except when activating.
(There's a case in NMModemBroadband where set_mm_enabled()
when the modem is locked may cause this, but we'll solve this
a different way later.)
https://bugzilla.redhat.com/show_bug.cgi?id=1058308
When c4fc72c7 began using the DEACTIVATING state, the modem code
wasn't updated to handle this. Because it only checked for
activating or ACTIVATED states to determine whether the modem was
previously connected, and thus when an MM disconnect was needed,
when the device enters the DISCONNECTED state it was no longer
considered previously active, and not disconnected.
Also, remove the NEED_AUTH handling from the modem code's device
state switch, because it does not appear to be needed. The
modem will only enter NEED_AUTH when it requires PAP/CHAP secrets
during the connection attempt or when a PIN is required before
enabling the modem. In both cases the modem won't yet be connected,
so this code will never be hit.
The functions nm_remote_connection_save(), nm_remote_connection_commit_changes(),
and nm_remote_connection_commit_changes_unsaved() indicate in the documentation,
that they allow omitting the callback argument. Remove invalid checks
for callback.
Signed-off-by: Thomas Haller <thaller@redhat.com>
