After applying a configuration with static IPv4 addresses, call
/sbin/arping to announce the new addresses to the host's neighbors.
(Basic idea copied from Fedora ifup-eth.)
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f"
BOOTPROTO=none
IPADDR="10.0.0.2"
PREFIX="24"
GATEWAY="10.0.0.1"
HWADDR="52:54:00:12:34:56"
TYPE=Ethernet
NAME="ens3"
This ifcfg file results in connection.interface-name=ens3.
However, device-generated connection didn't set interface-name property.
Fix that by setting interface-name property when generating a connection. Also
allow matching connections if interface-name is not set in a connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1077743
The AC doesn't get a D-Bus path until it's exported, but that happens after
it's handed to the Device it will be activated on. The Device emits a
PropertyChanged event when it's handed the AC, but it ignores ACs that
aren't exported yet. Thus when activating, the Device doesn't emit the
AC's path at all in the ActiveConnection property because it's NULL.
Fix that by exporting the AC immediately before starting activation
with it.
Second, move the notification of the Device.ActiveConnection property
to be emitted along with the state change to PREPARE instead of long
before it. While we don't guarantee signal ordering in general, this
seems like a more correct ordering.
https://bugzilla.gnome.org/show_bug.cgi?id=723783
The atm/adsl plugin really is a generic ATM plugin but (a) it needs a
bit of work to do IPoATM rather than just PPPoATM and PPPoEoATM, and
(b) most people currently using NM's ATM support are using DSL devices
not actual ATM cards anyway, and have no idea what "ATM" even means.
If we add the necessary IPoATM support later we can rename the plugin
back to -atm
nm_device_deactivate() is used when deactivating a device, but also
when initializing it when it is first managed. Rename it to
nm_device_cleanup(), and use a different log message ("preparing
device") in the NM_DEVICE_STATE_REASON_NOW_MANAGED case.
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.
If an AP object is not given, and no compatible AP can be found
in the scan list, the AP is most likely not broadcasting its SSID
and should be marked as 'hidden'.
The config is owned by teamd and will be freed by teamdctl_free(). Also use
teamdctl_config_get_raw_direct() instead of teamdctl_config_get_raw() to be
sure we have current data.
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>
Since vxlan is new-ish, and vxlan IPv6 support in particular has only
been in the kernel since 3.11, we include our own copy of the vxlan
netlink constants rather than depending on the installed headers.
NMDeviceGre and NMDeviceMacvlan didn't deal with the possibility that
the virtual device might be created before its parent's NMDevice is
created. Mostly fix this by having them put off the call to
nm_manager_get_device_by_ifindex() until someone actually requests the
device.
This is not perfect; if someone listening to notify::parent checks
right away, they may find that the parent property is still NULL, and
notify::parent will not be emitted again when it gets filled in. But
it's better than what's there now, when parent would remain NULL
forever in this case.
NMDeviceVeth did not have this problem, but it did have another
possible problem because it wasn't cleaning up its weak references
properly.
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.
Make WWAN support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1187224 1125208 (-5%)
MM: 0 100576
(all results from stripped files)
Make Bluetooth support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1253016 1187224 (-5%)
BT: 0 85752
(all results from stripped files)
Make ADSL support a plugin using the new device factory interface.
Provides a 1% size reduction in the core NM binary.
Before After
NM: 1265336 1253016 (-1%)
ATM: 0 27360
(all results from stripped files)
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.
Instead of having NMManager listen directly to the ModemManager
for modem removal signals, have the NMDeviceModem and NMDeviceBt
listen for them (since they obviously have a pointer to the backing
NMModem object) and then re-emit any necessary device removal
signals to the manager.
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.
The OLPC mesh code did rely on nm_manager_get() referencing the
singleton when returning it, but all other callers of nm_manager_get()
did not. Thus the manager's refcount would always increase and
almost never decrease. Fix the refcounting so that the manager
always has only one ref, and it's lifetime is controlled by
main() and nothing else.
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>
