| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
But, of course, only one realized device can have the same
interface name at a time.
This commit effectively reverts most of:
1b37cd03409fa3c0fb26fb6e8093b54b2b7c5d8d
core: allow ActiveConnections to be created without a device
But it's not easy to do a separate revert of that code due to
interdependencies with nm-manager.c.
Creating devices when they are defined by a connection also makes
makes it possible to require the NMDevice to be present when
activating it, which means we can remove a bunch of code from
NMManager that had to handle software devices not existing yet at
the time of the activation request.
But it also means we must be more careful when finding master
interfaces during slave activation, since we cannot simply match
by interface name alone. Instead we must find the master which
matches both the interface name and can control slaves of the type
which is being activated.
|
| |
|
|
|
| |
Mirror new NetworkManager API to return both real devices and
device placeholders.
|
| | |
|
| |
|
|
| |
Returns both realized and un-realized devices.
|
| |
|
|
|
|
|
|
| |
Ensure the platform link with the same interface name as the
NMDevice is actually compatible with it before using the link
for initialization of device properties. If not, remove the
NMDevice and create a new one since there are kernel resources
with a different type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unrealized devices aren't backed by kernel resources and so won't know
all of their attributes. That means three things:
1) they must update their attributes when they become realized
2) they must clear those attributes when unrealized
3) they must be looser in checking compatible connections until
they are realized
This requires that the setup() function be split into two parts, start & finish,
because finish must be run after add_device()
Also, we can simplify whether to pay attention to 'recheck-assume', which
is now dependent on priv->is_nm_owned, because the only case where NM should
*not* listen for the 'recheck-assume' signal is when the device is a
software device created by NM itself. That logic was previously spread
across the callers of add_device() but is now consolidated into
nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
|
| |
|
|
|
|
|
|
|
| |
update_connection()/check_connection_compatible()
The device properties are obtained via netlink, thus we get proper
platform notifications whenever they change. So the device properties
always reflect the platform state and there is no need to refresh
it during update_connection()/check_connection_compatible().
|
| | |
|
| |
|
|
|
| |
let update_properties_from_ifindex() also support clearing
the properties to make it usable from unrealize().
|
| |
|
|
|
| |
When a device is unrealized, its class-specific properties must also be cleared
since the device is no longer valid.
|
| | |
|
| |
|
|
|
|
|
| |
This property is TRUE for devices that exist either as a kernel device
or are backed by some other resource (eg, ModemManager object, Bluez
device, etc). It will eventually be FALSE for software devices that
are not yet instantiated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is only one user of the NM_DEVICE_MASTER property (NMActiveConnection).
device_master_changed() uses the property for change notifications,
but returns early if !nm_device_get_master().
We might emit the "notify::master" signal too often, even when nothing
changed (because currently we always emit it when priv->master changes).
If we would fix that to only emit the signal when nm_device_get_master()
actually changes, it would still be correct, because device_master_changed()
doesn't care about notifications when the master is unset.
Hence, the only user doesn't care about the difference. So change it because
it's unexpected that the property and function are not completely equal.
|
| |
|
|
|
|
|
| |
nm_utils_g_value_set_object_path_array()
nm_utils_g_value_set_object_path_array() is used at several places, so that
this optimazation makes some sense.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Commit cd3df12c8f8ed6c868c12bc4e7fe6ba162dafc5b reused the
virtual function component_added() to notify the vlan device
about a possibly new parent.
This reuse of the virtual function for another purpose is confusing.
Clean that up by splitting the implementation and add a new
virtual function nm_device_notify_new_device_added() which gets
(only implemented by NMDeviceVlan).
|
| |
|
|
|
|
| |
This is a straightforward copy of the changes done in libnm. It is done to cope
with test failures due to redundant or misordered signals. See
commit 52ae28f6e5bf68c575145f633f7c85c145aa20fe for a detailed explanation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deleting a master-device either via `nmcli device delete`
or `ip link delete`, the slave-device would hang.
This seems to be broken for a very long time already.
This is due to the following:
#0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175
#1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117
#2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460
Previously, nm_device_slave_notify_release() being called with reason
"NONE" did not actually transition the device-state, thus keeping the
device wrongly in activated state.
There were two callers that passed configure=FALSE to nm_device_release_one_slave(),
(and thus reason=NONE to nm_device_slave_notify_release()):
- (1) device_link_changed():
nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/);
- (2) nm_device_removed():
nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED);
We should always change the device-state during nm_device_slave_notify_release()
regardless of the reason.
(2) was added by commit c83b40aca76fc0ed624a6c9e71dbd7b0abfa13f2, later
refined by commit 5dd48f7527c67b399ac144f594e035216771d61c. In a way
change the second fix to perform some of the configuration (but still
not unenslaving the device).
|
| |
|
|
| |
It is already performed in do_connections().
|
| |
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1268911
|
| |
|
|
|
|
|
|
|
| |
Check if 'ipip' and 'ip6_tunnel' modules are loaded when trying to
perform link tests that require them and skip the tests if the modules
are not available.
Fixes: 133724d95805142e29c6d34a7bc201368e7a9d05
Fixes: 1a3448b43bb122243b7f9730e2ed7d62ab0a4c1e
|
| |\
| |
| |
| |
| |
| | |
Add support for creating IP tunnel interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=758047
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
As per previous commit, GRE tunnels are now represented as generic IP
tunnel devices.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new object type represents tunnels over IPv4 and IPv6.
We have a single setting type (NMSettingIPTunnel) for tunnels and it
can't be shared among different device factories. So we define also a
single device type for all tunnels.
This new object will also represent GRE tunnels, which before were
instantiated as NMDeviceGre and had a ".Device.Gre" D-Bus
interface. This commit introduces a change in behavior.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Add a generic NMSettingTunnel which describes properties of tunnels
over IPv4 and IPv6 (GRE, SIT, IPIP, IPIP6, IP6GRE, etc.). Since those
tunnel types all have similar properties it makes sense to have a
single setting type for them.
|
| |/
|
|
|
|
| |
Add function nm_utils_enum_get_values() which returns a string array
containing the enum values. It can be used, for example, to build a
list of allowed values for user.
|
| |
|
|
|
|
|
|
|
|
|
| |
D-Bus has an upper limit on number of Match rules and it's rather easy
to hit as the proxy likes to add one for each object. Let's remove the Match
rule the proxy added and ensure a less granular rule is present instead.
Ideally, we should be able to tell glib not to hook its rules.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=758749
https://bugzilla.gnome.org/show_bug.cgi?id=758751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When wpa_supplicant keeps returning an error, NetworkManager was trying over
and over again. Which resulted in endless messages:
<error> [1448462154.584916] [supplicant-manager/nm-supplicant-interface.c:879] interface_add_cb(): (AAA): error adding interface: wpa_supplicant couldn't grab this interface.
NetworkManager[17073]: <info> (AAA): supplicant interface state: starting -> down
Testcase:
$ iw list | grep -A 3 "interface combinations"
interface combinations are not supported
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
$ sudo iw wlan0 interface add AAA type managed
...
$ sudo iw dev AAA del
Fixes: 3a2e6de0d30217753c825ba1f20e589c1f647780
https://bugzilla.gnome.org/show_bug.cgi?id=753971
|
| |
|
|
|
|
|
|
|
| |
@random_data is declared as _cleanup_free_.
Freeing it is unnecessary and freeing without clearing the
pointer leads do a double free.
This reverts commit 3d1557eaad4d408218bee8996c3721eb2aa5e22c.
|
| |
|
|
| |
Fixes: 64c6b124d24c0cd06b2868b4ca6a71f8e78e6c00
|
| |
|
|
| |
Fixes: 64c6b124d24c0cd06b2868b4ca6a71f8e78e6c00
|
| |
|
|
| |
Fixes: 64c6b124d24c0cd06b2868b4ca6a71f8e78e6c00
|
| |
|
|
|
|
| |
type tun'
Fixes: 64c6b124d24c0cd06b2868b4ca6a71f8e78e6c00
|
| |
|
|
|
| |
nmcli> set eth.s390-options portno=
(process:4711): libnm-CRITICAL **: nm_setting_wired_add_s390_option: assertion 'value_len > 0 && value_len < 200' failed
|
| |
|
|
|
|
|
| |
nmcli> set vpn.data haha=
(process:3951): libnm-CRITICAL **: nm_setting_vpn_add_data_item: assertion 'strlen (item) > 0' failed
nmcli> set vpn.secrets haha=
(process:3951): libnm-CRITICAL **: nm_setting_vpn_add_secret: assertion 'strlen (secret) > 0' failed
|
| |
|
|
|
|
| |
when providing empty arguments.
Fixes: 0c65b289601d46edb0a950e291ddd376e368ccfd
|
