If a device had its carrier ignored, and did not have a carrier on startup,
then NetworkManager would not re-check autoconnect connections when the
device's carrier appeared. Because ignore-carrier devices are always
in DISCONNECTED state when they are managed, the nm-device.c::carrier_changed()
code essentially did nothing when the carrier appeared. It needs to
also trigger an auto-activation recheck signal when the carrier appears
to ensure that now-valid connections (like those that require DHCP or
IPv6) can be auto-activated.
Devices disconnected explicitly by user should stay disconnected, preventing
auto-connecting until manual request.
Introduction of NM_DEVICE_STATE_DEACTIVATING state broke this feature.
disconnect_cb() correctly set autoconnect device property to FALSE, however
nm_device_state_changed() put it to TRUE again. Thus only the active connection
was blocked instead of the whole device.
https://bugzilla.gnome.org/show_bug.cgi?id=726239
Because not all clients set the 'hidden' property in a connection for
hidden/non-SSID-broadcasting networks, they may not show up in
the device's available-connections property. After the
PendingActivation object removal, all activations require the
connection to be in available-connections, and thus hidden SSID
networks could not be activated.
Unfortunately check_connection_available() is used both during
activation and to populate the available-connections array, but we
only want to special-case activation paths, and still ensure that
SSIDs not found in the scan list are not in available-connections.
To make it clear this is a WiFi only hack, and that we should
remove it at some point in the future, create another class method
specifically for hidden WiFi and use that in activation paths to
special-case hidden WiFi connection activation.
Instead of only passing the ifindex to the callback, pack
additional data. This allows for better logging by also
writing the g_idle_add id which allows to associate the scheduling
with cancel calls.
Also, this fixes that the callback could not clear the
@delete_on_deactivate_id of the device, so that a following
delete_on_deactivate_unschedule() would think that there is
still something to cancel.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes queued activation request to be aborted because the software
device gets removed before the device reaches the PREPARED state.
This happens, because when the previous connection disconnects, the
device will schedule its removal.
https://bugzilla.redhat.com/show_bug.cgi?id=1073015
Signed-off-by: Thomas Haller <thaller@redhat.com>
Setting the address flag IFA_F_NOPREFIXROUTE broke adding the device route to
the IPv6 prefix because the check for nm_ip6_config_destination_is_direct()
caused the route to be skipped. This, together with the kernel no
longer adding the prefix route resulted in no device route for autoconf
/64 prefixes.
https://bugzilla.redhat.com/show_bug.cgi?id=1068632https://bugzilla.redhat.com/show_bug.cgi?id=1072410
Signed-off-by: Thomas Haller <thaller@redhat.com>
The IPv6 spec say that when performing SLAAC, you should sent at most
3 RSes, at least 4 seconds apart. We were previously continuing to
send RSes forever if we didn't get back a response. Fix that.
(Since the fix involves making nm-lndp-rdisc use NMPlatform, it was
necessary to rewrite the rdisc test program a bit, to not try to
include <net/if.h>, which is incompatible with <linux/if.h>.)
This got broken at some point. The intent of ignore-carrier was always
to ignore the carrier for IP configuration for static/manual connections,
but never for DHCP/SLAAC where a link is actually required. Thus
when checking whether to postpone IP configuration for a master interface
that's using DHCP/SLAAC, don't allow ignore-carrier to factor into
the decision.
Add a generic signal that devices can use to indicate that something
material in the network situation changed, and that auto-activation
may now be possible. This reduces specific knowledge of device types
in the policy.
In preparation for making WWAN and Bluetooth plugins, rework
the device plugin interface to meet those plugins' needs and
port WiMAX over in the process.
In reality the connection provider (NMSettings) is always the same
object, and some device plugins need access to it. Instead of
cluttering up the device plugin API by passing the provider into
every plugin regardless of whether the plugin needs it, create
a getter function.
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.
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.
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>
This feature needs support from the kernel and libnl.
If there is no system support, NM acts as before, adding the
autoconf address as /128. It does so, to prevent the kernel
from adding a route for this prefix. With system support, we
add the address as /64 and set the flag IFA_F_NOPREFIXROUTE.
https://bugzilla.redhat.com/show_bug.cgi?id=1044590https://bugzilla.redhat.com/show_bug.cgi?id=1045118
Signed-off-by: Thomas Haller <thaller@redhat.com>
NetworkManager uses the sysctl value 'max_addresses' as the kernel does.
There is however a difference in what addresses are taken into account.
The kernel counts all addresses on the interface (including temporary,
private addresses and user configured ones).
NM instead only limits the number of public autoconf addresses to
'max_addresses'. This is because it is difficult for NM to count all
addresses (which can come from different sources) and it is not
necessarily a more logical behavior. Only be aware, that NM uses
the same config value as the kernel, but counts differently.
Especially, the kernel might reach the limit earlier then NM in the
presence of temporary addresses or addresses not from SLAAC.
Note, that the kernel uses 'max_addresses' only to limit public, autoconf
addresses. So this limit does not affect NM adding as many addresses as
it wants.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
Since IPv6 configuration gets updated every time a router advertisement
comes in, it can lead NM to continuously logging:
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
that's annoying. So after the initial configuration is done, make
subsequent IPv6 Commit log messages debug instead of info.
Don't disable IPv6 when we're about to assume a connection that may well
have IPv6 already configured on the interface, which removes all addresses
and routes from the interface and generally Breaks Stuff.
When disconnecting a master device, propagate its NMDeviceStateReason
to the slaves. That way, if the reason is USER_REQUESTED, then the
slaves will be blocked from re-autoconnecting as well.
Add a property to NMDevice that can be used to tell whether the device
is enslaved, and if so what its master is.
This is currently internal-only, but it could be exported later
perhaps.
Virtual devices may be created and destroyed, but we need to keep
their autoconnect state across that. Previously this was handled by
NMManager, but it really belongs with the other autoconnect tracking
in NMPolicy and NMSettingsConnection.
This also fixes a bug where NMPolicy would sometimes decide to
autoactivate a virtual device connection which NMManager would then
have to cancel.
When a device is disconnected by the user (as opposed to due to
network or hardware error, etc), set it first to DEACTIVATING, which
does nothing but queue a transition to disconnected. This lets other
parts of NM observe the device when it is about-to-disconnect, but
still has an associated connection.
NMSettings (and NMConnectionProvider) had a signal to indicate when it
had loaded the connections, but in reality this always happened before
nm_settings_new() returned (as a side effect of calling
unmanaged_specs_changed()) and so no one else would ever actually see
the signal. So just kill it.
The sysctl values in the kernel (for those values for which
nm_platform_sysctl_get_uint() is currently used) are defined as s32.
Change nm_platform_sysctl_get_uint() to nm_platform_sysctl_get_int32()
and ensure, that a matching integer type is used thoroughly.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This appears to be a bug since the original 0.9.0 release when
connection permissions were implemented.
If all the following are true:
- the user is local (as determined by systemd or ConsoleKit)
- the user has been given the NETWORK_CONTROL PolicyKit permission
- the user is not listed in the connection's permissions
- the user knows the D-Bus object path of a connection which they
have no permissions for
then that user may activate/deactivate connections that are not
visible to that user as determined by the connection permissions.
Fix that by ensuring that these operations check whether the user
has permission.
These operations are *not* affected, and have always checked user
permissions before allowing the operation:
- modifying any connection details
- requesting any secrets or passwords for the connection
- deleting the connection
If NM is not explicitly managing resolv.conf (either due to the "dns"
NetworkManager.conf setting, or because resolv.conf is immutable),
then don't try to parse nameservers out of it when capturing a
connection, since there's no reason to believe that the name servers
there are related to any particular connection.
