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.
Use a GSList of the string values, instead of an array of GQuarks.
Using GQuarks does not allow to add arbitrary strings, because they
would leak the internalized strings. The next patch will begin
using unique, non-const action strings.
Given the rather small number of expected pending states, a singly
linked list seems appropriate.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(some fixes and simplifications by dcbw based on patch reviews)
The NMActiveConnection class tracks the full activation request, and internal
activation requests go through the same process as external ones, including
some authentication. Sometimes that means activation is scheduled, control
returns to the mainloop, and then the activation proceeds from an idle
handler.
Unfortunately, that means that adding a pending "activation" action from
nm-device.c doesn't always work, since there is a short window between when
the activation is started in nm-manager.c (in nm_manager_activate_connection())
and when the device actually changes state. Inside that window, the pending
actions may drop to zero, and startup will be declared complete before the
device actually starts activating.
Instead, ensure that the pending action is added when the internal activation
is actually started (eg, when NMActiveConnection receives the NMDevice object).
Carrier state is only valid if the network interface is IFF_UP, because drivers
are not required to do carrier detection if the device is not up. Thus, if NM
is the first process to set the interface IFF_UP, there may be a short delay
while the driver performs carrier detection. NetworkManager must suppress
"startup complete" during this delay to ensure that the carrier state is known
before making startup property decisions.
Previously, when NetworkManager set the interface IFF_UP, the interface would
not have a carrier for a few seconds until the driver's carrier detection was
done. Since the interface had no carrier, NetworkManager could not begin
connection activation on the interface, and the interface would not suppress
the "startup complete" transition. Thus, NetworkManager would declare that
startup was complete prematurely and anything depending on startup network
connectivity would fail as no interfaces were active.
https://bugzilla.redhat.com/show_bug.cgi?id=1034921https://bugzilla.redhat.com/show_bug.cgi?id=1030583
This lets us do two things:
1) ensure that pending actions are unique and not doubly added/removed
2) we can (eventually) print out the pending action list for debugging
However, since we cannot have two pending actions with the same name at
the same time, we need to change the queued device state actions to
include the state name. But that makes debugging even more descriptive
so it's a bonus.
When a device is initialized to be managed, it will transition through states
unmanaged -> unavailable -> disconnected. We don't want to remove software
devices during this initial transition to disconnected, because it prevents
auto-activation.
Test case:
$ nmcli con add type vlan ifname myvlan dev eth0 id 123
NM should immediately create myvlan interface and automatically activate it.
https://bugzilla.redhat.com/show_bug.cgi?id=1035814
Slaves have no IP configuration and should not have any IP settings.
This fixes connection comparison between generated slave connections
and persistent slave connections, as persistent slave connections won't
have any IP configuration.
This reverts commit 9a019f1fb5.
Generic connections should be bound to their interface names in a more generic
way instead of in nm-device.c. The Generic device itself should set the
attributes it needs when generating the connection, like other device types do.
This will be done in a following commit.
Previously, the device activation would stall in this case, because
the code wasn't expecting it to happen. In particular, this happens
when trying to assume a device that is up but has no IP config.
https://bugzilla.gnome.org/show_bug.cgi?id=715181
