2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2011 - 2015 Red Hat, Inc.
|
2012-10-29 19:02:45 -05:00
|
|
|
*/
|
|
|
|
|
|
2021-02-04 18:04:13 +01:00
|
|
|
#include "src/core/nm-default-daemon.h"
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2016-09-29 13:49:01 +02:00
|
|
|
#include "nm-device-bridge.h"
|
|
|
|
|
|
2013-08-23 23:02:54 +02:00
|
|
|
#include <stdlib.h>
|
2020-12-13 16:08:56 +01:00
|
|
|
#include <linux/if_ether.h>
|
2012-10-29 19:02:45 -05:00
|
|
|
|
|
|
|
|
#include "NetworkManagerUtils.h"
|
|
|
|
|
#include "nm-device-private.h"
|
2021-03-04 11:29:39 +01:00
|
|
|
#include "libnm-platform/nm-platform.h"
|
2014-09-08 10:12:28 -05:00
|
|
|
#include "nm-device-factory.h"
|
2021-08-20 18:40:21 +08:00
|
|
|
#include "libnm-core-aux-intern/nm-libnm-core-utils.h"
|
2021-02-12 15:01:09 +01:00
|
|
|
#include "libnm-core-intern/nm-core-internal.h"
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2020-11-06 18:22:11 +01:00
|
|
|
#define _NMLOG_DEVICE_TYPE NMDeviceBridge
|
2014-08-02 15:14:26 +02:00
|
|
|
#include "nm-device-logging.h"
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2016-09-29 13:49:01 +02:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
enum _NMBtCbState {
|
|
|
|
|
_NM_BT_CB_STATE_NONE = 0, /* Registration not done */
|
|
|
|
|
_NM_BT_CB_STATE_WAIT = 1, /* Waiting for the callback */
|
|
|
|
|
_NM_BT_CB_STATE_SUCCESS = 2, /* Callback succeeded */
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-29 13:49:01 +02:00
|
|
|
struct _NMDeviceBridge {
|
|
|
|
|
NMDevice parent;
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
GCancellable *bt_cancellable;
|
2019-03-15 08:53:37 +01:00
|
|
|
bool vlan_configured : 1;
|
2022-04-05 22:41:51 +02:00
|
|
|
unsigned bt_cb_state : 2;
|
2016-09-29 13:49:01 +02:00
|
|
|
};
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2016-09-29 13:49:01 +02:00
|
|
|
struct _NMDeviceBridgeClass {
|
|
|
|
|
NMDeviceClass parent;
|
|
|
|
|
};
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2016-09-29 13:49:01 +02:00
|
|
|
G_DEFINE_TYPE(NMDeviceBridge, nm_device_bridge, NM_TYPE_DEVICE)
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2017-06-01 11:57:42 +02:00
|
|
|
const NMBtVTableNetworkServer *nm_bt_vtable_network_server = NULL;
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2015-04-17 15:15:38 +02:00
|
|
|
static NMDeviceCapabilities
|
2012-10-29 19:02:45 -05:00
|
|
|
get_generic_capabilities(NMDevice *dev)
|
|
|
|
|
{
|
2014-09-24 17:46:15 -05:00
|
|
|
return NM_DEVICE_CAP_CARRIER_DETECT | NM_DEVICE_CAP_IS_SOFTWARE;
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
2013-11-06 17:44:18 -06:00
|
|
|
static gboolean
|
2021-11-09 13:28:54 +01:00
|
|
|
check_connection_available(NMDevice *device,
|
|
|
|
|
NMConnection *connection,
|
2015-01-16 14:54:11 +01:00
|
|
|
NMDeviceCheckConAvailableFlags flags,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *specific_object,
|
|
|
|
|
GError **error)
|
2013-11-06 17:44:18 -06:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
2017-06-03 13:31:46 +02:00
|
|
|
NMSettingBluetooth *s_bt;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 16:21:43 +02:00
|
|
|
if (!NM_DEVICE_CLASS(nm_device_bridge_parent_class)
|
|
|
|
|
->check_connection_available(device, connection, flags, specific_object, error))
|
2017-06-02 00:01:26 +02:00
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-06-03 13:31:46 +02:00
|
|
|
s_bt = _nm_connection_get_setting_bluetooth_for_nap(connection);
|
|
|
|
|
if (s_bt) {
|
2018-06-27 16:21:43 +02:00
|
|
|
const char *bdaddr;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 16:21:43 +02:00
|
|
|
if (!nm_bt_vtable_network_server) {
|
|
|
|
|
nm_utils_error_set_literal(error,
|
|
|
|
|
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
|
|
|
|
|
"bluetooth plugin not available to activate NAP profile");
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 16:21:43 +02:00
|
|
|
bdaddr = nm_setting_bluetooth_get_bdaddr(s_bt);
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
if (!nm_bt_vtable_network_server->is_available(
|
|
|
|
|
nm_bt_vtable_network_server,
|
|
|
|
|
bdaddr,
|
2022-04-05 22:41:51 +02:00
|
|
|
(self->bt_cancellable || self->bt_cb_state != _NM_BT_CB_STATE_NONE) ? device
|
|
|
|
|
: NULL)) {
|
2018-06-27 16:21:43 +02:00
|
|
|
if (bdaddr)
|
|
|
|
|
nm_utils_error_set(error,
|
|
|
|
|
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
"no suitable NAP device \"%s\" available",
|
|
|
|
|
bdaddr);
|
2018-06-27 16:21:43 +02:00
|
|
|
else
|
|
|
|
|
nm_utils_error_set_literal(error,
|
|
|
|
|
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
"no suitable NAP device available");
|
2018-06-27 16:21:43 +02:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2017-06-03 13:31:46 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2013-11-06 17:44:18 -06:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
static gboolean
|
2018-06-27 17:00:55 +02:00
|
|
|
check_connection_compatible(NMDevice *device, NMConnection *connection, GError **error)
|
2012-10-29 19:02:45 -05:00
|
|
|
{
|
|
|
|
|
NMSettingBridge *s_bridge;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *mac_address;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 17:00:55 +02:00
|
|
|
if (!NM_DEVICE_CLASS(nm_device_bridge_parent_class)
|
|
|
|
|
->check_connection_compatible(device, connection, error))
|
2013-03-07 07:44:36 -05:00
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 17:00:55 +02:00
|
|
|
if (nm_connection_is_type(connection, NM_SETTING_BLUETOOTH_SETTING_NAME)
|
|
|
|
|
&& _nm_connection_get_setting_bluetooth_for_nap(connection)) {
|
|
|
|
|
s_bridge = nm_connection_get_setting_bridge(connection);
|
|
|
|
|
if (!s_bridge) {
|
|
|
|
|
nm_utils_error_set_literal(error,
|
|
|
|
|
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
|
|
|
|
|
"missing bridge setting for bluetooth NAP profile");
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-06-27 17:00:55 +02:00
|
|
|
/* a bluetooth NAP connection is handled by the bridge.
|
|
|
|
|
*
|
|
|
|
|
* Proceed... */
|
|
|
|
|
} else {
|
|
|
|
|
s_bridge =
|
|
|
|
|
_nm_connection_check_main_setting(connection, NM_SETTING_BRIDGE_SETTING_NAME, error);
|
|
|
|
|
if (!s_bridge)
|
all: change handling of connection.type for bluetooth NAP and in general
Branch f9b1bc16e9e691ab89caf883f33d94be72364671 added bluetooth NAP
support. A NAP connection is of connection.type "bluetooth", but it
also has a "bridge" setting. Also, it is primarily handled by NMDeviceBridge
and NMBridgeDeviceFactory (with help from NMBluezManager).
However, don't let nm_connection_get_connection_type() and
nm_connnection_is_type() lie about what the connection.type is.
The type is "bluetooth" for most purposes -- at least, as far as
the client is concerned (and the public API of libnm). This restores
previous API behavior, where nm_connection_get_connection_type()
and nm_connection_is_type() would be simple accessors to the
"connection.type" property.
Only a few places care about the bridge aspect, and those places need special
treatment. For example NMDeviceBridge needs to be fully aware that it can
handle bluetooth NAP connection. That is nothing new: if you handle a
connection of any type, you must know which fields matter and what they
mean. It's not enough that nm_connection_get_connection_type() for bluetooth
NAP connectins is claiming to be a bridge.
Counter examples, where the original behavior is right:
src/nm-manager.c- g_set_error (error,
src/nm-manager.c- NM_MANAGER_ERROR,
src/nm-manager.c- NM_MANAGER_ERROR_FAILED,
src/nm-manager.c- "NetworkManager plugin for '%s' unavailable",
src/nm-manager.c: nm_connection_get_connection_type (connection));
the correct message is: "no bluetooth plugin available", not "bridge".
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: if ( ( nm_connection_is_type (connection, NM_SETTING_WIRED_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: && !nm_connection_get_setting_pppoe (connection))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_VLAN_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_WIRELESS_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_INFINIBAND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BOND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_TEAM_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BRIDGE_SETTING_NAME))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c- return TRUE;
the correct behavior is for ifcfg-rh plugin to reject bluetooth NAP
connections, not proceed and store it.
2017-06-01 14:55:41 +02:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-05-16 17:51:27 +02:00
|
|
|
mac_address = nm_setting_bridge_get_mac_address(s_bridge);
|
2014-09-24 16:58:07 -05:00
|
|
|
if (mac_address && nm_device_is_real(device)) {
|
2014-06-21 12:44:56 -04:00
|
|
|
const char *hw_addr;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-06-21 12:44:56 -04:00
|
|
|
hw_addr = nm_device_get_hw_address(device);
|
2018-06-27 17:00:55 +02:00
|
|
|
if (!hw_addr || !nm_utils_hwaddr_matches(hw_addr, -1, mac_address, -1)) {
|
|
|
|
|
nm_utils_error_set_literal(error,
|
|
|
|
|
NM_UTILS_ERROR_CONNECTION_AVAILABLE_TEMPORARY,
|
|
|
|
|
"mac address mismatches");
|
2014-05-16 17:51:27 +02:00
|
|
|
return FALSE;
|
2018-06-27 17:00:55 +02:00
|
|
|
}
|
2014-05-16 17:51:27 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
2021-11-09 13:28:54 +01:00
|
|
|
complete_connection(NMDevice *device,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
const char *specific_object,
|
core: avoid clone of all-connections list for nm_utils_complete_generic()
NMSettings exposes a cached list of all connection. We don't need
to clone it. Note that this is not save against concurrent modification,
meaning, add/remove of connections in NMSettings will invalidate the
list.
However, it wasn't save against that previously either, because
altough we cloned the container (GSList), we didn't take an additional
reference to the elements.
This is purely a performance optimization, we don't need to clone the
list. Also, since the original list is of type "NMConnection *const*",
use that type insistently, instead of dependent API requiring GSList.
IMO, GSList is anyway not a very nice API for many use cases because
it requires an additional slice allocation for each element. It's
slower, and often less convenient to use.
2018-03-14 08:57:42 +01:00
|
|
|
NMConnection *const *existing_connections,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error)
|
2012-10-29 19:02:45 -05:00
|
|
|
{
|
2017-04-18 12:09:02 +02:00
|
|
|
nm_utils_complete_generic(nm_device_get_platform(device),
|
2016-03-08 13:57:20 +01:00
|
|
|
connection,
|
2012-10-29 19:02:45 -05:00
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
|
existing_connections,
|
|
|
|
|
NULL,
|
2014-08-25 16:21:59 +02:00
|
|
|
_("Bridge connection"),
|
2014-08-05 17:11:57 -04:00
|
|
|
"bridge",
|
2019-05-07 10:15:10 +02:00
|
|
|
NULL,
|
2012-10-29 19:02:45 -05:00
|
|
|
TRUE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-08-20 18:40:21 +08:00
|
|
|
_nm_connection_ensure_setting(connection, NM_TYPE_SETTING_BRIDGE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-20 09:40:17 -04:00
|
|
|
static void
|
|
|
|
|
to_sysfs_group_address_sys(const char *group_address, NMEtherAddr *out_addr)
|
|
|
|
|
{
|
|
|
|
|
if (group_address == NULL) {
|
2020-11-19 11:26:32 +01:00
|
|
|
*out_addr = NM_ETHER_ADDR_INIT(NM_BRIDGE_GROUP_ADDRESS_DEF_BIN);
|
2020-08-20 09:40:17 -04:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (!nm_utils_hwaddr_aton(group_address, out_addr, ETH_ALEN))
|
|
|
|
|
nm_assert_not_reached();
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
static void
|
|
|
|
|
from_sysfs_group_address(const char *value, GValue *out)
|
|
|
|
|
{
|
2020-08-21 13:50:21 +02:00
|
|
|
if (!nm_utils_hwaddr_matches(value, -1, NM_BRIDGE_GROUP_ADDRESS_DEF_STR, -1))
|
2020-03-23 19:29:24 +01:00
|
|
|
g_value_set_string(out, value);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
|
to_sysfs_group_address(GValue *value)
|
|
|
|
|
{
|
2020-08-21 13:50:21 +02:00
|
|
|
return g_value_get_string(value) ?: NM_BRIDGE_GROUP_ADDRESS_DEF_STR;
|
2020-03-23 19:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
2020-08-20 09:40:17 -04:00
|
|
|
static int
|
|
|
|
|
to_sysfs_vlan_protocol_sys(const char *value)
|
|
|
|
|
{
|
|
|
|
|
if (nm_streq0(value, "802.1ad"))
|
|
|
|
|
return ETH_P_8021AD;
|
|
|
|
|
|
2020-08-21 13:50:21 +02:00
|
|
|
return ETH_P_8021Q;
|
2020-08-20 09:40:17 -04:00
|
|
|
}
|
|
|
|
|
|
2020-03-26 12:02:20 +01:00
|
|
|
static void
|
|
|
|
|
from_sysfs_vlan_protocol(const char *value, GValue *out)
|
|
|
|
|
{
|
|
|
|
|
switch (_nm_utils_ascii_str_to_uint64(value, 16, 0, G_MAXUINT, -1)) {
|
|
|
|
|
case ETH_P_8021Q:
|
|
|
|
|
/* default value */
|
|
|
|
|
break;
|
|
|
|
|
case ETH_P_8021AD:
|
|
|
|
|
g_value_set_string(out, "802.1ad");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
|
to_sysfs_vlan_protocol(GValue *value)
|
|
|
|
|
{
|
|
|
|
|
const char *str = g_value_get_string(value);
|
|
|
|
|
|
|
|
|
|
if (nm_streq0(str, "802.1ad")) {
|
|
|
|
|
G_STATIC_ASSERT_EXPR(ETH_P_8021AD == 0x88A8);
|
|
|
|
|
return "0x88A8";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
G_STATIC_ASSERT_EXPR(ETH_P_8021Q == 0x8100);
|
|
|
|
|
return "0x8100";
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-20 09:40:17 -04:00
|
|
|
static int
|
|
|
|
|
to_sysfs_multicast_router_sys(const char *value)
|
|
|
|
|
{
|
|
|
|
|
if (nm_streq0(value, "disabled"))
|
|
|
|
|
return 0;
|
|
|
|
|
if (nm_streq0(value, "auto"))
|
|
|
|
|
return 1;
|
|
|
|
|
if (nm_streq0(value, "enabled"))
|
|
|
|
|
return 2;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-08-20 09:40:17 -04:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-26 18:38:04 +01:00
|
|
|
static const char *
|
|
|
|
|
to_sysfs_multicast_router(GValue *value)
|
|
|
|
|
{
|
|
|
|
|
const char *str = g_value_get_string(value);
|
|
|
|
|
|
|
|
|
|
if (nm_streq0(str, "disabled"))
|
|
|
|
|
return "0";
|
|
|
|
|
if (nm_streq0(str, "auto"))
|
|
|
|
|
return "1";
|
|
|
|
|
if (nm_streq0(str, "enabled"))
|
|
|
|
|
return "2";
|
|
|
|
|
|
|
|
|
|
return "1";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
from_sysfs_multicast_router(const char *value, GValue *out)
|
|
|
|
|
{
|
|
|
|
|
switch (_nm_utils_ascii_str_to_uint64(value, 10, 0, G_MAXUINT, -1)) {
|
|
|
|
|
case 0:
|
|
|
|
|
g_value_set_string(out, "disabled");
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
g_value_set_string(out, "enabled");
|
|
|
|
|
break;
|
|
|
|
|
case 1:
|
|
|
|
|
default:
|
|
|
|
|
/* default value */
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2020-08-06 16:52:16 -04:00
|
|
|
#define _DEFAULT_IF_ZERO(val, def_val) \
|
|
|
|
|
({ \
|
|
|
|
|
typeof(val) _val = (val); \
|
|
|
|
|
typeof(val) _def_val = (def_val); \
|
|
|
|
|
\
|
|
|
|
|
(_val == 0) ? _def_val : _val; \
|
|
|
|
|
})
|
|
|
|
|
|
2013-08-23 23:02:31 +02:00
|
|
|
typedef struct {
|
|
|
|
|
const char *name;
|
|
|
|
|
const char *sysname;
|
2020-03-23 19:29:24 +01:00
|
|
|
const char *(*to_sysfs)(GValue *value);
|
|
|
|
|
void (*from_sysfs)(const char *value, GValue *out);
|
2020-04-21 17:35:51 +02:00
|
|
|
guint64 nm_min;
|
|
|
|
|
guint64 nm_max;
|
|
|
|
|
guint64 nm_default;
|
2019-01-03 14:53:02 +01:00
|
|
|
bool default_if_zero;
|
|
|
|
|
bool user_hz_compensate;
|
2019-01-03 12:02:41 +01:00
|
|
|
bool only_with_stp;
|
2013-08-23 23:02:31 +02:00
|
|
|
} Option;
|
|
|
|
|
|
2020-05-05 14:40:04 +02:00
|
|
|
#define OPTION(_name, _sysname, ...) \
|
|
|
|
|
{ \
|
2021-11-09 13:28:54 +01:00
|
|
|
.name = ""_name \
|
|
|
|
|
"", \
|
2020-05-05 14:40:04 +02:00
|
|
|
.sysname = ""_sysname \
|
|
|
|
|
"", \
|
|
|
|
|
__VA_ARGS__ \
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define OPTION_TYPE_INT(min, max, def) .nm_min = (min), .nm_max = (max), .nm_default = (def)
|
|
|
|
|
|
|
|
|
|
#define OPTION_TYPE_BOOL(def) OPTION_TYPE_INT(FALSE, TRUE, def)
|
|
|
|
|
|
|
|
|
|
#define OPTION_TYPE_TOFROM(to, fro) .to_sysfs = (to), .from_sysfs = (fro)
|
|
|
|
|
|
2013-08-23 23:02:31 +02:00
|
|
|
static const Option master_options[] = {
|
2020-05-05 14:40:04 +02:00
|
|
|
OPTION(NM_SETTING_BRIDGE_STP, /* this must stay as the first item */
|
|
|
|
|
"stp_state",
|
|
|
|
|
OPTION_TYPE_BOOL(NM_BRIDGE_STP_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_PRIORITY,
|
|
|
|
|
"priority",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_PRIORITY_MIN, NM_BRIDGE_PRIORITY_MAX, NM_BRIDGE_PRIORITY_DEF),
|
|
|
|
|
.default_if_zero = TRUE,
|
|
|
|
|
.only_with_stp = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_FORWARD_DELAY,
|
|
|
|
|
"forward_delay",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_FORWARD_DELAY_MIN,
|
|
|
|
|
NM_BRIDGE_FORWARD_DELAY_MAX,
|
|
|
|
|
NM_BRIDGE_FORWARD_DELAY_DEF),
|
|
|
|
|
.default_if_zero = TRUE,
|
|
|
|
|
.user_hz_compensate = TRUE,
|
|
|
|
|
.only_with_stp = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_HELLO_TIME,
|
|
|
|
|
"hello_time",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_HELLO_TIME_MIN,
|
|
|
|
|
NM_BRIDGE_HELLO_TIME_MAX,
|
|
|
|
|
NM_BRIDGE_HELLO_TIME_DEF),
|
|
|
|
|
.default_if_zero = TRUE,
|
|
|
|
|
.user_hz_compensate = TRUE,
|
|
|
|
|
.only_with_stp = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MAX_AGE,
|
|
|
|
|
"max_age",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MAX_AGE_MIN, NM_BRIDGE_MAX_AGE_MAX, NM_BRIDGE_MAX_AGE_DEF),
|
|
|
|
|
.default_if_zero = TRUE,
|
|
|
|
|
.user_hz_compensate = TRUE,
|
|
|
|
|
.only_with_stp = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_AGEING_TIME,
|
|
|
|
|
"ageing_time",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_AGEING_TIME_MIN,
|
|
|
|
|
NM_BRIDGE_AGEING_TIME_MAX,
|
|
|
|
|
NM_BRIDGE_AGEING_TIME_DEF),
|
|
|
|
|
.user_hz_compensate = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_GROUP_FORWARD_MASK, "group_fwd_mask", OPTION_TYPE_INT(0, 0xFFFF, 0), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_HASH_MAX,
|
|
|
|
|
"hash_max",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_HASH_MAX_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_HASH_MAX_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_HASH_MAX_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_LAST_MEMBER_COUNT,
|
|
|
|
|
"multicast_last_member_count",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_LAST_MEMBER_COUNT_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_LAST_MEMBER_COUNT_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_LAST_MEMBER_COUNT_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_LAST_MEMBER_INTERVAL,
|
|
|
|
|
"multicast_last_member_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_LAST_MEMBER_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_LAST_MEMBER_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_LAST_MEMBER_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_MEMBERSHIP_INTERVAL,
|
|
|
|
|
"multicast_membership_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_MEMBERSHIP_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_MEMBERSHIP_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_MEMBERSHIP_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_QUERIER,
|
|
|
|
|
"multicast_querier",
|
|
|
|
|
OPTION_TYPE_BOOL(NM_BRIDGE_MULTICAST_QUERIER_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_QUERIER_INTERVAL,
|
|
|
|
|
"multicast_querier_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_QUERIER_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERIER_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERIER_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_QUERY_INTERVAL,
|
|
|
|
|
"multicast_query_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_QUERY_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERY_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERY_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_QUERY_RESPONSE_INTERVAL,
|
|
|
|
|
"multicast_query_response_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_QUERY_RESPONSE_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERY_RESPONSE_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_QUERY_RESPONSE_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_QUERY_USE_IFADDR,
|
|
|
|
|
"multicast_query_use_ifaddr",
|
|
|
|
|
OPTION_TYPE_BOOL(NM_BRIDGE_MULTICAST_QUERY_USE_IFADDR_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_SNOOPING,
|
|
|
|
|
"multicast_snooping",
|
|
|
|
|
OPTION_TYPE_BOOL(NM_BRIDGE_MULTICAST_SNOOPING_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_ROUTER,
|
|
|
|
|
"multicast_router",
|
|
|
|
|
OPTION_TYPE_TOFROM(to_sysfs_multicast_router, from_sysfs_multicast_router), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_STARTUP_QUERY_COUNT,
|
|
|
|
|
"multicast_startup_query_count",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_STARTUP_QUERY_COUNT_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_STARTUP_QUERY_COUNT_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_STARTUP_QUERY_COUNT_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_MULTICAST_STARTUP_QUERY_INTERVAL,
|
|
|
|
|
"multicast_startup_query_interval",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_MULTICAST_STARTUP_QUERY_INTERVAL_MIN,
|
|
|
|
|
NM_BRIDGE_MULTICAST_STARTUP_QUERY_INTERVAL_MAX,
|
|
|
|
|
NM_BRIDGE_MULTICAST_STARTUP_QUERY_INTERVAL_DEF), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_GROUP_ADDRESS,
|
|
|
|
|
"group_addr",
|
|
|
|
|
OPTION_TYPE_TOFROM(to_sysfs_group_address, from_sysfs_group_address), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_VLAN_PROTOCOL,
|
|
|
|
|
"vlan_protocol",
|
|
|
|
|
OPTION_TYPE_TOFROM(to_sysfs_vlan_protocol, from_sysfs_vlan_protocol), ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_VLAN_STATS_ENABLED,
|
|
|
|
|
"vlan_stats_enabled",
|
|
|
|
|
OPTION_TYPE_BOOL(NM_BRIDGE_VLAN_STATS_ENABLED_DEF)),
|
|
|
|
|
{
|
|
|
|
|
0,
|
2013-08-23 23:02:31 +02:00
|
|
|
}};
|
|
|
|
|
|
|
|
|
|
static const Option slave_options[] = {
|
2020-05-05 14:40:04 +02:00
|
|
|
OPTION(NM_SETTING_BRIDGE_PORT_PRIORITY,
|
|
|
|
|
"priority",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_PORT_PRIORITY_MIN,
|
|
|
|
|
NM_BRIDGE_PORT_PRIORITY_MAX,
|
|
|
|
|
NM_BRIDGE_PORT_PRIORITY_DEF),
|
|
|
|
|
.default_if_zero = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_PORT_PATH_COST,
|
|
|
|
|
"path_cost",
|
|
|
|
|
OPTION_TYPE_INT(NM_BRIDGE_PORT_PATH_COST_MIN,
|
|
|
|
|
NM_BRIDGE_PORT_PATH_COST_MAX,
|
|
|
|
|
NM_BRIDGE_PORT_PATH_COST_DEF),
|
|
|
|
|
.default_if_zero = TRUE, ),
|
|
|
|
|
OPTION(NM_SETTING_BRIDGE_PORT_HAIRPIN_MODE, "hairpin_mode", OPTION_TYPE_BOOL(FALSE), ),
|
2013-08-23 23:02:31 +02:00
|
|
|
{0}};
|
|
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
static void
|
2013-10-11 18:25:20 +02:00
|
|
|
commit_option(NMDevice *device, NMSetting *setting, const Option *option, gboolean slave)
|
2012-10-29 19:02:45 -05:00
|
|
|
{
|
2013-08-23 23:02:31 +02:00
|
|
|
int ifindex = nm_device_get_ifindex(device);
|
2020-03-23 19:29:24 +01:00
|
|
|
nm_auto_unset_gvalue GValue val = G_VALUE_INIT;
|
2021-11-09 13:28:54 +01:00
|
|
|
GParamSpec *pspec;
|
|
|
|
|
const char *value;
|
2020-04-29 22:07:47 +02:00
|
|
|
char value_buf[100];
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-09 16:13:18 +02:00
|
|
|
if (slave)
|
|
|
|
|
nm_assert(NM_IS_SETTING_BRIDGE_PORT(setting));
|
|
|
|
|
else
|
|
|
|
|
nm_assert(NM_IS_SETTING_BRIDGE(setting));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2013-08-23 23:02:31 +02:00
|
|
|
pspec = g_object_class_find_property(G_OBJECT_GET_CLASS(setting), option->name);
|
2020-04-09 09:34:17 +02:00
|
|
|
nm_assert(pspec);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
g_value_init(&val, G_PARAM_SPEC_VALUE_TYPE(pspec));
|
2013-10-11 18:25:20 +02:00
|
|
|
g_object_get_property((GObject *) setting, option->name, &val);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
if (option->to_sysfs) {
|
2020-04-09 09:34:17 +02:00
|
|
|
value = option->to_sysfs(&val);
|
2020-03-23 19:29:24 +01:00
|
|
|
goto out;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
switch (pspec->value_type) {
|
2020-04-09 09:34:17 +02:00
|
|
|
case G_TYPE_BOOLEAN:
|
|
|
|
|
value = g_value_get_boolean(&val) ? "1" : "0";
|
|
|
|
|
break;
|
2020-04-21 17:35:51 +02:00
|
|
|
case G_TYPE_UINT64:
|
2020-04-09 09:34:17 +02:00
|
|
|
case G_TYPE_UINT:
|
|
|
|
|
{
|
2020-04-21 17:35:51 +02:00
|
|
|
guint64 uval;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-21 17:35:51 +02:00
|
|
|
if (pspec->value_type == G_TYPE_UINT64)
|
|
|
|
|
uval = g_value_get_uint64(&val);
|
|
|
|
|
else
|
|
|
|
|
uval = (guint) g_value_get_uint(&val);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-09 09:34:17 +02:00
|
|
|
/* zero means "unspecified" for some NM properties but isn't in the
|
|
|
|
|
* allowed kernel range, so reset the property to the default value.
|
|
|
|
|
*/
|
2020-04-29 20:40:00 +02:00
|
|
|
if (option->default_if_zero && uval == 0) {
|
2020-04-21 17:35:51 +02:00
|
|
|
if (pspec->value_type == G_TYPE_UINT64)
|
2020-04-29 20:40:00 +02:00
|
|
|
uval = NM_G_PARAM_SPEC_GET_DEFAULT_UINT64(pspec);
|
2020-04-21 17:35:51 +02:00
|
|
|
else
|
2020-04-29 20:40:00 +02:00
|
|
|
uval = NM_G_PARAM_SPEC_GET_DEFAULT_UINT(pspec);
|
2020-04-09 09:34:17 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-09 09:34:17 +02:00
|
|
|
/* Linux kernel bridge interfaces use 'centiseconds' for time-based values.
|
|
|
|
|
* In reality it's not centiseconds, but depends on HZ and USER_HZ, which
|
|
|
|
|
* is almost always works out to be a multiplier of 100, so we can assume
|
|
|
|
|
* centiseconds. See clock_t_to_jiffies().
|
|
|
|
|
*/
|
|
|
|
|
if (option->user_hz_compensate)
|
|
|
|
|
uval *= 100;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-21 17:35:51 +02:00
|
|
|
if (pspec->value_type == G_TYPE_UINT64)
|
|
|
|
|
nm_sprintf_buf(value_buf, "%" G_GUINT64_FORMAT, uval);
|
|
|
|
|
else
|
|
|
|
|
nm_sprintf_buf(value_buf, "%u", (guint) uval);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-09 09:34:17 +02:00
|
|
|
value = value_buf;
|
|
|
|
|
} break;
|
|
|
|
|
case G_TYPE_STRING:
|
|
|
|
|
value = g_value_get_string(&val);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
nm_assert_not_reached();
|
|
|
|
|
value = NULL;
|
|
|
|
|
break;
|
2020-03-23 19:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
if (!value)
|
|
|
|
|
return;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
if (slave) {
|
|
|
|
|
nm_platform_sysctl_slave_set_option(nm_device_get_platform(device),
|
|
|
|
|
ifindex,
|
|
|
|
|
option->sysname,
|
|
|
|
|
value);
|
|
|
|
|
} else {
|
|
|
|
|
nm_platform_sysctl_master_set_option(nm_device_get_platform(device),
|
|
|
|
|
ifindex,
|
|
|
|
|
option->sysname,
|
|
|
|
|
value);
|
|
|
|
|
}
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
2019-04-16 11:01:53 +02:00
|
|
|
static const NMPlatformBridgeVlan **
|
2019-03-16 17:22:57 +01:00
|
|
|
setting_vlans_to_platform(GPtrArray *array)
|
|
|
|
|
{
|
2019-04-16 11:01:53 +02:00
|
|
|
NMPlatformBridgeVlan **arr;
|
2021-11-09 13:28:54 +01:00
|
|
|
NMPlatformBridgeVlan *p_data;
|
2019-03-16 17:22:57 +01:00
|
|
|
guint i;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
if (!array || !array->len)
|
|
|
|
|
return NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-04-16 11:01:53 +02:00
|
|
|
G_STATIC_ASSERT_EXPR(_nm_alignof(NMPlatformBridgeVlan *) >= _nm_alignof(NMPlatformBridgeVlan));
|
|
|
|
|
arr = g_malloc((sizeof(NMPlatformBridgeVlan *) * (array->len + 1))
|
|
|
|
|
+ (sizeof(NMPlatformBridgeVlan) * (array->len)));
|
|
|
|
|
p_data = (NMPlatformBridgeVlan *) &arr[array->len + 1];
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
for (i = 0; i < array->len; i++) {
|
|
|
|
|
NMBridgeVlan *vlan = array->pdata[i];
|
2019-04-15 15:14:33 +02:00
|
|
|
guint16 vid_start, vid_end;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-04-15 15:14:33 +02:00
|
|
|
nm_bridge_vlan_get_vid_range(vlan, &vid_start, &vid_end);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-04-16 11:01:53 +02:00
|
|
|
p_data[i] = (NMPlatformBridgeVlan){
|
|
|
|
|
.vid_start = vid_start,
|
|
|
|
|
.vid_end = vid_end,
|
|
|
|
|
.pvid = nm_bridge_vlan_is_pvid(vlan),
|
|
|
|
|
.untagged = nm_bridge_vlan_is_untagged(vlan),
|
|
|
|
|
};
|
|
|
|
|
arr[i] = &p_data[i];
|
2019-03-16 17:22:57 +01:00
|
|
|
}
|
2019-04-16 11:01:53 +02:00
|
|
|
arr[i] = NULL;
|
|
|
|
|
return (const NMPlatformBridgeVlan **) arr;
|
2019-03-16 17:22:57 +01:00
|
|
|
}
|
|
|
|
|
|
2013-08-23 23:02:31 +02:00
|
|
|
static void
|
2013-10-11 18:25:20 +02:00
|
|
|
commit_slave_options(NMDevice *device, NMSettingBridgePort *setting)
|
2013-08-23 23:02:31 +02:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
const Option *option;
|
|
|
|
|
NMSetting *s;
|
2019-03-16 17:22:57 +01:00
|
|
|
gs_unref_object NMSetting *s_clear = NULL;
|
2013-08-23 23:02:31 +02:00
|
|
|
|
2013-10-11 18:25:20 +02:00
|
|
|
if (setting)
|
|
|
|
|
s = NM_SETTING(setting);
|
|
|
|
|
else
|
|
|
|
|
s = s_clear = nm_setting_bridge_port_new();
|
2013-08-23 23:02:31 +02:00
|
|
|
|
|
|
|
|
for (option = slave_options; option->name; option++)
|
2013-10-11 18:25:20 +02:00
|
|
|
commit_option(device, s, option, TRUE);
|
2013-08-23 23:02:31 +02:00
|
|
|
}
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2013-08-23 23:02:54 +02:00
|
|
|
static void
|
|
|
|
|
update_connection(NMDevice *device, NMConnection *connection)
|
|
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
2021-08-20 18:40:21 +08:00
|
|
|
NMSettingBridge *s_bridge = _nm_connection_ensure_setting(connection, NM_TYPE_SETTING_BRIDGE);
|
2013-08-23 23:02:54 +02:00
|
|
|
int ifindex = nm_device_get_ifindex(device);
|
2021-11-09 13:28:54 +01:00
|
|
|
const Option *option;
|
|
|
|
|
gs_free char *stp = NULL;
|
2019-01-03 12:02:41 +01:00
|
|
|
int stp_value;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-03 12:02:41 +01:00
|
|
|
option = master_options;
|
|
|
|
|
nm_assert(nm_streq(option->sysname, "stp_state"));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-03 12:02:41 +01:00
|
|
|
stp = nm_platform_sysctl_master_get_option(nm_device_get_platform(device),
|
|
|
|
|
ifindex,
|
|
|
|
|
option->sysname);
|
|
|
|
|
stp_value =
|
|
|
|
|
_nm_utils_ascii_str_to_int64(stp, 10, option->nm_min, option->nm_max, option->nm_default);
|
|
|
|
|
g_object_set(s_bridge, option->name, stp_value, NULL);
|
|
|
|
|
option++;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-03 12:02:41 +01:00
|
|
|
for (; option->name; option++) {
|
2020-03-23 19:29:24 +01:00
|
|
|
nm_auto_unset_gvalue GValue value = G_VALUE_INIT;
|
2021-11-09 13:28:54 +01:00
|
|
|
gs_free char *str = NULL;
|
|
|
|
|
GParamSpec *pspec;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
str = nm_platform_sysctl_master_get_option(nm_device_get_platform(device),
|
|
|
|
|
ifindex,
|
|
|
|
|
option->sysname);
|
|
|
|
|
pspec = g_object_class_find_property(G_OBJECT_GET_CLASS(s_bridge), option->name);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-03 12:02:41 +01:00
|
|
|
if (!stp_value && option->only_with_stp)
|
|
|
|
|
continue;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
if (!str) {
|
2014-08-02 15:14:26 +02:00
|
|
|
_LOGW(LOGD_BRIDGE, "failed to read bridge setting '%s'", option->sysname);
|
2020-03-23 19:29:24 +01:00
|
|
|
continue;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
g_value_init(&value, G_PARAM_SPEC_VALUE_TYPE(pspec));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
if (option->from_sysfs) {
|
2020-04-09 09:34:17 +02:00
|
|
|
option->from_sysfs(str, &value);
|
2020-03-23 19:29:24 +01:00
|
|
|
goto out;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
switch (pspec->value_type) {
|
2020-04-21 17:35:51 +02:00
|
|
|
case G_TYPE_UINT64:
|
2020-03-23 19:29:24 +01:00
|
|
|
case G_TYPE_UINT:
|
|
|
|
|
{
|
2020-04-21 17:35:51 +02:00
|
|
|
guint64 uvalue;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
/* See comments in set_sysfs_uint() about centiseconds. */
|
|
|
|
|
if (option->user_hz_compensate) {
|
|
|
|
|
uvalue = _nm_utils_ascii_str_to_int64(str,
|
|
|
|
|
10,
|
|
|
|
|
option->nm_min * 100,
|
|
|
|
|
option->nm_max * 100,
|
|
|
|
|
option->nm_default * 100);
|
|
|
|
|
uvalue /= 100;
|
|
|
|
|
} else {
|
2020-04-21 17:35:51 +02:00
|
|
|
uvalue = _nm_utils_ascii_str_to_uint64(str,
|
|
|
|
|
10,
|
|
|
|
|
option->nm_min,
|
|
|
|
|
option->nm_max,
|
|
|
|
|
option->nm_default);
|
2020-03-23 19:29:24 +01:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-21 17:35:51 +02:00
|
|
|
if (pspec->value_type == G_TYPE_UINT64)
|
|
|
|
|
g_value_set_uint64(&value, uvalue);
|
|
|
|
|
else
|
|
|
|
|
g_value_set_uint(&value, (guint) uvalue);
|
2020-03-23 19:29:24 +01:00
|
|
|
} break;
|
|
|
|
|
case G_TYPE_BOOLEAN:
|
|
|
|
|
{
|
|
|
|
|
gboolean bvalue;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-03-23 19:29:24 +01:00
|
|
|
bvalue = _nm_utils_ascii_str_to_int64(str,
|
|
|
|
|
10,
|
|
|
|
|
option->nm_min,
|
|
|
|
|
option->nm_max,
|
|
|
|
|
option->nm_default);
|
|
|
|
|
g_value_set_boolean(&value, bvalue);
|
|
|
|
|
} break;
|
|
|
|
|
case G_TYPE_STRING:
|
|
|
|
|
g_value_set_string(&value, str);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2020-04-09 09:34:17 +02:00
|
|
|
nm_assert_not_reached();
|
2020-03-23 19:29:24 +01:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
g_object_set_property(G_OBJECT(s_bridge), option->name, &value);
|
2013-08-23 23:02:54 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-18 20:17:57 +02:00
|
|
|
static gboolean
|
2021-11-09 13:28:54 +01:00
|
|
|
master_update_slave_connection(NMDevice *device,
|
|
|
|
|
NMDevice *slave,
|
2014-06-18 20:17:57 +02:00
|
|
|
NMConnection *connection,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error)
|
2013-08-22 20:41:01 +02:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
2014-06-18 20:17:57 +02:00
|
|
|
NMSettingConnection *s_con;
|
2013-08-22 20:41:01 +02:00
|
|
|
NMSettingBridgePort *s_port;
|
2014-06-18 20:17:57 +02:00
|
|
|
int ifindex_slave = nm_device_get_ifindex(slave);
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *iface = nm_device_get_iface(device);
|
|
|
|
|
const Option *option;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-06-18 20:17:57 +02:00
|
|
|
g_return_val_if_fail(ifindex_slave > 0, FALSE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-06-18 20:17:57 +02:00
|
|
|
s_con = nm_connection_get_setting_connection(connection);
|
2021-08-20 18:40:21 +08:00
|
|
|
s_port = _nm_connection_ensure_setting(connection, NM_TYPE_SETTING_BRIDGE_PORT);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2013-08-22 20:41:01 +02:00
|
|
|
for (option = slave_options; option->name; option++) {
|
2017-04-18 12:09:02 +02:00
|
|
|
gs_free char *str = nm_platform_sysctl_slave_get_option(nm_device_get_platform(device),
|
|
|
|
|
ifindex_slave,
|
|
|
|
|
option->sysname);
|
2019-01-03 11:40:13 +01:00
|
|
|
uint value;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2013-08-22 20:41:01 +02:00
|
|
|
if (str) {
|
|
|
|
|
/* See comments in set_sysfs_uint() about centiseconds. */
|
2019-01-03 11:40:13 +01:00
|
|
|
if (option->user_hz_compensate) {
|
|
|
|
|
value = _nm_utils_ascii_str_to_int64(str,
|
|
|
|
|
10,
|
|
|
|
|
option->nm_min * 100,
|
|
|
|
|
option->nm_max * 100,
|
|
|
|
|
option->nm_default * 100);
|
2013-08-22 20:41:01 +02:00
|
|
|
value /= 100;
|
2019-01-03 11:40:13 +01:00
|
|
|
} else {
|
|
|
|
|
value = _nm_utils_ascii_str_to_int64(str,
|
|
|
|
|
10,
|
|
|
|
|
option->nm_min,
|
|
|
|
|
option->nm_max,
|
|
|
|
|
option->nm_default);
|
|
|
|
|
}
|
2013-08-22 20:41:01 +02:00
|
|
|
g_object_set(s_port, option->name, value, NULL);
|
2014-08-02 15:14:26 +02:00
|
|
|
} else
|
|
|
|
|
_LOGW(LOGD_BRIDGE, "failed to read bridge port setting '%s'", option->sysname);
|
2013-08-22 20:41:01 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-06-18 20:17:57 +02:00
|
|
|
g_object_set(s_con,
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER,
|
|
|
|
|
iface,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE,
|
|
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
|
NULL);
|
2013-08-22 20:41:01 +02:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
static gboolean
|
|
|
|
|
bridge_set_vlan_options(NMDevice *device, NMSettingBridge *s_bridge)
|
|
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
gconstpointer hwaddr;
|
|
|
|
|
size_t length;
|
|
|
|
|
gboolean enabled;
|
|
|
|
|
guint16 pvid;
|
|
|
|
|
NMPlatform *plat;
|
|
|
|
|
int ifindex;
|
|
|
|
|
gs_unref_ptrarray GPtrArray *vlans = NULL;
|
2019-04-16 11:01:53 +02:00
|
|
|
gs_free const NMPlatformBridgeVlan **plat_vlans = NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
if (self->vlan_configured)
|
|
|
|
|
return TRUE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
plat = nm_device_get_platform(device);
|
|
|
|
|
ifindex = nm_device_get_ifindex(device);
|
|
|
|
|
enabled = nm_setting_bridge_get_vlan_filtering(s_bridge);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
if (!enabled) {
|
|
|
|
|
nm_platform_sysctl_master_set_option(plat, ifindex, "vlan_filtering", "0");
|
|
|
|
|
nm_platform_sysctl_master_set_option(plat, ifindex, "default_pvid", "1");
|
2019-03-16 17:22:57 +01:00
|
|
|
nm_platform_link_set_bridge_vlans(plat, ifindex, FALSE, NULL);
|
2019-03-15 08:53:37 +01:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
hwaddr = nm_platform_link_get_address(plat, ifindex, &length);
|
|
|
|
|
g_return_val_if_fail(length == ETH_ALEN, FALSE);
|
2020-10-01 13:27:07 +02:00
|
|
|
if (nm_utils_hwaddr_matches(hwaddr, length, &nm_ether_addr_zero, ETH_ALEN)) {
|
2019-03-15 08:53:37 +01:00
|
|
|
/* We need a non-zero MAC address to set the default pvid.
|
|
|
|
|
* Retry later. */
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self->vlan_configured = TRUE;
|
|
|
|
|
|
|
|
|
|
/* Filtering must be disabled to change the default PVID */
|
|
|
|
|
if (!nm_platform_sysctl_master_set_option(plat, ifindex, "vlan_filtering", "0"))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
/* Clear the default PVID so that we later can force the re-creation of
|
|
|
|
|
* default PVID VLANs by writing the option again. */
|
|
|
|
|
if (!nm_platform_sysctl_master_set_option(plat, ifindex, "default_pvid", "0"))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
/* Clear all existing VLANs */
|
|
|
|
|
if (!nm_platform_link_set_bridge_vlans(plat, ifindex, FALSE, NULL))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
/* Now set the default PVID. After this point the kernel creates
|
|
|
|
|
* a PVID VLAN on each port, including the bridge itself. */
|
|
|
|
|
pvid = nm_setting_bridge_get_vlan_default_pvid(s_bridge);
|
|
|
|
|
if (pvid) {
|
|
|
|
|
char value[32];
|
|
|
|
|
|
|
|
|
|
nm_sprintf_buf(value, "%u", pvid);
|
|
|
|
|
if (!nm_platform_sysctl_master_set_option(plat, ifindex, "default_pvid", value))
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
/* Create VLANs only after setting the default PVID, so that
|
|
|
|
|
* any PVID VLAN overrides the bridge's default PVID. */
|
|
|
|
|
g_object_get(s_bridge, NM_SETTING_BRIDGE_VLANS, &vlans, NULL);
|
|
|
|
|
plat_vlans = setting_vlans_to_platform(vlans);
|
2019-04-16 11:01:53 +02:00
|
|
|
if (plat_vlans && !nm_platform_link_set_bridge_vlans(plat, ifindex, FALSE, plat_vlans))
|
2019-03-16 17:22:57 +01:00
|
|
|
return FALSE;
|
|
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
if (!nm_platform_sysctl_master_set_option(plat, ifindex, "vlan_filtering", "1"))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-28 10:57:05 +01:00
|
|
|
static void
|
|
|
|
|
_platform_lnk_bridge_init_from_setting(NMSettingBridge *s_bridge, NMPlatformLnkBridge *props)
|
|
|
|
|
{
|
|
|
|
|
*props = (NMPlatformLnkBridge){
|
|
|
|
|
.forward_delay = _DEFAULT_IF_ZERO(nm_setting_bridge_get_forward_delay(s_bridge) * 100u,
|
|
|
|
|
NM_BRIDGE_FORWARD_DELAY_DEF_SYS),
|
|
|
|
|
.hello_time = _DEFAULT_IF_ZERO(nm_setting_bridge_get_hello_time(s_bridge) * 100u,
|
|
|
|
|
NM_BRIDGE_HELLO_TIME_DEF_SYS),
|
|
|
|
|
.max_age = _DEFAULT_IF_ZERO(nm_setting_bridge_get_max_age(s_bridge) * 100u,
|
|
|
|
|
NM_BRIDGE_MAX_AGE_DEF_SYS),
|
|
|
|
|
.ageing_time = nm_setting_bridge_get_ageing_time(s_bridge) * 100u,
|
|
|
|
|
.stp_state = nm_setting_bridge_get_stp(s_bridge),
|
|
|
|
|
.priority = nm_setting_bridge_get_priority(s_bridge),
|
|
|
|
|
.vlan_protocol = to_sysfs_vlan_protocol_sys(nm_setting_bridge_get_vlan_protocol(s_bridge)),
|
|
|
|
|
.vlan_stats_enabled = nm_setting_bridge_get_vlan_stats_enabled(s_bridge),
|
|
|
|
|
.group_fwd_mask = nm_setting_bridge_get_group_forward_mask(s_bridge),
|
|
|
|
|
.mcast_snooping = nm_setting_bridge_get_multicast_snooping(s_bridge),
|
|
|
|
|
.mcast_router =
|
|
|
|
|
to_sysfs_multicast_router_sys(nm_setting_bridge_get_multicast_router(s_bridge)),
|
|
|
|
|
.mcast_query_use_ifaddr = nm_setting_bridge_get_multicast_query_use_ifaddr(s_bridge),
|
|
|
|
|
.mcast_querier = nm_setting_bridge_get_multicast_querier(s_bridge),
|
|
|
|
|
.mcast_hash_max = nm_setting_bridge_get_multicast_hash_max(s_bridge),
|
|
|
|
|
.mcast_last_member_count = nm_setting_bridge_get_multicast_last_member_count(s_bridge),
|
|
|
|
|
.mcast_startup_query_count = nm_setting_bridge_get_multicast_startup_query_count(s_bridge),
|
|
|
|
|
.mcast_last_member_interval =
|
|
|
|
|
nm_setting_bridge_get_multicast_last_member_interval(s_bridge),
|
|
|
|
|
.mcast_membership_interval = nm_setting_bridge_get_multicast_membership_interval(s_bridge),
|
|
|
|
|
.mcast_querier_interval = nm_setting_bridge_get_multicast_querier_interval(s_bridge),
|
|
|
|
|
.mcast_query_interval = nm_setting_bridge_get_multicast_query_interval(s_bridge),
|
|
|
|
|
.mcast_query_response_interval =
|
|
|
|
|
nm_setting_bridge_get_multicast_query_response_interval(s_bridge),
|
|
|
|
|
.mcast_startup_query_interval =
|
|
|
|
|
nm_setting_bridge_get_multicast_startup_query_interval(s_bridge),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
to_sysfs_group_address_sys(nm_setting_bridge_get_group_address(s_bridge), &props->group_addr);
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-13 17:07:18 +02:00
|
|
|
static gboolean
|
|
|
|
|
link_config(NMDevice *device, NMConnection *connection)
|
2013-08-23 23:02:31 +02:00
|
|
|
{
|
2022-07-13 17:07:18 +02:00
|
|
|
int ifindex = nm_device_get_ifindex(device);
|
2022-03-16 11:33:39 +01:00
|
|
|
NMSettingBridge *s_bridge;
|
|
|
|
|
NMPlatformLnkBridge props;
|
2019-08-21 17:05:20 +02:00
|
|
|
|
2022-03-16 11:33:39 +01:00
|
|
|
s_bridge = nm_connection_get_setting_bridge(connection);
|
2022-07-13 17:07:18 +02:00
|
|
|
g_return_val_if_fail(s_bridge, FALSE);
|
2019-03-15 08:53:37 +01:00
|
|
|
|
2022-03-16 11:33:39 +01:00
|
|
|
_platform_lnk_bridge_init_from_setting(s_bridge, &props);
|
2016-10-21 14:40:37 +02:00
|
|
|
|
2022-07-13 17:07:18 +02:00
|
|
|
if (nm_platform_link_bridge_change(nm_device_get_platform(device), ifindex, &props) < 0)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
return bridge_set_vlan_options(device, s_bridge);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static NMActStageReturn
|
|
|
|
|
act_stage1_prepare(NMDevice *device, NMDeviceStateReason *out_failure_reason)
|
|
|
|
|
{
|
|
|
|
|
NMConnection *connection;
|
2022-03-16 11:33:39 +01:00
|
|
|
|
2022-07-13 17:07:18 +02:00
|
|
|
connection = nm_device_get_applied_connection(device);
|
|
|
|
|
g_return_val_if_fail(connection, NM_ACT_STAGE_RETURN_FAILURE);
|
|
|
|
|
|
|
|
|
|
if (!link_config(device, connection)) {
|
2019-03-15 08:53:37 +01:00
|
|
|
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
|
|
|
|
|
return NM_ACT_STAGE_RETURN_FAILURE;
|
|
|
|
|
}
|
2013-08-23 23:02:31 +02:00
|
|
|
|
|
|
|
|
return NM_ACT_STAGE_RETURN_SUCCESS;
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
static void
|
|
|
|
|
_bt_register_bridge_cb(GError *error, gpointer user_data)
|
|
|
|
|
{
|
|
|
|
|
NMDeviceBridge *self;
|
|
|
|
|
|
2020-01-23 10:36:24 +01:00
|
|
|
if (nm_utils_error_is_cancelled(error))
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
self = user_data;
|
|
|
|
|
|
|
|
|
|
g_clear_object(&self->bt_cancellable);
|
|
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
|
_LOGD(LOGD_DEVICE, "bluetooth NAP server failed to register bridge: %s", error->message);
|
|
|
|
|
nm_device_state_changed(NM_DEVICE(self),
|
|
|
|
|
NM_DEVICE_STATE_FAILED,
|
|
|
|
|
NM_DEVICE_STATE_REASON_BT_FAILED);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
self->bt_cb_state = _NM_BT_CB_STATE_SUCCESS;
|
2020-02-28 16:11:19 +01:00
|
|
|
nm_device_activate_schedule_stage2_device_config(NM_DEVICE(self), FALSE);
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
_nm_device_bridge_notify_unregister_bt_nap(NMDevice *device, const char *reason)
|
|
|
|
|
{
|
|
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
|
|
|
|
|
_LOGD(LOGD_DEVICE,
|
|
|
|
|
"bluetooth NAP server unregistered from bridge: %s%s",
|
|
|
|
|
reason,
|
2022-04-05 22:41:51 +02:00
|
|
|
self->bt_cb_state != _NM_BT_CB_STATE_NONE ? "" : " (was no longer registered)");
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
|
|
|
|
|
nm_clear_g_cancellable(&self->bt_cancellable);
|
|
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
if (self->bt_cb_state != _NM_BT_CB_STATE_NONE) {
|
|
|
|
|
self->bt_cb_state = _NM_BT_CB_STATE_NONE;
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
nm_device_state_changed(device, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_BT_FAILED);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-01 11:57:42 +02:00
|
|
|
static NMActStageReturn
|
|
|
|
|
act_stage2_config(NMDevice *device, NMDeviceStateReason *out_failure_reason)
|
|
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
NMConnection *connection;
|
|
|
|
|
NMSettingBluetooth *s_bt;
|
2020-02-27 16:45:16 +01:00
|
|
|
gs_free_error GError *error = NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-06-03 13:31:46 +02:00
|
|
|
connection = nm_device_get_applied_connection(device);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-06-03 13:31:46 +02:00
|
|
|
s_bt = _nm_connection_get_setting_bluetooth_for_nap(connection);
|
2020-02-27 16:45:16 +01:00
|
|
|
if (!s_bt)
|
|
|
|
|
return NM_ACT_STAGE_RETURN_SUCCESS;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-27 16:45:16 +01:00
|
|
|
if (!nm_bt_vtable_network_server) {
|
|
|
|
|
_LOGD(LOGD_DEVICE, "bluetooth NAP server failed because bluetooth plugin not available");
|
|
|
|
|
*out_failure_reason = NM_DEVICE_STATE_REASON_BT_FAILED;
|
|
|
|
|
return NM_ACT_STAGE_RETURN_FAILURE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-27 16:45:16 +01:00
|
|
|
if (self->bt_cancellable)
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
return NM_ACT_STAGE_RETURN_POSTPONE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
if (self->bt_cb_state == _NM_BT_CB_STATE_WAIT)
|
2020-02-28 16:11:19 +01:00
|
|
|
return NM_ACT_STAGE_RETURN_POSTPONE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
if (self->bt_cb_state == _NM_BT_CB_STATE_SUCCESS)
|
|
|
|
|
return NM_ACT_STAGE_RETURN_SUCCESS;
|
|
|
|
|
|
2020-02-27 16:45:16 +01:00
|
|
|
self->bt_cancellable = g_cancellable_new();
|
|
|
|
|
if (!nm_bt_vtable_network_server->register_bridge(nm_bt_vtable_network_server,
|
|
|
|
|
nm_setting_bluetooth_get_bdaddr(s_bt),
|
|
|
|
|
device,
|
|
|
|
|
self->bt_cancellable,
|
|
|
|
|
_bt_register_bridge_cb,
|
|
|
|
|
device,
|
|
|
|
|
&error)) {
|
|
|
|
|
_LOGD(LOGD_DEVICE, "bluetooth NAP server failed to register bridge: %s", error->message);
|
|
|
|
|
*out_failure_reason = NM_DEVICE_STATE_REASON_BT_FAILED;
|
|
|
|
|
return NM_ACT_STAGE_RETURN_FAILURE;
|
2017-06-01 11:57:42 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
self->bt_cb_state = _NM_BT_CB_STATE_WAIT;
|
2020-02-27 16:45:16 +01:00
|
|
|
return NM_ACT_STAGE_RETURN_POSTPONE;
|
2017-06-01 11:57:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
deactivate(NMDevice *device)
|
|
|
|
|
{
|
2019-08-21 17:05:20 +02:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
_LOGD(LOGD_DEVICE,
|
|
|
|
|
"deactivate bridge%s",
|
2022-04-05 22:41:51 +02:00
|
|
|
self->bt_cb_state != _NM_BT_CB_STATE_NONE ? " (registered as NAP bluetooth device)" : "");
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
|
2019-08-21 17:05:20 +02:00
|
|
|
self->vlan_configured = FALSE;
|
|
|
|
|
|
bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data
This is a complete refactoring of the bluetooth code.
Now that BlueZ 4 support was dropped, the separation of NMBluezManager
and NMBluez5Manager makes no sense. They should be merged.
At that point, notice that BlueZ 5's D-Bus API is fully centered around
D-Bus's ObjectManager interface. Using that interface, we basically only
call GetManagedObjects() once and register to InterfacesAdded,
InterfacesRemoved and PropertiesChanged signals. There is no need to
fetch individual properties ever.
Note how NMBluezDevice used to query the D-Bus properties itself by
creating a GDBusProxy. This is redundant, because when using the ObjectManager
interfaces, we have all information already.
Instead, let NMBluezManager basically become the client-side cache of
all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
about caching the D-Bus interface's state, tracking suitable profiles
(pan_connection), and moderate between bluez and NMDeviceBt.
These tasks don't get simpler by moving them to a seprate file. Let them
also be handled by NMBluezManager.
I mean, just look how it was previously: NMBluez5Manager registers to
ObjectManager interface and sees a device appearing. It creates a
NMBluezDevice object and registers to its "initialized" and
"notify:usable" signal. In the meantime, NMBluezDevice fetches the
relevant information from D-Bus (although it was already present in the
data provided by the ObjectManager) and eventually emits these usable
and initialized signals.
Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
NMBluezDevice are strongly cooperating to the point that it is simpler
to merge them.
This is not mere refactoring. This patch aims to make everything
asynchronously and always cancellable. Also, it aims to fix races
and inconsistencies of the state.
- Registering to a NAP server now waits for the response and delays
activation of the NMDeviceBridge accordingly.
- For NAP connections we now watch the bnep0 interface in platform, and tear
down the device when it goes away. Bluez doesn't send us a notification
on D-Bus in that case.
- Rework establishing a DUN connection. It no longer uses blocking
connect() and does not block until rfcomm device appears. It's
all async now. It also watches the rfcomm file descriptor for
POLLERR/POLLHUP to notice disconnect.
- drop nm_device_factory_emit_component_added() and instead let
NMDeviceBt directly register to the WWan factory's "added" signal.
2019-08-11 10:43:53 +02:00
|
|
|
nm_clear_g_cancellable(&self->bt_cancellable);
|
|
|
|
|
|
2022-04-05 22:41:51 +02:00
|
|
|
if (self->bt_cb_state != _NM_BT_CB_STATE_NONE) {
|
|
|
|
|
self->bt_cb_state = _NM_BT_CB_STATE_NONE;
|
2017-06-03 13:31:46 +02:00
|
|
|
nm_bt_vtable_network_server->unregister_bridge(nm_bt_vtable_network_server, device);
|
|
|
|
|
}
|
2017-06-01 11:57:42 +02:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 16:27:24 +02:00
|
|
|
static NMTernary
|
|
|
|
|
attach_port(NMDevice *device,
|
|
|
|
|
NMDevice *port,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
gboolean configure,
|
|
|
|
|
GCancellable *cancellable,
|
|
|
|
|
NMDeviceAttachPortCallback callback,
|
|
|
|
|
gpointer user_data)
|
2012-10-29 19:02:45 -05:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
NMConnection *master_connection;
|
|
|
|
|
NMSettingBridge *s_bridge;
|
2019-03-15 08:53:37 +01:00
|
|
|
NMSettingBridgePort *s_port;
|
2014-08-02 15:14:26 +02:00
|
|
|
|
2013-11-07 01:08:02 -06:00
|
|
|
if (configure) {
|
2017-04-18 12:09:02 +02:00
|
|
|
if (!nm_platform_link_enslave(nm_device_get_platform(device),
|
|
|
|
|
nm_device_get_ip_ifindex(device),
|
2022-05-02 13:58:04 +02:00
|
|
|
nm_device_get_ip_ifindex(port)))
|
2013-11-07 01:08:02 -06:00
|
|
|
return FALSE;
|
2012-11-14 14:05:30 -06:00
|
|
|
|
2019-03-15 08:53:37 +01:00
|
|
|
master_connection = nm_device_get_applied_connection(device);
|
|
|
|
|
nm_assert(master_connection);
|
|
|
|
|
s_bridge = nm_connection_get_setting_bridge(master_connection);
|
|
|
|
|
nm_assert(s_bridge);
|
|
|
|
|
s_port = nm_connection_get_setting_bridge_port(connection);
|
|
|
|
|
|
2022-07-19 17:58:27 +02:00
|
|
|
if (!nm_device_sys_iface_state_is_external(device))
|
|
|
|
|
bridge_set_vlan_options(device, s_bridge);
|
2019-03-16 17:22:57 +01:00
|
|
|
|
|
|
|
|
if (nm_setting_bridge_get_vlan_filtering(s_bridge)) {
|
2019-04-16 11:01:53 +02:00
|
|
|
gs_free const NMPlatformBridgeVlan **plat_vlans = NULL;
|
2021-11-09 13:28:54 +01:00
|
|
|
gs_unref_ptrarray GPtrArray *vlans = NULL;
|
2019-04-16 11:01:53 +02:00
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
if (s_port)
|
|
|
|
|
g_object_get(s_port, NM_SETTING_BRIDGE_PORT_VLANS, &vlans, NULL);
|
2019-04-16 11:01:53 +02:00
|
|
|
|
2019-03-16 17:22:57 +01:00
|
|
|
plat_vlans = setting_vlans_to_platform(vlans);
|
|
|
|
|
|
|
|
|
|
/* Since the link was just enslaved, there are no existing VLANs
|
|
|
|
|
* (except for the default one) and so there's no need to flush. */
|
|
|
|
|
|
|
|
|
|
if (plat_vlans
|
2022-05-02 13:58:04 +02:00
|
|
|
&& !nm_platform_link_set_bridge_vlans(nm_device_get_platform(port),
|
|
|
|
|
nm_device_get_ifindex(port),
|
2019-03-16 17:22:57 +01:00
|
|
|
TRUE,
|
2019-04-16 11:01:53 +02:00
|
|
|
plat_vlans))
|
2019-03-16 17:22:57 +01:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-02 13:58:04 +02:00
|
|
|
commit_slave_options(port, s_port);
|
2014-02-25 16:44:01 -05:00
|
|
|
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGI(LOGD_BRIDGE, "attached bridge port %s", nm_device_get_ip_iface(port));
|
2014-02-25 16:44:01 -05:00
|
|
|
} else {
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGI(LOGD_BRIDGE, "bridge port %s was attached", nm_device_get_ip_iface(port));
|
2013-11-07 01:08:02 -06:00
|
|
|
}
|
2012-11-14 14:05:30 -06:00
|
|
|
|
|
|
|
|
return TRUE;
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
2015-12-02 09:56:17 +01:00
|
|
|
static void
|
2022-05-02 13:58:04 +02:00
|
|
|
detach_port(NMDevice *device, NMDevice *port, gboolean configure)
|
2012-10-29 19:02:45 -05:00
|
|
|
{
|
2014-08-02 15:14:26 +02:00
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
2015-12-02 09:56:17 +01:00
|
|
|
gboolean success;
|
device: fix crash releasing destroyed slave
I encountered this on a WIP branch, but I think it can happen
under regular conditions. I think there is no error condition here,
and we should do nothing if we have no ifindex.
<debug> [1561653068.2192] platform: signal: link removed: 1699: test1p <DOWN;broadcast,multicast> mtu 1500 master 1698 arp 1 veth* init addrgenmode none addr D6:14:45:97:06:75 brd FF:FF:FF:FF:FF:FF driver veth rx:0,0 tx:38,5606
...
<info> [1561653068.2617] device (test1): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
...
<trace> [1561653068.2635] device[0x564058c73750] (test1p): sys-iface-state: external -> removed
<debug> [1561653068.2635] device[0x564058c73750] (test1p): unrealize (ifindex 1699)
<debug> [1561653068.2636] device[0x564058c73750] (test1p): parent: clear
<trace> [1561653068.2636] device[0x564058b98eb0] (vethbr): mtu: commit-mtu...
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!by-type,!user-explicit,!user-settings,!user-udev,!is-slave=0x10/0x1479/unmanaged/unrealized], set-unmanaged [platform-init=0x10])
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!user-settings=0x10/0x51/unmanaged/unrealized], forget [parent,by-type,user-explicit,user-udev,external-down,is-slave=0x1c2c])
<info> [1561653068.2639] device (test1p): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
<debug> [1561653068.2640] device[0x564058c73750] (test1p): deactivating device (reason 'unmanaged') [3]
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip4-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip6-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'dhcp6' not pending (expected)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'autoconf6' not pending (expected)
<debug> [1561653068.2640] rules-manager: sync
<debug> [1561653068.2640] device[0x564058c73750] (test1p): set metered value 0
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip4-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip6-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2644] device[0x564058b98eb0] (vethbr): slave test1p state change 100 (activated) -> 10 (unmanaged)
<trace> [1561653068.2644] device[0x564058b98eb0] (vethbr): master: release one slave 0x564058c73750/test1p
((src/platform/nm-platform.c:2002)): assertion '<dropped>' failed
backtrace:
...
#3 0x0000564057fb713e _nm_g_return_if_fail_warning (NetworkManager)
#4 0x000056405808b37c release_slave (NetworkManager)
#5 0x0000564058079aef nm_device_master_release_one_slave (NetworkManager)
#6 0x00005640580844d7 slave_state_changed (NetworkManager)
#7 0x00007efc24833fae ffi_call_unix64 (libffi.so.6)
#8 0x00007efc2483396f ffi_call (libffi.so.6)
#9 0x00007efc29b836e5 g_cclosure_marshal_generic (libgobject-2.0.so.0)
#10 0x00007efc29b82c1d g_closure_invoke (libgobject-2.0.so.0)
#11 0x00007efc29b96173 signal_emit_unlocked_R (libgobject-2.0.so.0)
#12 0x00007efc29b9f29a g_signal_emit_valist (libgobject-2.0.so.0)
#13 0x00007efc29b9f893 g_signal_emit (libgobject-2.0.so.0)
#14 0x000056405807ab20 _set_state_full (NetworkManager)
#15 0x000056405807d803 nm_device_unrealize (NetworkManager)
#16 0x0000564057f6072c _platform_link_cb_idle (NetworkManager)
#17 0x00007efc296a01db g_idle_dispatch (libglib-2.0.so.0)
...
2019-06-28 17:31:40 +02:00
|
|
|
int ifindex_slave;
|
2019-07-31 11:40:35 +02:00
|
|
|
int ifindex;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-08-01 14:56:07 +02:00
|
|
|
if (configure) {
|
|
|
|
|
ifindex = nm_device_get_ifindex(device);
|
|
|
|
|
if (ifindex <= 0 || !nm_platform_link_get(nm_device_get_platform(device), ifindex))
|
|
|
|
|
configure = FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-05-02 13:58:04 +02:00
|
|
|
ifindex_slave = nm_device_get_ip_ifindex(port);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
device: fix crash releasing destroyed slave
I encountered this on a WIP branch, but I think it can happen
under regular conditions. I think there is no error condition here,
and we should do nothing if we have no ifindex.
<debug> [1561653068.2192] platform: signal: link removed: 1699: test1p <DOWN;broadcast,multicast> mtu 1500 master 1698 arp 1 veth* init addrgenmode none addr D6:14:45:97:06:75 brd FF:FF:FF:FF:FF:FF driver veth rx:0,0 tx:38,5606
...
<info> [1561653068.2617] device (test1): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
...
<trace> [1561653068.2635] device[0x564058c73750] (test1p): sys-iface-state: external -> removed
<debug> [1561653068.2635] device[0x564058c73750] (test1p): unrealize (ifindex 1699)
<debug> [1561653068.2636] device[0x564058c73750] (test1p): parent: clear
<trace> [1561653068.2636] device[0x564058b98eb0] (vethbr): mtu: commit-mtu...
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!by-type,!user-explicit,!user-settings,!user-udev,!is-slave=0x10/0x1479/unmanaged/unrealized], set-unmanaged [platform-init=0x10])
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!user-settings=0x10/0x51/unmanaged/unrealized], forget [parent,by-type,user-explicit,user-udev,external-down,is-slave=0x1c2c])
<info> [1561653068.2639] device (test1p): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
<debug> [1561653068.2640] device[0x564058c73750] (test1p): deactivating device (reason 'unmanaged') [3]
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip4-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip6-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'dhcp6' not pending (expected)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'autoconf6' not pending (expected)
<debug> [1561653068.2640] rules-manager: sync
<debug> [1561653068.2640] device[0x564058c73750] (test1p): set metered value 0
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip4-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip6-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2644] device[0x564058b98eb0] (vethbr): slave test1p state change 100 (activated) -> 10 (unmanaged)
<trace> [1561653068.2644] device[0x564058b98eb0] (vethbr): master: release one slave 0x564058c73750/test1p
((src/platform/nm-platform.c:2002)): assertion '<dropped>' failed
backtrace:
...
#3 0x0000564057fb713e _nm_g_return_if_fail_warning (NetworkManager)
#4 0x000056405808b37c release_slave (NetworkManager)
#5 0x0000564058079aef nm_device_master_release_one_slave (NetworkManager)
#6 0x00005640580844d7 slave_state_changed (NetworkManager)
#7 0x00007efc24833fae ffi_call_unix64 (libffi.so.6)
#8 0x00007efc2483396f ffi_call (libffi.so.6)
#9 0x00007efc29b836e5 g_cclosure_marshal_generic (libgobject-2.0.so.0)
#10 0x00007efc29b82c1d g_closure_invoke (libgobject-2.0.so.0)
#11 0x00007efc29b96173 signal_emit_unlocked_R (libgobject-2.0.so.0)
#12 0x00007efc29b9f29a g_signal_emit_valist (libgobject-2.0.so.0)
#13 0x00007efc29b9f893 g_signal_emit (libgobject-2.0.so.0)
#14 0x000056405807ab20 _set_state_full (NetworkManager)
#15 0x000056405807d803 nm_device_unrealize (NetworkManager)
#16 0x0000564057f6072c _platform_link_cb_idle (NetworkManager)
#17 0x00007efc296a01db g_idle_dispatch (libglib-2.0.so.0)
...
2019-06-28 17:31:40 +02:00
|
|
|
if (ifindex_slave <= 0) {
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGD(LOGD_TEAM, "bridge port %s is already detached", nm_device_get_ip_iface(port));
|
device: fix crash releasing destroyed slave
I encountered this on a WIP branch, but I think it can happen
under regular conditions. I think there is no error condition here,
and we should do nothing if we have no ifindex.
<debug> [1561653068.2192] platform: signal: link removed: 1699: test1p <DOWN;broadcast,multicast> mtu 1500 master 1698 arp 1 veth* init addrgenmode none addr D6:14:45:97:06:75 brd FF:FF:FF:FF:FF:FF driver veth rx:0,0 tx:38,5606
...
<info> [1561653068.2617] device (test1): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
...
<trace> [1561653068.2635] device[0x564058c73750] (test1p): sys-iface-state: external -> removed
<debug> [1561653068.2635] device[0x564058c73750] (test1p): unrealize (ifindex 1699)
<debug> [1561653068.2636] device[0x564058c73750] (test1p): parent: clear
<trace> [1561653068.2636] device[0x564058b98eb0] (vethbr): mtu: commit-mtu...
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!by-type,!user-explicit,!user-settings,!user-udev,!is-slave=0x10/0x1479/unmanaged/unrealized], set-unmanaged [platform-init=0x10])
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!user-settings=0x10/0x51/unmanaged/unrealized], forget [parent,by-type,user-explicit,user-udev,external-down,is-slave=0x1c2c])
<info> [1561653068.2639] device (test1p): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
<debug> [1561653068.2640] device[0x564058c73750] (test1p): deactivating device (reason 'unmanaged') [3]
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip4-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip6-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'dhcp6' not pending (expected)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'autoconf6' not pending (expected)
<debug> [1561653068.2640] rules-manager: sync
<debug> [1561653068.2640] device[0x564058c73750] (test1p): set metered value 0
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip4-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip6-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2644] device[0x564058b98eb0] (vethbr): slave test1p state change 100 (activated) -> 10 (unmanaged)
<trace> [1561653068.2644] device[0x564058b98eb0] (vethbr): master: release one slave 0x564058c73750/test1p
((src/platform/nm-platform.c:2002)): assertion '<dropped>' failed
backtrace:
...
#3 0x0000564057fb713e _nm_g_return_if_fail_warning (NetworkManager)
#4 0x000056405808b37c release_slave (NetworkManager)
#5 0x0000564058079aef nm_device_master_release_one_slave (NetworkManager)
#6 0x00005640580844d7 slave_state_changed (NetworkManager)
#7 0x00007efc24833fae ffi_call_unix64 (libffi.so.6)
#8 0x00007efc2483396f ffi_call (libffi.so.6)
#9 0x00007efc29b836e5 g_cclosure_marshal_generic (libgobject-2.0.so.0)
#10 0x00007efc29b82c1d g_closure_invoke (libgobject-2.0.so.0)
#11 0x00007efc29b96173 signal_emit_unlocked_R (libgobject-2.0.so.0)
#12 0x00007efc29b9f29a g_signal_emit_valist (libgobject-2.0.so.0)
#13 0x00007efc29b9f893 g_signal_emit (libgobject-2.0.so.0)
#14 0x000056405807ab20 _set_state_full (NetworkManager)
#15 0x000056405807d803 nm_device_unrealize (NetworkManager)
#16 0x0000564057f6072c _platform_link_cb_idle (NetworkManager)
#17 0x00007efc296a01db g_idle_dispatch (libglib-2.0.so.0)
...
2019-06-28 17:31:40 +02:00
|
|
|
return;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-02-25 16:44:01 -05:00
|
|
|
if (configure) {
|
2017-04-18 12:09:02 +02:00
|
|
|
success = nm_platform_link_release(nm_device_get_platform(device),
|
platform: add self argument to platform functions
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
2015-04-18 12:36:09 +02:00
|
|
|
nm_device_get_ip_ifindex(device),
|
device: fix crash releasing destroyed slave
I encountered this on a WIP branch, but I think it can happen
under regular conditions. I think there is no error condition here,
and we should do nothing if we have no ifindex.
<debug> [1561653068.2192] platform: signal: link removed: 1699: test1p <DOWN;broadcast,multicast> mtu 1500 master 1698 arp 1 veth* init addrgenmode none addr D6:14:45:97:06:75 brd FF:FF:FF:FF:FF:FF driver veth rx:0,0 tx:38,5606
...
<info> [1561653068.2617] device (test1): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
...
<trace> [1561653068.2635] device[0x564058c73750] (test1p): sys-iface-state: external -> removed
<debug> [1561653068.2635] device[0x564058c73750] (test1p): unrealize (ifindex 1699)
<debug> [1561653068.2636] device[0x564058c73750] (test1p): parent: clear
<trace> [1561653068.2636] device[0x564058b98eb0] (vethbr): mtu: commit-mtu...
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!by-type,!user-explicit,!user-settings,!user-udev,!is-slave=0x10/0x1479/unmanaged/unrealized], set-unmanaged [platform-init=0x10])
<debug> [1561653068.2639] device[0x564058c73750] (test1p): unmanaged: flags set to [platform-init,!sleeping,!user-settings=0x10/0x51/unmanaged/unrealized], forget [parent,by-type,user-explicit,user-udev,external-down,is-slave=0x1c2c])
<info> [1561653068.2639] device (test1p): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
<debug> [1561653068.2640] device[0x564058c73750] (test1p): deactivating device (reason 'unmanaged') [3]
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip4-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): ip6-state: set to 0 (none)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'dhcp6' not pending (expected)
<trace> [1561653068.2640] device[0x564058c73750] (test1p): remove_pending_action (0): 'autoconf6' not pending (expected)
<debug> [1561653068.2640] rules-manager: sync
<debug> [1561653068.2640] device[0x564058c73750] (test1p): set metered value 0
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip4-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2641] device[0x564058c73750] (test1p): ip6-config: update (commit=1, new-config=(nil))
<debug> [1561653068.2644] device[0x564058b98eb0] (vethbr): slave test1p state change 100 (activated) -> 10 (unmanaged)
<trace> [1561653068.2644] device[0x564058b98eb0] (vethbr): master: release one slave 0x564058c73750/test1p
((src/platform/nm-platform.c:2002)): assertion '<dropped>' failed
backtrace:
...
#3 0x0000564057fb713e _nm_g_return_if_fail_warning (NetworkManager)
#4 0x000056405808b37c release_slave (NetworkManager)
#5 0x0000564058079aef nm_device_master_release_one_slave (NetworkManager)
#6 0x00005640580844d7 slave_state_changed (NetworkManager)
#7 0x00007efc24833fae ffi_call_unix64 (libffi.so.6)
#8 0x00007efc2483396f ffi_call (libffi.so.6)
#9 0x00007efc29b836e5 g_cclosure_marshal_generic (libgobject-2.0.so.0)
#10 0x00007efc29b82c1d g_closure_invoke (libgobject-2.0.so.0)
#11 0x00007efc29b96173 signal_emit_unlocked_R (libgobject-2.0.so.0)
#12 0x00007efc29b9f29a g_signal_emit_valist (libgobject-2.0.so.0)
#13 0x00007efc29b9f893 g_signal_emit (libgobject-2.0.so.0)
#14 0x000056405807ab20 _set_state_full (NetworkManager)
#15 0x000056405807d803 nm_device_unrealize (NetworkManager)
#16 0x0000564057f6072c _platform_link_cb_idle (NetworkManager)
#17 0x00007efc296a01db g_idle_dispatch (libglib-2.0.so.0)
...
2019-06-28 17:31:40 +02:00
|
|
|
ifindex_slave);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-02-25 16:44:01 -05:00
|
|
|
if (success) {
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGI(LOGD_BRIDGE, "detached bridge port %s", nm_device_get_ip_iface(port));
|
2014-02-25 16:44:01 -05:00
|
|
|
} else {
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGW(LOGD_BRIDGE, "failed to detach bridge port %s", nm_device_get_ip_iface(port));
|
2014-02-25 16:44:01 -05:00
|
|
|
}
|
2014-02-25 16:41:33 -05:00
|
|
|
} else {
|
2022-05-02 13:58:04 +02:00
|
|
|
_LOGI(LOGD_BRIDGE, "bridge port %s was detached", nm_device_get_ip_iface(port));
|
2014-02-25 16:41:33 -05:00
|
|
|
}
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
static gboolean
|
2021-11-09 13:28:54 +01:00
|
|
|
create_and_realize(NMDevice *device,
|
|
|
|
|
NMConnection *connection,
|
|
|
|
|
NMDevice *parent,
|
2015-12-09 15:13:57 +01:00
|
|
|
const NMPlatformLink **out_plink,
|
2021-11-09 13:28:54 +01:00
|
|
|
GError **error)
|
2014-09-05 08:50:02 -05:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSettingWired *s_wired;
|
|
|
|
|
NMSettingBridge *s_bridge;
|
|
|
|
|
const char *iface = nm_device_get_iface(device);
|
|
|
|
|
const char *hwaddr;
|
|
|
|
|
gs_free char *hwaddr_cloned = NULL;
|
2021-03-03 20:57:01 +01:00
|
|
|
guint8 mac_address[_NM_UTILS_HWADDR_LEN_MAX];
|
2020-08-05 13:46:28 -04:00
|
|
|
NMPlatformLnkBridge props;
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
int r;
|
2020-10-30 16:35:25 +01:00
|
|
|
guint32 mtu = 0;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-07-25 13:15:15 +02:00
|
|
|
nm_assert(iface);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
s_bridge = nm_connection_get_setting_bridge(connection);
|
2017-07-25 13:15:15 +02:00
|
|
|
nm_assert(s_bridge);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
hwaddr = nm_setting_bridge_get_mac_address(s_bridge);
|
2017-07-25 13:15:15 +02:00
|
|
|
if (!hwaddr
|
|
|
|
|
&& nm_device_hw_addr_get_cloned(device, connection, FALSE, &hwaddr_cloned, NULL, NULL)) {
|
2019-12-31 01:22:36 +01:00
|
|
|
/* FIXME: we set the MAC address when creating the interface, while the
|
|
|
|
|
* NMDevice is still unrealized. As we afterwards realize the device, it
|
|
|
|
|
* forgets the parameters for the cloned MAC address, and in stage 1
|
|
|
|
|
* it might create a different MAC address. That should be fixed by
|
|
|
|
|
* better handling device realization. */
|
2017-07-25 13:15:15 +02:00
|
|
|
hwaddr = hwaddr_cloned;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
if (hwaddr) {
|
|
|
|
|
if (!nm_utils_hwaddr_aton(hwaddr, mac_address, ETH_ALEN)) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_DEVICE_ERROR,
|
|
|
|
|
NM_DEVICE_ERROR_FAILED,
|
|
|
|
|
"Invalid hardware address '%s'",
|
|
|
|
|
hwaddr);
|
2017-07-25 13:15:15 +02:00
|
|
|
g_return_val_if_reached(FALSE);
|
2014-09-05 08:50:02 -05:00
|
|
|
}
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-02-28 10:57:05 +01:00
|
|
|
_platform_lnk_bridge_init_from_setting(s_bridge, &props);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-05-05 10:29:31 +02:00
|
|
|
s_wired = nm_connection_get_setting_wired(connection);
|
|
|
|
|
nm_assert(s_wired);
|
|
|
|
|
|
|
|
|
|
mtu = nm_setting_wired_get_mtu(s_wired);
|
|
|
|
|
|
2020-10-21 18:57:18 +02:00
|
|
|
/* If mtu != 0, we set the MTU of the new bridge at creation time. However, kernel will still
|
|
|
|
|
* automatically adjust the MTU of the bridge based on the minimum of the slave's MTU.
|
|
|
|
|
* We don't want this automatism as the user asked for a fixed MTU.
|
|
|
|
|
*
|
|
|
|
|
* To workaround this behavior of kernel, we will later toggle the MTU twice. See
|
|
|
|
|
* NMDeviceClass.mtu_force_set. */
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
r = nm_platform_link_bridge_add(nm_device_get_platform(device),
|
|
|
|
|
iface,
|
|
|
|
|
hwaddr ? mac_address : NULL,
|
|
|
|
|
hwaddr ? ETH_ALEN : 0,
|
2020-10-30 16:35:25 +01:00
|
|
|
mtu,
|
2020-08-05 13:46:28 -04:00
|
|
|
&props,
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
out_plink);
|
|
|
|
|
if (r < 0) {
|
2014-09-05 08:50:02 -05:00
|
|
|
g_set_error(error,
|
|
|
|
|
NM_DEVICE_ERROR,
|
|
|
|
|
NM_DEVICE_ERROR_CREATION_FAILED,
|
|
|
|
|
"Failed to create bridge interface '%s' for '%s': %s",
|
|
|
|
|
iface,
|
|
|
|
|
nm_connection_get_id(connection),
|
platform: merge NMPlatformError with nm-error
Platform had it's own scheme for reporting errors: NMPlatformError.
Before, NMPlatformError indicated success via zero, negative integer
values are numbers from <errno.h>, and positive integer values are
platform specific codes. This changes now according to nm-error:
success is still zero. Negative values indicate a failure, where the
numeric value is either from <errno.h> or one of our error codes.
The meaning of positive values depends on the functions. Most functions
can only report an error reason (negative) and success (zero). For such
functions, positive values should never be returned (but the caller
should anticipate them).
For some functions, positive values could mean additional information
(but still success). That depends.
This is also what systemd does, except that systemd only returns
(negative) integers from <errno.h>, while we merge our own error codes
into the range of <errno.h>.
The advantage is to get rid of one way how to signal errors. The other
advantage is, that these error codes are compatible with all other
nm-errno values. For example, previously negative values indicated error
codes from <errno.h>, but it did not entail error codes from netlink.
2018-12-22 14:13:05 +01:00
|
|
|
nm_strerror(r));
|
2014-09-05 08:50:02 -05:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-09-05 08:50:02 -05:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2012-10-29 19:02:45 -05:00
|
|
|
|
2022-07-13 17:07:18 +02:00
|
|
|
static gboolean
|
|
|
|
|
can_reapply_change(NMDevice *device,
|
|
|
|
|
const char *setting_name,
|
|
|
|
|
NMSetting *s_old,
|
|
|
|
|
NMSetting *s_new,
|
|
|
|
|
GHashTable *diffs,
|
|
|
|
|
GError **error)
|
|
|
|
|
{
|
|
|
|
|
/* Delegate changes to other settings to parent class */
|
|
|
|
|
if (!nm_streq(setting_name, NM_SETTING_BRIDGE_SETTING_NAME)) {
|
2022-07-29 12:35:03 +02:00
|
|
|
return NM_DEVICE_CLASS(nm_device_bridge_parent_class)
|
2022-07-13 17:07:18 +02:00
|
|
|
->can_reapply_change(device, setting_name, s_old, s_new, diffs, error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nm_device_hash_check_invalid_keys(diffs,
|
|
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
|
error,
|
|
|
|
|
NM_SETTING_BRIDGE_STP,
|
|
|
|
|
NM_SETTING_BRIDGE_PRIORITY,
|
|
|
|
|
NM_SETTING_BRIDGE_FORWARD_DELAY,
|
|
|
|
|
NM_SETTING_BRIDGE_HELLO_TIME,
|
|
|
|
|
NM_SETTING_BRIDGE_MAX_AGE,
|
|
|
|
|
NM_SETTING_BRIDGE_AGEING_TIME,
|
|
|
|
|
NM_SETTING_BRIDGE_GROUP_FORWARD_MASK,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_HASH_MAX,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_LAST_MEMBER_COUNT,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_LAST_MEMBER_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_MEMBERSHIP_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_SNOOPING,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_ROUTER,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_QUERIER,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_QUERIER_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_QUERY_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_QUERY_RESPONSE_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_QUERY_USE_IFADDR,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_STARTUP_QUERY_COUNT,
|
|
|
|
|
NM_SETTING_BRIDGE_MULTICAST_STARTUP_QUERY_INTERVAL,
|
|
|
|
|
NM_SETTING_BRIDGE_GROUP_ADDRESS,
|
|
|
|
|
NM_SETTING_BRIDGE_VLAN_PROTOCOL,
|
|
|
|
|
NM_SETTING_BRIDGE_VLAN_STATS_ENABLED,
|
|
|
|
|
NM_SETTING_BRIDGE_VLAN_FILTERING,
|
|
|
|
|
NM_SETTING_BRIDGE_VLAN_DEFAULT_PVID,
|
|
|
|
|
NM_SETTING_BRIDGE_VLANS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
reapply_connection(NMDevice *device, NMConnection *con_old, NMConnection *con_new)
|
|
|
|
|
{
|
|
|
|
|
NMDeviceBridge *self = NM_DEVICE_BRIDGE(device);
|
|
|
|
|
NMSettingBridge *s_bridge;
|
|
|
|
|
|
|
|
|
|
NM_DEVICE_CLASS(nm_device_bridge_parent_class)->reapply_connection(device, con_old, con_new);
|
|
|
|
|
|
|
|
|
|
_LOGD(LOGD_BRIDGE, "reapplying bridge settings");
|
|
|
|
|
s_bridge = nm_connection_get_setting_bridge(con_new);
|
|
|
|
|
g_return_if_fail(s_bridge);
|
|
|
|
|
|
2022-08-04 18:20:07 +02:00
|
|
|
/* Make sure bridge_set_vlan_options() called by link_config()
|
|
|
|
|
* sets vlan_filtering and default_pvid anew. */
|
|
|
|
|
self->vlan_configured = FALSE;
|
|
|
|
|
|
2022-07-13 17:07:18 +02:00
|
|
|
link_config(device, con_new);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
static void
|
|
|
|
|
nm_device_bridge_init(NMDeviceBridge *self)
|
|
|
|
|
{
|
2017-06-01 23:08:30 +02:00
|
|
|
nm_assert(nm_device_is_master(NM_DEVICE(self)));
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
|
|
|
|
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. It seems that the new version has a
slightly smaller RSS size.
- 19356 RSS
+ 18660 RSS
2018-02-26 13:51:52 +01:00
|
|
|
static const NMDBusInterfaceInfoExtended interface_info_device_bridge = {
|
|
|
|
|
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT(
|
|
|
|
|
NM_DBUS_INTERFACE_DEVICE_BRIDGE,
|
|
|
|
|
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS(
|
2021-05-12 18:18:57 +02:00
|
|
|
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("HwAddress", "s", NM_DEVICE_HW_ADDRESS),
|
|
|
|
|
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Carrier", "b", NM_DEVICE_CARRIER),
|
|
|
|
|
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("Slaves", "ao", NM_DEVICE_SLAVES), ), ),
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. It seems that the new version has a
slightly smaller RSS size.
- 19356 RSS
+ 18660 RSS
2018-02-26 13:51:52 +01:00
|
|
|
};
|
|
|
|
|
|
2012-10-29 19:02:45 -05:00
|
|
|
static void
|
|
|
|
|
nm_device_bridge_class_init(NMDeviceBridgeClass *klass)
|
|
|
|
|
{
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. It seems that the new version has a
slightly smaller RSS size.
- 19356 RSS
+ 18660 RSS
2018-02-26 13:51:52 +01:00
|
|
|
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS(klass);
|
2021-11-09 13:28:54 +01:00
|
|
|
NMDeviceClass *device_class = NM_DEVICE_CLASS(klass);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API
Previously, we used the generated GDBusInterfaceSkeleton types and glued
them via the NMExportedObject base class to our NM types. We also used
GDBusObjectManagerServer.
Don't do that anymore. The resulting code was more complicated despite (or
because?) using generated classes. It was hard to understand, complex, had
ordering-issues, and had a runtime and memory overhead.
This patch refactors this entirely and uses the lower layer API GDBusConnection
directly. It replaces the generated code, GDBusInterfaceSkeleton, and
GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager
and static descriptor instances of type GDBusInterfaceInfo.
This adds a net plus of more then 1300 lines of hand written code. I claim
that this implementation is easier to understand. Note that previously we
also required extensive and complex glue code to bind our objects to the
generated skeleton objects. Instead, now glue our objects directly to
GDBusConnection. The result is more immediate and gets rid of layers of
code in between.
Now that the D-Bus glue us more under our control, we can address issus and
bottlenecks better, instead of adding code to bend the generated skeletons
to our needs.
Note that the current implementation now only supports one D-Bus connection.
That was effectively the case already, although there were places (and still are)
where the code pretends it could also support connections from a private socket.
We dropped private socket support mainly because it was unused, untested and
buggy, but also because GDBusObjectManagerServer could not export the same
objects on multiple connections. Now, it would be rather straight forward to
fix that and re-introduce ObjectManager on each private connection. But this
commit doesn't do that yet, and the new code intentionally supports only one
D-Bus connection.
Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start()
succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to
connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough
for the moment. It could be easily extended later, for example with polling whether the
system bus appears (like was done previously). Also, restart of D-Bus daemon isn't
supported either -- just like before.
Note how NMDBusManager now implements the ObjectManager D-Bus interface
directly.
Also, this fixes race issues in the server, by no longer delaying
PropertiesChanged signals. NMExportedObject would collect changed
properties and send the signal out in idle_emit_properties_changed()
on idle. This messes up the ordering of change events w.r.t. other
signals and events on the bus. Note that not only NMExportedObject
messed up the ordering. Also the generated code would hook into
notify() and process change events in and idle handle, exhibiting the
same ordering issue too.
No longer do that. PropertiesChanged signals will be sent right away
by hooking into dispatch_properties_changed(). This means, changing
a property in quick succession will no longer be combined and is
guaranteed to emit signals for each individual state. Quite possibly
we emit now more PropertiesChanged signals then before.
However, we are now able to group a set of changes by using standard
g_object_freeze_notify()/g_object_thaw_notify(). We probably should
make more use of that.
Also, now that our signals are all handled in the right order, we
might find places where we still emit them in the wrong order. But that
is then due to the order in which our GObjects emit signals, not due
to an ill behavior of the D-Bus glue. Possibly we need to identify
such ordering issues and fix them.
Numbers (for contrib/rpm --without debug on x86_64):
- the patch changes the code size of NetworkManager by
- 2809360 bytes
+ 2537528 bytes (-9.7%)
- Runtime measurements are harder because there is a large variance
during testing. In other words, the numbers are not reproducible.
Currently, the implementation performs no caching of GVariants at all,
but it would be rather simple to add it, if that turns out to be
useful.
Anyway, without strong claim, it seems that the new form tends to
perform slightly better. That would be no surprise.
$ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done)
- real 1m39.355s
+ real 1m37.432s
$ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done)
- real 0m26.843s
+ real 0m25.281s
- Regarding RSS size, just looking at the processes in similar
conditions, doesn't give a large difference. On my system they
consume about 19MB RSS. It seems that the new version has a
slightly smaller RSS size.
- 19356 RSS
+ 18660 RSS
2018-02-26 13:51:52 +01:00
|
|
|
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS(&interface_info_device_bridge);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-07-10 09:26:42 +02:00
|
|
|
device_class->connection_type_supported = NM_SETTING_BRIDGE_SETTING_NAME;
|
|
|
|
|
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES(NM_LINK_TYPE_BRIDGE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->is_master = TRUE;
|
2020-10-21 18:57:18 +02:00
|
|
|
device_class->mtu_force_set = TRUE;
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->get_generic_capabilities = get_generic_capabilities;
|
|
|
|
|
device_class->check_connection_compatible = check_connection_compatible;
|
|
|
|
|
device_class->check_connection_available = check_connection_available;
|
|
|
|
|
device_class->complete_connection = complete_connection;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->update_connection = update_connection;
|
|
|
|
|
device_class->master_update_slave_connection = master_update_slave_connection;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->create_and_realize = create_and_realize;
|
2019-08-22 09:57:55 +02:00
|
|
|
device_class->act_stage1_prepare_set_hwaddr_ethernet = TRUE;
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->act_stage1_prepare = act_stage1_prepare;
|
|
|
|
|
device_class->act_stage2_config = act_stage2_config;
|
|
|
|
|
device_class->deactivate = deactivate;
|
2022-05-02 13:58:04 +02:00
|
|
|
device_class->attach_port = attach_port;
|
|
|
|
|
device_class->detach_port = detach_port;
|
2018-07-10 07:45:35 +02:00
|
|
|
device_class->get_configured_mtu = nm_device_get_configured_mtu_for_wired;
|
2022-07-13 17:07:18 +02:00
|
|
|
device_class->can_reapply_change = can_reapply_change;
|
|
|
|
|
device_class->reapply_connection = reapply_connection;
|
2012-10-29 19:02:45 -05:00
|
|
|
}
|
2014-09-08 10:12:28 -05:00
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2014-09-08 10:12:28 -05:00
|
|
|
|
2016-10-07 17:00:59 +02:00
|
|
|
#define NM_TYPE_BRIDGE_DEVICE_FACTORY (nm_bridge_device_factory_get_type())
|
|
|
|
|
#define NM_BRIDGE_DEVICE_FACTORY(obj) \
|
|
|
|
|
(G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_BRIDGE_DEVICE_FACTORY, NMBridgeDeviceFactory))
|
2014-09-08 10:12:28 -05:00
|
|
|
|
|
|
|
|
static NMDevice *
|
2021-11-09 13:28:54 +01:00
|
|
|
create_device(NMDeviceFactory *factory,
|
|
|
|
|
const char *iface,
|
2016-01-10 15:13:20 +01:00
|
|
|
const NMPlatformLink *plink,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMConnection *connection,
|
|
|
|
|
gboolean *out_ignore)
|
2014-09-08 10:12:28 -05:00
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_DEVICE_BRIDGE,
|
|
|
|
|
NM_DEVICE_IFACE,
|
|
|
|
|
iface,
|
|
|
|
|
NM_DEVICE_DRIVER,
|
|
|
|
|
"bridge",
|
|
|
|
|
NM_DEVICE_TYPE_DESC,
|
|
|
|
|
"Bridge",
|
|
|
|
|
NM_DEVICE_DEVICE_TYPE,
|
|
|
|
|
NM_DEVICE_TYPE_BRIDGE,
|
|
|
|
|
NM_DEVICE_LINK_TYPE,
|
|
|
|
|
NM_LINK_TYPE_BRIDGE,
|
|
|
|
|
NULL);
|
2014-09-08 10:12:28 -05:00
|
|
|
}
|
|
|
|
|
|
2017-06-30 16:33:07 +02:00
|
|
|
static gboolean
|
|
|
|
|
match_connection(NMDeviceFactory *factory, NMConnection *connection)
|
|
|
|
|
{
|
|
|
|
|
const char *type = nm_connection_get_connection_type(connection);
|
|
|
|
|
|
|
|
|
|
if (nm_streq(type, NM_SETTING_BRIDGE_SETTING_NAME))
|
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
|
|
nm_assert(nm_streq(type, NM_SETTING_BLUETOOTH_SETTING_NAME));
|
|
|
|
|
|
2017-08-06 07:50:48 +02:00
|
|
|
if (!_nm_connection_get_setting_bluetooth_for_nap(connection))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
if (!g_type_from_name("NMBluezManager")) {
|
|
|
|
|
/* bluetooth NAP connections are handled by bridge factory. However,
|
|
|
|
|
* it needs help from the bluetooth plugin, so if the plugin is not loaded,
|
|
|
|
|
* we claim not to support it. */
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
2017-06-30 16:33:07 +02:00
|
|
|
}
|
|
|
|
|
|
2014-09-17 14:17:30 -05:00
|
|
|
NM_DEVICE_FACTORY_DEFINE_INTERNAL(
|
|
|
|
|
BRIDGE,
|
|
|
|
|
Bridge,
|
|
|
|
|
bridge,
|
|
|
|
|
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES(NM_LINK_TYPE_BRIDGE)
|
2017-06-30 16:33:07 +02:00
|
|
|
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES(NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
|
NM_SETTING_BLUETOOTH_SETTING_NAME),
|
2016-10-07 16:05:43 +02:00
|
|
|
factory_class->create_device = create_device;
|
2017-06-30 16:33:07 +02:00
|
|
|
factory_class->match_connection = match_connection;);
|