Multi-link support is introduced in 802.11be specification. This enables
Wi-Fi devices with multiple radios to use these links simultaneously for
data transfer.
This commit introduces a new interface type to represent an MLO link
for an MLO connection.
A Wi-Fi station's MLO connection to AP shall have multiple links
represented by an MLO link and each link need to carry the respective
connection information e.g., Connection State, Connected BSS Info,
Connection Frequency/properties, etc.
Thus, each MLO link of an MLO connection is represented by a wdev of
type NL80211_IFTYPE_MLO_LINK_DEVICE.
A MLO link wdev does not have an active netdev associated to it but will
be similar to that of NL80211_IFTYPE_STATION wdev with respect to
maintaining connection state information and providing the required
operations to establish an MLO link.
One of these MLO Links (wdev’s) needs to be the MLD interface of the MLO
connection and this will be the wdev with NL80211_IFTYPE_STATION which
has a netdev interface associated.
A MLO station can have multiple links to an MLO AP and thus the MLD-wdev
interface has to relate to all such MLO link's-wdev's.
MLD wdev and MLO link wdev's can also be on different wiphy's if the
host driver's register a single wiphy for each supported band/MAC/PHY.
MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the userspace
prior the MLO connection.
struct cfg80211_connect_resp_params is now enhanced to also carry MLO
link specific (wdev) information along with the connection result.
Accordingly, cfg8011 shall get the information of the associated
MLO link's for the MLO connection and will notify the same to the
userspace.
User space entities will be able to configure the keys ( GTK / IGTK )
or any other MLO link specific information on the respective MLO link
wdev.
Please note that the enhancements in this commit are aimed to initiate
the design review. These changes have not yet been tested.
Also, this commit highlights the main areas that would need changes and
would need additional enhancements to make it complete.
One instance on this aspect is to consider a cfg80211 ops to start the
mlo link device (say start_mlo_link_device) for either the STA or AP
interface. This interface shall pair with stop_mlo_link_device and
thus provide the option for the user space to start/stop a specicic
MLO link. This again can be an optional interface which can be used
at the discretion of the driver architectures (driver's implicitly
starting an MLO link need not rely on this control from user space).
Signed-off-by: Sunil Dutt <[email protected]>
---
include/net/cfg80211.h | 24 ++++++++++++++++++++++++
include/uapi/linux/nl80211.h | 12 ++++++++++++
net/wireless/chan.c | 3 +++
net/wireless/core.c | 34 ++++++++++++++++++++++++++++++++++
net/wireless/core.h | 3 +++
net/wireless/nl80211.c | 44 +++++++++++++++++++++++++++++++++++++++++---
net/wireless/rdev-ops.h | 8 ++++++++
net/wireless/sme.c | 43 +++++++++++++++++++++++++++++++++++++++++--
net/wireless/trace.h | 5 +++++
net/wireless/util.c | 4 ++++
10 files changed, 175 insertions(+), 5 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9678d32..cea3b14 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3935,6 +3935,7 @@ struct mgmt_frame_regs {
* This callback may sleep.
* @reset_tid_config: Reset TID specific configuration for the peer, for the
* given TIDs. This callback may sleep.
+ * @stop_mlo_link_device: Stop the MLO Link device.
*/
struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -4260,6 +4261,8 @@ struct cfg80211_ops {
struct cfg80211_tid_config *tid_conf);
int (*reset_tid_config)(struct wiphy *wiphy, struct net_device *dev,
const u8 *peer, u8 tids);
+ void (*stop_mlo_link_device)(struct wiphy *wiphy,
+ struct wireless_dev *wdev);
};
/*
@@ -5248,6 +5251,12 @@ struct cfg80211_cqm_config;
* @pmsr_free_wk: (private) peer measurements cleanup work
* @unprot_beacon_reported: (private) timestamp of last
* unprotected beacon report
+ * @mlo_list: Used to collect the MLO links. Applicable for iftype
+ * NL80211_IFTYPE_MLO_LINK_DEVICE.
+ * @mlo_link_wdev_list: MLO Link wdev's list associated for the current
+ * MLO connection. Applicable for iftype NL80211_IFTYPE_STATION.
+ * @mld_wdev: MLD (MLO Data) wdev associated for the MLO link wdev for
+ * an MLO connection. Applicable for iftype NL80211_IFTYPE_MLO_LINK_DEVICE.
*/
struct wireless_dev {
struct wiphy *wiphy;
@@ -5327,6 +5336,9 @@ struct wireless_dev {
struct work_struct pmsr_free_wk;
unsigned long unprot_beacon_reported;
+ struct list_head mlo_list;
+ struct list_head mlo_link_wdev_list;
+ struct wireless_dev *mld_wdev;
};
static inline u8 *wdev_address(struct wireless_dev *wdev)
@@ -6828,6 +6840,16 @@ struct cfg80211_fils_resp_params {
};
/**
+ * struct cfg80211_mlo_link_device_params - MLO Link device params.
+ * @wdev: the wireless device associated with the MLO Link device.
+ * @bss: Entry of bss to which MLO Link got connected to.
+ */
+struct cfg80211_mlo_link_device_params {
+ struct wireless_dev *wdev;
+ struct cfg80211_bss *bss;
+};
+
+/**
* struct cfg80211_connect_resp_params - Connection response params
* @status: Status code, %WLAN_STATUS_SUCCESS for successful connection, use
* %WLAN_STATUS_UNSPECIFIED_FAILURE if your device cannot give you
@@ -6866,6 +6888,8 @@ struct cfg80211_connect_resp_params {
size_t resp_ie_len;
struct cfg80211_fils_resp_params fils;
enum nl80211_timeout_reason timeout_reason;
+ const struct cfg80211_mlo_link_device_params *mlo_links;
+ int n_mlo_links;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 3e0d4a0..2b01e4f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2534,6 +2534,11 @@ enum nl80211_commands {
* This is a u8 attribute that encapsulates one of the values from
* &enum nl80211_sae_pwe_mechanism.
*
+ * @NL80211_ATTR_MLO_LINK_INFO: MLO Links connection information.
+ * It is a nested attribute, carrying the MLO links connection information.
+ * Carries the %NL80211_ATTR_WIPHY, %NL80211_ATTR_WDEV, of each MLO Link
+ * device, along with the connected BSSID for that link through
+ * %NL80211_ATTR_MAC.
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3025,6 +3030,8 @@ enum nl80211_attrs {
NL80211_ATTR_SAE_PWE,
+ NL80211_ATTR_MLO_LINK_INFO,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -3110,6 +3117,7 @@ enum nl80211_attrs {
* @NL80211_IF_TYPE_OCB: Outside Context of a BSS
* This mode corresponds to the MIB variable dot11OCBActivated=true
* @NL80211_IFTYPE_NAN: NAN device interface type (not a netdev)
+ * @NL80211_IFTYPE_MLO_LINK_DEVICE: MLO Link device interface type (not a netdev).
* @NL80211_IFTYPE_MAX: highest interface type number currently defined
* @NUM_NL80211_IFTYPES: number of defined interface types
*
@@ -3131,6 +3139,7 @@ enum nl80211_iftype {
NL80211_IFTYPE_P2P_DEVICE,
NL80211_IFTYPE_OCB,
NL80211_IFTYPE_NAN,
+ NL80211_IFTYPE_MLO_LINK_DEVICE,
/* keep last */
NUM_NL80211_IFTYPES,
@@ -5908,6 +5917,8 @@ enum nl80211_feature_flags {
* @NL80211_EXT_FEATURE_BEACON_RATE_HE: Driver supports beacon rate
* configuration (AP/mesh) with HE rates.
*
+ * @NL80211_EXT_FEATURE_MLO: Driver/device supports MLO (Multi Link Operation).
+ *
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
*/
@@ -5969,6 +5980,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_FILS_DISCOVERY,
NL80211_EXT_FEATURE_UNSOL_BCAST_PROBE_RESP,
NL80211_EXT_FEATURE_BEACON_RATE_HE,
+ NL80211_EXT_FEATURE_MLO,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index e4030f1..1a5bb09 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -532,6 +532,7 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_P2P_DEVICE:
case NL80211_IFTYPE_NAN:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
break;
case NL80211_IFTYPE_WDS:
case NL80211_IFTYPE_UNSPECIFIED:
@@ -678,6 +679,7 @@ bool cfg80211_beaconing_iface_active(struct wireless_dev *wdev)
case NL80211_IFTYPE_MONITOR:
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_P2P_DEVICE:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
/* Can NAN type be considered as beaconing interface? */
case NL80211_IFTYPE_NAN:
break;
@@ -1278,6 +1280,7 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
break;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_P2P_CLIENT:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
if (wdev->current_bss) {
*chan = wdev->current_bss->pub.channel;
*chanmode = CHAN_MODE_SHARED;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index f6b744e..24aab59 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -261,6 +261,31 @@ void cfg80211_stop_nan(struct cfg80211_registered_device *rdev,
rdev->opencount--;
}
+void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev)
+{
+ ASSERT_RTNL();
+
+ if (WARN_ON(wdev->iftype != NL80211_IFTYPE_MLO_LINK_DEVICE))
+ return;
+
+ if (!wdev_running(wdev))
+ return;
+
+ rdev_stop_mlo_link_device(rdev, wdev);
+ wdev->is_running = false;
+
+ rdev->opencount--;
+
+ if (rdev->scan_req && rdev->scan_req->wdev == wdev) {
+ if (WARN_ON(!rdev->scan_req->notified &&
+ (!rdev->int_scan_req ||
+ !rdev->int_scan_req->notified)))
+ rdev->scan_req->info.aborted = true;
+ ___cfg80211_scan_done(rdev, false);
+ }
+}
+
void cfg80211_shutdown_all_interfaces(struct wiphy *wiphy)
{
struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
@@ -281,6 +306,9 @@ void cfg80211_shutdown_all_interfaces(struct wiphy *wiphy)
case NL80211_IFTYPE_NAN:
cfg80211_stop_nan(rdev, wdev);
break;
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
+ cfg80211_stop_mlo_link_device(rdev, wdev);
+ break;
default:
break;
}
@@ -1118,6 +1146,9 @@ static void __cfg80211_unregister_wdev(struct wireless_dev *wdev, bool sync)
case NL80211_IFTYPE_NAN:
cfg80211_stop_nan(rdev, wdev);
break;
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
+ cfg80211_stop_mlo_link_device(rdev, wdev);
+ break;
default:
break;
}
@@ -1200,6 +1231,7 @@ void __cfg80211_leave(struct cfg80211_registered_device *rdev,
break;
case NL80211_IFTYPE_P2P_DEVICE:
case NL80211_IFTYPE_NAN:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
/* cannot happen, has no netdev */
break;
case NL80211_IFTYPE_AP_VLAN:
@@ -1254,6 +1286,8 @@ void cfg80211_init_wdev(struct cfg80211_registered_device *rdev,
spin_lock_init(&wdev->mgmt_registrations_lock);
INIT_LIST_HEAD(&wdev->pmsr_list);
spin_lock_init(&wdev->pmsr_lock);
+ INIT_LIST_HEAD(&wdev->mlo_link_wdev_list);
+ INIT_LIST_HEAD(&wdev->mlo_list);
INIT_WORK(&wdev->pmsr_free_wk, cfg80211_pmsr_free_wk);
/*
diff --git a/net/wireless/core.h b/net/wireless/core.h
index e1ec9ac..785d7c6 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -532,6 +532,9 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
void cfg80211_stop_p2p_device(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
+void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev);
+
void cfg80211_stop_nan(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b76bdc8..189ca2c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -718,6 +718,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_SAE_PWE] =
NLA_POLICY_RANGE(NLA_U8, NL80211_SAE_PWE_HUNT_AND_PECK,
NL80211_SAE_PWE_BOTH),
+ [NL80211_ATTR_MLO_LINK_INFO] = { .type = NLA_NESTED },
};
/* policy for the key attributes */
@@ -1400,6 +1401,7 @@ static int nl80211_key_allowed(struct wireless_dev *wdev)
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_P2P_CLIENT:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
if (!wdev->current_bss)
return -ENOLINK;
break;
@@ -3805,6 +3807,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
return -EOPNOTSUPP;
if ((type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN ||
+ type == NL80211_IFTYPE_MLO_LINK_DEVICE ||
rdev->wiphy.features & NL80211_FEATURE_MAC_ON_CREATE) &&
info->attrs[NL80211_ATTR_MAC]) {
nla_memcpy(params.macaddr, info->attrs[NL80211_ATTR_MAC],
@@ -3858,11 +3861,13 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
wdev->mesh_id_up_len);
wdev_unlock(wdev);
break;
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
case NL80211_IFTYPE_NAN:
case NL80211_IFTYPE_P2P_DEVICE:
/*
- * P2P Device and NAN do not have a netdev, so don't go
- * through the netdev notifier and must be added here
+ * P2P Device, NAN and MLO Link device do not have a netdev,
+ * so don't go through the netdev notifier and must be added
+ * here
*/
cfg80211_init_wdev(rdev, wdev);
break;
@@ -11125,6 +11130,7 @@ static int nl80211_register_mgmt(struct sk_buff *skb, struct genl_info *info)
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_P2P_GO:
case NL80211_IFTYPE_P2P_DEVICE:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
break;
case NL80211_IFTYPE_NAN:
default:
@@ -11181,6 +11187,7 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_P2P_GO:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
break;
case NL80211_IFTYPE_NAN:
default:
@@ -11305,6 +11312,7 @@ static int nl80211_tx_mgmt_cancel_wait(struct sk_buff *skb, struct genl_info *in
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_P2P_GO:
case NL80211_IFTYPE_P2P_DEVICE:
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
break;
case NL80211_IFTYPE_NAN:
default:
@@ -16023,10 +16031,14 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
{
struct sk_buff *msg;
void *hdr;
+ struct nlattr *nested, *nested_mlo_links;
+ struct cfg80211_mlo_link_device_params *mlo_link;
+ int i = 0;
msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
cr->fils.kek_len + cr->fils.pmk_len +
- (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+ (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+ (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
if (!msg)
return;
@@ -16065,6 +16077,32 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev,
nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid)))))
goto nla_put_failure;
+ if (cr->n_mlo_links) {
+ nested = nla_nest_start(msg, NL80211_ATTR_MLO_LINK_INFO);
+ if (!nested)
+ goto nla_put_failure;
+
+ for (i = 0; i < cr->n_mlo_links; i++) {
+ mlo_link = (struct cfg80211_mlo_link_device_params *)&cr->mlo_links[i];
+ nested_mlo_links = nla_nest_start(msg, i + 1);
+ if (!nested_mlo_links)
+ goto nla_put_failure;
+
+ if ((mlo_link->wdev &&
+ nla_put_u32(msg, NL80211_ATTR_WIPHY,
+ wiphy_to_rdev(mlo_link->wdev->wiphy)->wiphy_idx)) ||
+ (mlo_link->wdev &&
+ nla_put_u64_64bit(msg, NL80211_ATTR_WDEV, wdev_id(mlo_link->wdev),
+ NL80211_ATTR_PAD)) ||
+ (mlo_link->bss &&
+ nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, mlo_link->bss->bssid)))
+ goto nla_put_failure;
+
+ nla_nest_end(msg, nested_mlo_links);
+ }
+ nla_nest_end(msg, nested);
+ }
+
genlmsg_end(msg, hdr);
genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0,
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 5e2f349..68bdfb8 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1022,6 +1022,14 @@ rdev_nan_change_conf(struct cfg80211_registered_device *rdev,
return ret;
}
+static inline void rdev_stop_mlo_link_device(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev)
+{
+ trace_rdev_stop_mlo_link_device(&rdev->wiphy, wdev);
+ rdev->ops->stop_mlo_link_device(&rdev->wiphy, wdev);
+ trace_rdev_return_void(&rdev->wiphy);
+}
+
static inline int rdev_set_mac_acl(struct cfg80211_registered_device *rdev,
struct net_device *dev,
struct cfg80211_acl_data *params)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 38df713..60a3720 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -682,6 +682,8 @@ void __cfg80211_connect_result(struct net_device *dev,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
const u8 *country_ie;
+ struct cfg80211_mlo_link_device_params *mlo_link;
+ int i = 0;
#ifdef CONFIG_CFG80211_WEXT
union iwreq_data wrqu;
#endif
@@ -783,6 +785,20 @@ void __cfg80211_connect_result(struct net_device *dev,
regulatory_hint_country_ie(wdev->wiphy, cr->bss->channel->band,
country_ie + 2, country_ie[1]);
kfree(country_ie);
+
+ for (i = 0; i < cr->n_mlo_links; i++) {
+ mlo_link = (struct cfg80211_mlo_link_device_params *)&cr->mlo_links[i];
+ if (mlo_link->wdev) {
+ list_add_rcu(&mlo_link->wdev->mlo_list, &wdev->mlo_link_wdev_list);
+ mlo_link->wdev->mld_wdev = wdev;
+ if (mlo_link->bss) {
+ mlo_link->wdev->current_bss = bss_from_pub(mlo_link->bss);
+ cfg80211_hold_bss(bss_from_pub(mlo_link->bss));
+ }
+ mlo_link->wdev->is_running = true;
+ wiphy_to_rdev(mlo_link->wdev->wiphy)->opencount++;
+ }
+ }
}
/* Consumes bss object one way or another */
@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,
ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
params->req_ie_len + params->resp_ie_len +
params->fils.kek_len + params->fils.pmk_len +
- (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+ (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+ (params->n_mlo_links ? params->n_mlo_links *
+ sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);
if (!ev) {
cfg80211_put_bss(wdev->wiphy, params->bss);
return;
@@ -880,6 +898,14 @@ void cfg80211_connect_done(struct net_device *dev,
WLAN_PMKID_LEN);
next += WLAN_PMKID_LEN;
}
+ if (params->n_mlo_links) {
+ ev->cr.mlo_links = (struct cfg80211_mlo_link_device_params *)next;
+ memcpy((void *)ev->cr.mlo_links, params->mlo_links,
+ params->n_mlo_links *
+ sizeof(struct cfg80211_mlo_link_device_params));
+ next += params->n_mlo_links *
+ sizeof(struct cfg80211_mlo_link_device_params);
+ }
ev->cr.fils.update_erp_next_seq_num = params->fils.update_erp_next_seq_num;
if (params->fils.update_erp_next_seq_num)
ev->cr.fils.erp_next_seq_num = params->fils.erp_next_seq_num;
@@ -888,6 +914,7 @@ void cfg80211_connect_done(struct net_device *dev,
ev->cr.bss = params->bss;
ev->cr.status = params->status;
ev->cr.timeout_reason = params->timeout_reason;
+ ev->cr.n_mlo_links = params->n_mlo_links;
spin_lock_irqsave(&wdev->event_lock, flags);
list_add_tail(&ev->list, &wdev->event_list);
@@ -1077,7 +1104,7 @@ EXPORT_SYMBOL(cfg80211_port_authorized);
void __cfg80211_disconnected(struct net_device *dev, const u8 *ie,
size_t ie_len, u16 reason, bool from_ap)
{
- struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct wireless_dev *wdev = dev->ieee80211_ptr, *mlo_wdev;
struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
int i;
#ifdef CONFIG_CFG80211_WEXT
@@ -1136,6 +1163,18 @@ void __cfg80211_disconnected(struct net_device *dev, const u8 *ie,
wdev->wext.connect.ssid_len = 0;
#endif
+ list_for_each_entry(mlo_wdev, &wdev->mlo_link_wdev_list, mlo_list) {
+ cfg80211_stop_mlo_link_device(wiphy_to_rdev(mlo_wdev->wiphy), mlo_wdev);
+ list_del_rcu(&mlo_wdev->mlo_list);
+ mlo_wdev->mld_wdev = NULL;
+ if (mlo_wdev->current_bss) {
+ cfg80211_unhold_bss(mlo_wdev->current_bss);
+ cfg80211_put_bss(mlo_wdev->wiphy, &wdev->current_bss->pub);
+ }
+ mlo_wdev->current_bss = NULL;
+ mlo_wdev->ssid_len = 0;
+ }
+
schedule_work(&cfg80211_disconnect_work);
}
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 817c6fe..93f06eb 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2139,6 +2139,11 @@ TRACE_EVENT(rdev_set_mac_acl,
WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->acl_policy)
);
+DEFINE_EVENT(wiphy_wdev_evt, rdev_stop_mlo_link_device,
+ TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev),
+ TP_ARGS(wiphy, wdev)
+);
+
TRACE_EVENT(rdev_update_ft_ies,
TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
struct cfg80211_update_ft_ies_params *ftie),
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 5af8803..c592bb7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1017,6 +1017,8 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
WLAN_REASON_DEAUTH_LEAVING, true);
wdev_unlock(dev->ieee80211_ptr);
break;
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
+ break;
case NL80211_IFTYPE_MESH_POINT:
/* mesh should be handled? */
break;
@@ -1065,6 +1067,8 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
case NL80211_IFTYPE_NAN:
WARN_ON(1);
break;
+ case NL80211_IFTYPE_MLO_LINK_DEVICE:
+ break;
}
}
--
2.7.4
Hi,
> Multi-link support is introduced in 802.11be specification.
[...]
I'll definitely have to take a closer look at this and the spec and
think about it - but a couple of quick comments below.
> @@ -3131,6 +3139,7 @@ enum nl80211_iftype {
> NL80211_IFTYPE_P2P_DEVICE,
> NL80211_IFTYPE_OCB,
> NL80211_IFTYPE_NAN,
> + NL80211_IFTYPE_MLO_LINK_DEVICE,
You'll probably have to update some mac80211 code in this patch to avoid
compiler warnings.
> +void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev,
> + struct wireless_dev *wdev)
> +{
> + ASSERT_RTNL();
> +
> + if (WARN_ON(wdev->iftype != NL80211_IFTYPE_MLO_LINK_DEVICE))
> + return;
> +
> + if (!wdev_running(wdev))
> + return;
> +
> + rdev_stop_mlo_link_device(rdev, wdev);
> + wdev->is_running = false;
> +
> + rdev->opencount--;
> +
> + if (rdev->scan_req && rdev->scan_req->wdev == wdev) {
> + if (WARN_ON(!rdev->scan_req->notified &&
> + (!rdev->int_scan_req ||
> + !rdev->int_scan_req->notified)))
> + rdev->scan_req->info.aborted = true;
> + ___cfg80211_scan_done(rdev, false);
> + }
Does it even make sense to allow scanning on this wdev, rather than on
the normal client interfaces? Perhaps should just not be able to get
there?
> @@ -718,6 +718,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
> [NL80211_ATTR_SAE_PWE] =
> NLA_POLICY_RANGE(NLA_U8, NL80211_SAE_PWE_HUNT_AND_PECK,
> NL80211_SAE_PWE_BOTH),
> + [NL80211_ATTR_MLO_LINK_INFO] = { .type = NLA_NESTED },
That should specify what/how it's nested, using
NLA_POLICY_NESTED_ARRAY() (I think, in this case)
> struct sk_buff *msg;
> void *hdr;
> + struct nlattr *nested, *nested_mlo_links;
> + struct cfg80211_mlo_link_device_params *mlo_link;
> + int i = 0;
>
> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
> cr->fils.kek_len + cr->fils.pmk_len +
> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
32 probably should be some NLA_SIZE or something constant?
There's also no point in the ternary operator since 0 * 32 is 0 :)
> /* Consumes bss object one way or another */
> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,
> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
> params->req_ie_len + params->resp_ie_len +
> params->fils.kek_len + params->fils.pmk_len +
> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
> + (params->n_mlo_links ? params->n_mlo_links *
> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);
same here, no need for the ternary
It feels strangely asymmetric to have stop and no start ... but I guess
that's the part where I need to think about it and look a bit at how it
all works :)
johannes
On 09-12-2020 16:36, Johannes Berg wrote:
> Hi,
>
>> Multi-link support is introduced in 802.11be specification.
> [...]
>
> I'll definitely have to take a closer look at this and the spec and
> think about it - but a couple of quick comments below.
Did not get my hands on the spec yet, but just firing random thoughts.
This multi-link support sounds a bit like bonding. Could that be
leveraged for wireless? I wonder why there is a need for a non-netdev
interface. Does networking layer need to be aware of the multi-link for
scheduling traffic to it? Is there one driver per multi-link or per radio?
[...]
>> struct sk_buff *msg;
>> void *hdr;
>> + struct nlattr *nested, *nested_mlo_links;
>> + struct cfg80211_mlo_link_device_params *mlo_link;
>> + int i = 0;
>>
>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
>> cr->fils.kek_len + cr->fils.pmk_len +
>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
>
> 32 probably should be some NLA_SIZE or something constant?
Probably sizeof(*mlo_link) ?
> There's also no point in the ternary operator since 0 * 32 is 0 :)
>
>> /* Consumes bss object one way or another */
>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,
>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
>> params->req_ie_len + params->resp_ie_len +
>> params->fils.kek_len + params->fils.pmk_len +
>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>> + (params->n_mlo_links ? params->n_mlo_links *
>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);
>
> same here, no need for the ternary
>
>
> It feels strangely asymmetric to have stop and no start ... but I guess
> that's the part where I need to think about it and look a bit at how it
> all works :)
Had the same feeling in my gutt (wherever that is ;-)
Regards,
Arend
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
On 2020-12-14 14:55, Arend van Spriel wrote:
> On 09-12-2020 16:36, Johannes Berg wrote:
>> Hi,
>>
>>> Multi-link support is introduced in 802.11be specification.
>> [...]
>>
>> I'll definitely have to take a closer look at this and the spec and
>> think about it - but a couple of quick comments below.
Thanks for your comments. Please allow me to address your comments in
the subsequent patches.
Our main intention through this RFC is to get the view on the proposal
to introduce a new NL80211_IFTYPE for an MLO Link.
Please suggest on this.
> Did not get my hands on the spec yet, but just firing random thoughts.
> This multi-link support sounds a bit like bonding. Could that be
> leveraged for wireless? I wonder why there is a need for a non-netdev
> interface. Does networking layer need to be aware of the multi-link
> for scheduling traffic to it? Is there one driver per multi-link or
> per radio?
The following is what the Bonding driver / interface does for the
multiple network interfaces.
1. Bonding driver aggregates multiple network interfaces into a single
logical bonded interface.
2. Each network interface is called as a slave in the bonding driver.
3. It’s the Bonding driver that schedules the traffic across these
slaves.
4. Bonding interface operates on one of the following modes ( mentioning
for a quick reference ).
balance-rr : Round-robin policy: Transmit packets in sequential
order from the first available slave through the last.
active-backup : Only one slave in the bond is active. A different
slave becomes active if, and only if, the active slave fails.
balance-xor : Transmit based on the selected transmit hash
policy.
balance-tlb : channel bonding that does not require any special
switch support. The outgoing traffic is distributed according to the
current load
balance-alb : includes balance-tlb plus receive load balancing.
5. With the above modes, the scheduling of the traffic is determined
with in the kernel / bonding driver and have the host driver / firmware
follow it.
The following are the factors for not considering the MLO Link as a
bonding interface and further to propose this RFC
(new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).
1. For MLO, our intention is to allow the traffic scheduling (among the
MLO links) to be closer to the lower layers in
the driver/firmware, etc, unlike the bonding driver where kernel
schedules the traffic.
2. If MLO Link has to use a bonding interface, each MLO link has to be
associated with a network interface and thus each
of the MLO link has to be of NL80211_IF_TYPE ->
NL80211_IFTYPE_STATION.
3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs to
get triggered on each of this MLO Link of the
MLO connection.
4. Our intention is to consider the MLO station as a single network
interface . More specifically, have a single
NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO
connection ( MLD + MLO Links).
5. The reason we had to introduce a new NL80211_IF_TYPE ->
NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
link connection specific information ( e.g., Connection State,
Connected BSS Info, Connection Frequency/properties, etc),
for each wdev / MLO Link and at the same time have a single
connect / association request to the driver / AP.
6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall
represent an MLO Link and attribute to a network interface ( MLD ) of an
MLO connection.
7. The current proposal to introduce a new NL80211_IF_TYPE should
support the architectures of MLO links across the multiple wiphy
interfaces or on the same wiphy interface. These wiphy
interfaces can be from different drivers too.
Please review the above.
>
> [...]
>
>>> struct sk_buff *msg;
>>> void *hdr;
>>> + struct nlattr *nested, *nested_mlo_links;
>>> + struct cfg80211_mlo_link_device_params *mlo_link;
>>> + int i = 0;
>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
>>> cr->fils.kek_len + cr->fils.pmk_len +
>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
>>
>> 32 probably should be some NLA_SIZE or something constant?
>
> Probably sizeof(*mlo_link) ?
>
>> There's also no point in the ternary operator since 0 * 32 is 0 :)
>>
>>> /* Consumes bss object one way or another */
>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device
>>> *dev,
>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
>>> params->req_ie_len + params->resp_ie_len +
>>> params->fils.kek_len + params->fils.pmk_len +
>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>> + (params->n_mlo_links ? params->n_mlo_links *
>>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);
>>
>> same here, no need for the ternary
>>
>>
>> It feels strangely asymmetric to have stop and no start ... but I
>> guess
>> that's the part where I need to think about it and look a bit at how
>> it
>> all works :)
>
> Had the same feeling in my gutt (wherever that is ;-)
Sure. Will take this point. In fact, this was documented in the commit
message to consider the start (say start_mlo_link), but do not want the
drivers to depend on this trigger for starting the MLO link.
For example, the host drivers with SME can as well start the MLO Link
after getting the Assoc response for MLO links from the AP.
>
> Regards,
> Arend
On 2020-12-23 21:59, [email protected] wrote:
> On 2020-12-14 14:55, Arend van Spriel wrote:
>> On 09-12-2020 16:36, Johannes Berg wrote:
>>> Hi,
>>>
>>>> Multi-link support is introduced in 802.11be specification.
>>> [...]
>>>
>>> I'll definitely have to take a closer look at this and the spec and
>>> think about it - but a couple of quick comments below.
>
> Thanks for your comments. Please allow me to address your comments in
> the subsequent patches.
> Our main intention through this RFC is to get the view on the proposal
> to introduce a new NL80211_IFTYPE for an MLO Link.
> Please suggest on this.
>
>
>> Did not get my hands on the spec yet, but just firing random thoughts.
>> This multi-link support sounds a bit like bonding. Could that be
>> leveraged for wireless? I wonder why there is a need for a non-netdev
>> interface. Does networking layer need to be aware of the multi-link
>> for scheduling traffic to it? Is there one driver per multi-link or
>> per radio?
>
> The following is what the Bonding driver / interface does for the
> multiple network interfaces.
> 1. Bonding driver aggregates multiple network interfaces into a single
> logical bonded interface.
> 2. Each network interface is called as a slave in the bonding driver.
> 3. It’s the Bonding driver that schedules the traffic across these
> slaves.
> 4. Bonding interface operates on one of the following modes (
> mentioning for a quick reference ).
> balance-rr : Round-robin policy: Transmit packets in sequential
> order from the first available slave through the last.
> active-backup : Only one slave in the bond is active. A
> different slave becomes active if, and only if, the active slave
> fails.
> balance-xor : Transmit based on the selected transmit hash
> policy.
> balance-tlb : channel bonding that does not require any special
> switch support. The outgoing traffic is distributed according to the
> current load
> balance-alb : includes balance-tlb plus receive load balancing.
> 5. With the above modes, the scheduling of the traffic is determined
> with in the kernel / bonding driver and have the host driver /
> firmware follow it.
>
> The following are the factors for not considering the MLO Link as a
> bonding interface and further to propose this RFC
> (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).
>
> 1. For MLO, our intention is to allow the traffic scheduling (among
> the MLO links) to be closer to the lower layers in
> the driver/firmware, etc, unlike the bonding driver where
> kernel schedules the traffic.
> 2. If MLO Link has to use a bonding interface, each MLO link has to be
> associated with a network interface and thus each
> of the MLO link has to be of NL80211_IF_TYPE ->
> NL80211_IFTYPE_STATION.
> 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs
> to get triggered on each of this MLO Link of the
> MLO connection.
> 4. Our intention is to consider the MLO station as a single network
> interface . More specifically, have a single
> NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO
> connection ( MLD + MLO Links).
> 5. The reason we had to introduce a new NL80211_IF_TYPE ->
> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
> link connection specific information ( e.g., Connection State,
> Connected BSS Info, Connection Frequency/properties, etc),
> for each wdev / MLO Link and at the same time have a single
> connect / association request to the driver / AP.
> 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall
> represent an MLO Link and attribute to a network interface ( MLD ) of
> an
> MLO connection.
> 7. The current proposal to introduce a new NL80211_IF_TYPE should
> support the architectures of MLO links across the multiple wiphy
> interfaces or on the same wiphy interface. These wiphy
> interfaces can be from different drivers too.
>
> Please review the above.
>
>>
>> [...]
>>
>>>> struct sk_buff *msg;
>>>> void *hdr;
>>>> + struct nlattr *nested, *nested_mlo_links;
>>>> + struct cfg80211_mlo_link_device_params *mlo_link;
>>>> + int i = 0;
>>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
>>>> cr->fils.kek_len + cr->fils.pmk_len +
>>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
>>>
>>> 32 probably should be some NLA_SIZE or something constant?
>>
>> Probably sizeof(*mlo_link) ?
>>
>>> There's also no point in the ternary operator since 0 * 32 is 0 :)
>>>
>>>> /* Consumes bss object one way or another */
>>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device
>>>> *dev,
>>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
>>>> params->req_ie_len + params->resp_ie_len +
>>>> params->fils.kek_len + params->fils.pmk_len +
>>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>> + (params->n_mlo_links ? params->n_mlo_links *
>>>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);
>>>
>>> same here, no need for the ternary
>>>
>>>
>>> It feels strangely asymmetric to have stop and no start ... but I
>>> guess
>>> that's the part where I need to think about it and look a bit at how
>>> it
>>> all works :)
>>
>> Had the same feeling in my gutt (wherever that is ;-)
>
> Sure. Will take this point. In fact, this was documented in the commit
> message to consider the start (say start_mlo_link), but do not want
> the drivers to depend on this trigger for starting the MLO link.
> For example, the host drivers with SME can as well start the MLO Link
> after getting the Assoc response for MLO links from the AP.
>
>
>>
>> Regards,
>> Arend
Hi,
Can you please provide your comments on the proposal.
We wanted to hear your feedback on the following points.
Represent MLO link of an MLO connection by a wdev of type
NL80211_IFTYPE_MLO_LINK_DEVICE.
MLO link wdev does not have an active netdev associated to it but will
be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s
connection information ( connected channel , BSSID, etc).
MLD interface of an MLO connection will be a station interface
(NL80211_IFTYPE_STATION wdev) This station interface shall link the
wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211
layer shall link all such wdev’s.
Such MLO Link wdev’s shall be part of the same wiphy or different wiphy
(if host driver's register a single wiphy for each supported
band/MAC/PHY).
MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user
space prior the MLO connection.
User space can as well change the interface type among
NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To
support the use case where an existing STA wdev can change to a MLO wdev
and vice versa.
Regards,
Sunil
On 2/9/2021 3:48 PM, [email protected] wrote:
> On 2020-12-23 21:59, [email protected] wrote:
>> On 2020-12-14 14:55, Arend van Spriel wrote:
>>> On 09-12-2020 16:36, Johannes Berg wrote:
>>>> Hi,
>>>>
>>>>> Multi-link support is introduced in 802.11be specification.
>>>> [...]
>>>>
>>>> I'll definitely have to take a closer look at this and the spec and
>>>> think about it - but a couple of quick comments below.
>>
>> Thanks for your comments. Please allow me to address your comments in
>> the subsequent patches.
>> Our main intention through this RFC is to get the view on the proposal
>> to introduce a new NL80211_IFTYPE for an MLO Link.
>> Please suggest on this.
>>
>>
>>> Did not get my hands on the spec yet, but just firing random thoughts.
>>> This multi-link support sounds a bit like bonding. Could that be
>>> leveraged for wireless? I wonder why there is a need for a non-netdev
>>> interface. Does networking layer need to be aware of the multi-link
>>> for scheduling traffic to it? Is there one driver per multi-link or
>>> per radio?
>>
>> The following is what the Bonding driver / interface does for the
>> multiple network interfaces.
>> 1. Bonding driver aggregates multiple network interfaces into a single
>> logical bonded interface.
>> 2. Each network interface is called as a slave in the bonding driver.
>> 3. It’s the Bonding driver that schedules the traffic across these
>> slaves.
>> 4. Bonding interface operates on one of the following modes (
>> mentioning for a quick reference ).
>> balance-rr : Round-robin policy: Transmit packets in sequential
>> order from the first available slave through the last.
>> active-backup : Only one slave in the bond is active. A
>> different slave becomes active if, and only if, the active slave
>> fails.
>> balance-xor : Transmit based on the selected transmit hash policy.
>> balance-tlb : channel bonding that does not require any special
>> switch support. The outgoing traffic is distributed according to the
>> current load
>> balance-alb : includes balance-tlb plus receive load balancing.
>> 5. With the above modes, the scheduling of the traffic is determined
>> with in the kernel / bonding driver and have the host driver /
>> firmware follow it.
>>
>> The following are the factors for not considering the MLO Link as a
>> bonding interface and further to propose this RFC
>> (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).
>>
>> 1. For MLO, our intention is to allow the traffic scheduling (among
>> the MLO links) to be closer to the lower layers in
>> the driver/firmware, etc, unlike the bonding driver where
>> kernel schedules the traffic.
>> 2. If MLO Link has to use a bonding interface, each MLO link has to be
>> associated with a network interface and thus each
>> of the MLO link has to be of NL80211_IF_TYPE ->
>> NL80211_IFTYPE_STATION.
>> 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs
>> to get triggered on each of this MLO Link of the
>> MLO connection.
>> 4. Our intention is to consider the MLO station as a single network
>> interface . More specifically, have a single
>> NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO
>> connection ( MLD + MLO Links).
>> 5. The reason we had to introduce a new NL80211_IF_TYPE ->
>> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
>> link connection specific information ( e.g., Connection State,
>> Connected BSS Info, Connection Frequency/properties, etc),
>> for each wdev / MLO Link and at the same time have a single
>> connect / association request to the driver / AP.
>> 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall
>> represent an MLO Link and attribute to a network interface ( MLD ) of
>> an
>> MLO connection.
>> 7. The current proposal to introduce a new NL80211_IF_TYPE should
>> support the architectures of MLO links across the multiple wiphy
>> interfaces or on the same wiphy interface. These wiphy
>> interfaces can be from different drivers too.
>>
>> Please review the above.
>>
>>>
>>> [...]
>>>
>>>>> struct sk_buff *msg;
>>>>> void *hdr;
>>>>> + struct nlattr *nested, *nested_mlo_links;
>>>>> + struct cfg80211_mlo_link_device_params *mlo_link;
>>>>> + int i = 0;
>>>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
>>>>> cr->fils.kek_len + cr->fils.pmk_len +
>>>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
>>>>
>>>> 32 probably should be some NLA_SIZE or something constant?
>>>
>>> Probably sizeof(*mlo_link) ?
>>>
>>>> There's also no point in the ternary operator since 0 * 32 is 0 :)
>>>>
>>>>> /* Consumes bss object one way or another */
>>>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,
>>>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
>>>>> params->req_ie_len + params->resp_ie_len +
>>>>> params->fils.kek_len + params->fils.pmk_len +
>>>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>>> + (params->n_mlo_links ? params->n_mlo_links *
>>>>> + sizeof(struct cfg80211_mlo_link_device_params) : 0),
>>>>> gfp);
>>>>
>>>> same here, no need for the ternary
>>>>
>>>>
>>>> It feels strangely asymmetric to have stop and no start ... but I guess
>>>> that's the part where I need to think about it and look a bit at how it
>>>> all works :)
>>>
>>> Had the same feeling in my gutt (wherever that is ;-)
>>
>> Sure. Will take this point. In fact, this was documented in the commit
>> message to consider the start (say start_mlo_link), but do not want
>> the drivers to depend on this trigger for starting the MLO link.
>> For example, the host drivers with SME can as well start the MLO Link
>> after getting the Assoc response for MLO links from the AP.
>>
>>
>>>
>>> Regards,
>>> Arend
>
> Hi,
>
> Can you please provide your comments on the proposal.
> We wanted to hear your feedback on the following points.
>
> Represent MLO link of an MLO connection by a wdev of type
> NL80211_IFTYPE_MLO_LINK_DEVICE.
> MLO link wdev does not have an active netdev associated to it but will
> be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s
> connection information ( connected channel , BSSID, etc).
> MLD interface of an MLO connection will be a station interface
> (NL80211_IFTYPE_STATION wdev) This station interface shall link the
> wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211
> layer shall link all such wdev’s.
> Such MLO Link wdev’s shall be part of the same wiphy or different wiphy
> (if host driver's register a single wiphy for each supported band/MAC/PHY).
> MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user
> space prior the MLO connection.
From your explanation earlier it makes more sense to me now.
> User space can as well change the interface type among
> NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To
> support the use case where an existing STA wdev can change to a MLO wdev
> and vice versa.
This seems complicated especially for the "vice versa" scenario where
wdevs may be linked to it across different wiphy instances. btw. would
that also mean different drivers. I suspect it does, right?
Your explanation seems to focus on the station side of the MLO link, but
I think on the AP side one would also setup a MLO link. Would the MLD
interface be an AP interface in that case?
Actually, if I am not too confused here then what you call an "MLO link"
device is called MLD in the spec.:
"""
multi-link device (MLD): A device that is a logical entity and has more
than one affiliated station (STA) and has a single medium access control
(MAC) service access point (SAP) to logical link control (LLC), which
includes one MAC data service.
"""
The spec refers to AP MLD and non-AP MLD.
Regards,
Arend
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
On 2021-02-09 21:12, Arend Van Spriel wrote:
> On 2/9/2021 3:48 PM, [email protected] wrote:
>> On 2020-12-23 21:59, [email protected] wrote:
>>> On 2020-12-14 14:55, Arend van Spriel wrote:
>>>> On 09-12-2020 16:36, Johannes Berg wrote:
>>>>> Hi,
>>>>>
>>>>>> Multi-link support is introduced in 802.11be specification.
>>>>> [...]
>>>>>
>>>>> I'll definitely have to take a closer look at this and the spec and
>>>>> think about it - but a couple of quick comments below.
>>>
>>> Thanks for your comments. Please allow me to address your comments in
>>> the subsequent patches.
>>> Our main intention through this RFC is to get the view on the
>>> proposal
>>> to introduce a new NL80211_IFTYPE for an MLO Link.
>>> Please suggest on this.
>>>
>>>
>>>> Did not get my hands on the spec yet, but just firing random
>>>> thoughts.
>>>> This multi-link support sounds a bit like bonding. Could that be
>>>> leveraged for wireless? I wonder why there is a need for a
>>>> non-netdev
>>>> interface. Does networking layer need to be aware of the multi-link
>>>> for scheduling traffic to it? Is there one driver per multi-link or
>>>> per radio?
>>>
>>> The following is what the Bonding driver / interface does for the
>>> multiple network interfaces.
>>> 1. Bonding driver aggregates multiple network interfaces into a
>>> single
>>> logical bonded interface.
>>> 2. Each network interface is called as a slave in the bonding driver.
>>> 3. It’s the Bonding driver that schedules the traffic across these
>>> slaves.
>>> 4. Bonding interface operates on one of the following modes (
>>> mentioning for a quick reference ).
>>> balance-rr : Round-robin policy: Transmit packets in
>>> sequential
>>> order from the first available slave through the last.
>>> active-backup : Only one slave in the bond is active. A
>>> different slave becomes active if, and only if, the active slave
>>> fails.
>>> balance-xor : Transmit based on the selected transmit hash
>>> policy.
>>> balance-tlb : channel bonding that does not require any
>>> special
>>> switch support. The outgoing traffic is distributed according to the
>>> current load
>>> balance-alb : includes balance-tlb plus receive load
>>> balancing.
>>> 5. With the above modes, the scheduling of the traffic is determined
>>> with in the kernel / bonding driver and have the host driver /
>>> firmware follow it.
>>>
>>> The following are the factors for not considering the MLO Link as a
>>> bonding interface and further to propose this RFC
>>> (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).
>>>
>>> 1. For MLO, our intention is to allow the traffic scheduling (among
>>> the MLO links) to be closer to the lower layers in
>>> the driver/firmware, etc, unlike the bonding driver where
>>> kernel schedules the traffic.
>>> 2. If MLO Link has to use a bonding interface, each MLO link has to
>>> be
>>> associated with a network interface and thus each
>>> of the MLO link has to be of NL80211_IF_TYPE ->
>>> NL80211_IFTYPE_STATION.
>>> 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs
>>> to get triggered on each of this MLO Link of the
>>> MLO connection.
>>> 4. Our intention is to consider the MLO station as a single network
>>> interface . More specifically, have a single
>>> NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each
>>> MLO
>>> connection ( MLD + MLO Links).
>>> 5. The reason we had to introduce a new NL80211_IF_TYPE ->
>>> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
>>> link connection specific information ( e.g., Connection State,
>>> Connected BSS Info, Connection Frequency/properties, etc),
>>> for each wdev / MLO Link and at the same time have a single
>>> connect / association request to the driver / AP.
>>> 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall
>>> represent an MLO Link and attribute to a network interface ( MLD ) of
>>> an
>>> MLO connection.
>>> 7. The current proposal to introduce a new NL80211_IF_TYPE should
>>> support the architectures of MLO links across the multiple wiphy
>>> interfaces or on the same wiphy interface. These wiphy
>>> interfaces can be from different drivers too.
>>>
>>> Please review the above.
>>>
>>>>
>>>> [...]
>>>>
>>>>>> struct sk_buff *msg;
>>>>>> void *hdr;
>>>>>> + struct nlattr *nested, *nested_mlo_links;
>>>>>> + struct cfg80211_mlo_link_device_params *mlo_link;
>>>>>> + int i = 0;
>>>>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
>>>>>> cr->fils.kek_len + cr->fils.pmk_len +
>>>>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);
>>>>>
>>>>> 32 probably should be some NLA_SIZE or something constant?
>>>>
>>>> Probably sizeof(*mlo_link) ?
>>>>
>>>>> There's also no point in the ternary operator since 0 * 32 is 0 :)
>>>>>
>>>>>> /* Consumes bss object one way or another */
>>>>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device
>>>>>> *dev,
>>>>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
>>>>>> params->req_ie_len + params->resp_ie_len +
>>>>>> params->fils.kek_len + params->fils.pmk_len +
>>>>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
>>>>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
>>>>>> + (params->n_mlo_links ? params->n_mlo_links *
>>>>>> + sizeof(struct cfg80211_mlo_link_device_params) :
>>>>>> 0), gfp);
>>>>>
>>>>> same here, no need for the ternary
>>>>>
>>>>>
>>>>> It feels strangely asymmetric to have stop and no start ... but I
>>>>> guess
>>>>> that's the part where I need to think about it and look a bit at
>>>>> how it
>>>>> all works :)
>>>>
>>>> Had the same feeling in my gutt (wherever that is ;-)
>>>
>>> Sure. Will take this point. In fact, this was documented in the
>>> commit
>>> message to consider the start (say start_mlo_link), but do not want
>>> the drivers to depend on this trigger for starting the MLO link.
>>> For example, the host drivers with SME can as well start the MLO Link
>>> after getting the Assoc response for MLO links from the AP.
>>>
>>>
>>>>
>>>> Regards,
>>>> Arend
>>
>> Hi,
>>
>> Can you please provide your comments on the proposal.
>> We wanted to hear your feedback on the following points.
>>
>> Represent MLO link of an MLO connection by a wdev of type
>> NL80211_IFTYPE_MLO_LINK_DEVICE.
>> MLO link wdev does not have an active netdev associated to it but will
>> be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s
>> connection information ( connected channel , BSSID, etc).
>> MLD interface of an MLO connection will be a station interface
>> (NL80211_IFTYPE_STATION wdev) This station interface shall link the
>> wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211
>> layer shall link all such wdev’s.
>> Such MLO Link wdev’s shall be part of the same wiphy or different
>> wiphy (if host driver's register a single wiphy for each supported
>> band/MAC/PHY).
>> MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user
>> space prior the MLO connection.
>
> From your explanation earlier it makes more sense to me now.
>
>> User space can as well change the interface type among
>> NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To
>> support the use case where an existing STA wdev can change to a MLO
>> wdev and vice versa.
>
> This seems complicated especially for the "vice versa" scenario where
> wdevs may be linked to it across different wiphy instances. btw. would
> that also mean different drivers. I suspect it does, right?
The switch / change interface among the STA or MLO Link shall happen
only in the disconnected state.
At this point, (in the disconnected state) these MLO Link wdev’s are not
linked to the STA interface ( either on the same / different wiphy ).
These shall be linked after the Association to an MLO AP.
The intention here is to have the wdev in the right mode ( STA or MLO
Link ) before the connect / Association is triggered.
This wdev is put in to a MLO_LINK_DEVICE, before the connect /
association is triggered on the respective MLD (IFTYPE_STA) interface
for an MLO connection.
This wdev is put in the IFTYPE_STA mode, before triggering a connect /
association on this interface.
This should be applicable for different drivers too.
Please let us know if there are any caveats in this design
>
> Your explanation seems to focus on the station side of the MLO link,
> but I think on the AP side one would also setup a MLO link. Would the
> MLD interface be an AP interface in that case?
Yes.
The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link”
on the non-AP MLD.This would not be required for an AP MLO.
The following explains our design for AP.
For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance for
non-MLO / legacy client and an MLO link for AP-MLD.
To be specific, For a 2 link AP MLD , there will be 2 NL80211_IFTYPE_AP
wdev's created.
Both these wdev’s shall represent the MLO Link for an AP-MLD and each
also represent an AP instance for the non-MLO / legacy client’s to
connect.
MLO Link MAC address will be the MAC address of respective AP’s
(netdev/wdev).
A non-MLO client can connect to the respective AP instance, while the
non AP MLD connect’ s to the MLD AP by authenticating on either of the
AP (links).
> Actually, if I am not too confused here then what you call an "MLO
> link" device is called MLD in the spec.:
>
> """
> multi-link device (MLD): A device that is a logical entity and has
> more than one affiliated station (STA) and has a single medium access
> control (MAC) service access point (SAP) to logical link control
> (LLC), which includes one MAC data service.
> """
>
> The spec refers to AP MLD and non-AP MLD.
“MLO link” here refers to the link which is defined as the connectivity
between an AP-STA and the non-AP STA.
A multi-link device (MLD) consists of more than one STAs. An AP-MLD
consists of more than one AP STAs, and a non-AP MLD consists of one or
more non-AP STAs.
There can be multiple links between the AP and non-AP STAs for an MLD
and each of these links are referred by “MLO link”.
Currently , NL80211_IFTYPE_STATION wdev represents the non MLD client /
legacy connection to the non-MLD AP.
With this proposal, We plan to extend this for MLO too, by reusing this
NL80211_IFTYPE_STATION wdev to represent the “association link” for an
MLD connection
and new wdev type - NL80211_IFTYPE_MLO_LINK_DEVICE to represent the
additional links of the same MLD connection.
(e.g., These MLO Links represent multiple links – Link2, link3 and Link1
of MLD connection from “Example of multi-link setup” – Figure 35-2 of
D0.2 11be spec)
Regards,
Sunil
Hi,
Sorry for being so late on the thread. Took me far longer than I wanted
to get into looking at MLO at all.
> The switch / change interface among the STA or MLO Link shall happen
> only in the disconnected state.
> At this point, (in the disconnected state) these MLO Link wdev’s are not
> linked to the STA interface ( either on the same / different wiphy ).
> These shall be linked after the Association to an MLO AP.
> The intention here is to have the wdev in the right mode ( STA or MLO
> Link ) before the connect / Association is triggered.
> This wdev is put in to a MLO_LINK_DEVICE, before the connect /
> association is triggered on the respective MLD (IFTYPE_STA) interface
> for an MLO connection.
> This wdev is put in the IFTYPE_STA mode, before triggering a connect /
> association on this interface.
>
> This should be applicable for different drivers too.
>
> Please let us know if there are any caveats in this design
Just to summarize, to see if I'm understanding it correctly.
You're basically saying that on the client side
1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with whatever
MAC address it may have, and does not maintain its "own" association
to an AP;
2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the DEVICE
it's long enough) are added to it, with appropriate link addresses
selected for them;
3) this configuration can only happen while none of them are connected.
Right?
Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK
could share a MAC address with the MLD (_STATION), although I hear that
there's still a discussion right now on MLD-addressed and link-addressed
management frames, so I think we need to wait until we know that for
sure.
A couple of questions:
1) How do we present this to userspace, is that it? Wouldn't the
_STATION (MLD) interface ideally still have *some* visible wireless
state, and show which network it's connected to? It might be very
awkward to require all userspace tools to be updated to know about
and query for _MLO_LINKs.
Obviously, wpa_supplicant needs to be aware of these and can handle
it just fine, so I'm more concerned about other userspace. After
all, people still use tools built on wireless extensions
2) In some ways related to 1), but in other ways also not - perhaps we
need to anticipate that some devices will want to handle MLO link
decisions in firmware? I haven't thought about this much at all, but
if we require separate MLO_LINK type wdevs for each link that might
be tricky?
3) I keep thinking about moving much "associated" state into the STA
struct we maintain in the kernel, and actually maintaining the
*links* only as "multiple associations". This also gets tricky with
the link MAC addresses in a way, though that could be handled. It
might also be an easier way to manage some of that state problem
from my question 1)?
Any thoughts on this? I'm definitely not saying this would be easy,
but would it simplify things regarding the userspace APIs and the
offload question in 2)?
Any other designs than the MLO_LINK wdev that you have considered
and discarded, and if so for which reasons?
> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link”
> on the non-AP MLD.This would not be required for an AP MLO.
FWIW, I don't buy the part about this not being required for an AP MLD.
> The following explains our design for AP.
> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance for
> non-MLO / legacy client and an MLO link for AP-MLD.
> To be specific, For a 2 link AP MLD , there will be 2 NL80211_IFTYPE_AP
> wdev's created.
This will not work if there's a need (and possibly spec requirement) to
have an MLD address that's different from *all* the link addresses. It
will also be difficult to manage that one of the AP interfaces would
have to be defacto the MLD, but (at least in theory) any one of the AP
interfaces could be removed for 'degraded' operation.
I suspect will also not work right if you want to have AP_VLAN on the AP
MLD.
IMHO it'd be better for things to be symmetric like you suggest for the
client side.
Now, I can see the need for legacy interoperability, but then it seems
it would probably be better to do this the other way around and declare
a new AP_MLD interface type (with a netdev) that doesn't maintain its
own beacons etc. but just has its own MAC address (the AP MLD address)
and bubbles up the data frames exchanged on the MLD.
> Both these wdev’s shall represent the MLO Link for an AP-MLD and each
> also represent an AP instance for the non-MLO / legacy client’s to
> connect.
Yeah, don't think that works, see above.
> MLO Link MAC address will be the MAC address of respective AP’s
> (netdev/wdev).
Same here. Note that there may be a requirement, or at least a very
strong incentive, to have an MLD address different from all the links,
and we cannot preclude that in the design even if it doesn't become a
requirement.
> With this proposal, We plan to extend this for MLO too, by reusing this
> NL80211_IFTYPE_STATION wdev to represent the “association link” for an
> MLD connection
> and new wdev type - NL80211_IFTYPE_MLO_LINK_DEVICE to represent the
> additional links of the same MLD connection.
Wait, ok, this is *not* how I understood the proposal above.
Again, I don't think this works for the same reasons I outlined on the
AP case - symmetry, links coming and going, and MAC addressing.
johannes
Hi ,
Thanks for your response.
>> The switch / change interface among the STA or MLO Link shall happen
>> only in the disconnected state.
>> At this point, (in the disconnected state) these MLO Link wdev’s are
>> not
>> linked to the STA interface ( either on the same / different wiphy ).
>> These shall be linked after the Association to an MLO AP.
>> The intention here is to have the wdev in the right mode ( STA or MLO
>> Link ) before the connect / Association is triggered.
>> This wdev is put in to a MLO_LINK_DEVICE, before the connect /
>> association is triggered on the respective MLD (IFTYPE_STA) interface
>> for an MLO connection.
>> This wdev is put in the IFTYPE_STA mode, before triggering a connect /
>> association on this interface.
>>
>> This should be applicable for different drivers too.
>>
>> Please let us know if there are any caveats in this design
>
>
> Just to summarize, to see if I'm understanding it correctly.
>
> You're basically saying that on the client side
>
> 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with whatever
> MAC address it may have, and does not maintain its "own"
> association
> to an AP;
> 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the DEVICE
> it's long enough) are added to it, with appropriate link addresses
> selected for them;
> 3) this configuration can only happen while none of them are
> connected.
>
> Right?
No . Our intention was the NL80211_IFTYPE_STATION interface to also
represent
the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents
other MLO
Links of an MLO connection.
This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev
shall
link all such MLO_LINK’s which are part of the same MLD connection.
That way , there will be a single netdev interface exposed to the
applications
for the data transfer and these MLO_LINK wdevs along with
NL80211_IFTYPE_STATION
wdev represent the corresponding connection/link status with the MLD AP.
Please note that in this case the NL80211_IFTYPE_STATION Acts as both
the MLD
and one of the MLO Link’s.
>
> Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK
> could share a MAC address with the MLD (_STATION), although I hear that
> there's still a discussion right now on MLD-addressed and
> link-addressed
> management frames, so I think we need to wait until we know that for
> sure.
>
> A couple of questions:
>
> 1) How do we present this to userspace, is that it? Wouldn't the
> _STATION (MLD) interface ideally still have *some* visible wireless
> state, and show which network it's connected to? It might be very
> awkward to require all userspace tools to be updated to know about
> and query for _MLO_LINKs.
>
> Obviously, wpa_supplicant needs to be aware of these and can handle
> it just fine, so I'm more concerned about other userspace. After
> all, people still use tools built on wireless extensions
As I have mentioned above , the _STATION is both the MLD and one of the
MLO Links.
This shall still have the connected state with its MLO Link representing
the connection info with the AP.
The other MLO Link of a 2 Link MLO connection to the AP (for example) is
represented by the _MLO_LINK wdev.
Userspace tools can still see this _STATION as both the MLD and non MLD
station interface connection.
For an MLD connection this _STATION interface will also link with the
corresponding _MLO_LINK wdev’s and thus any
MLO aware user applications can as well get the connection stats of the
corresponding MLO Links along with _STATION link through the _STATION
interface.
>
> 2) In some ways related to 1), but in other ways also not - perhaps we
> need to anticipate that some devices will want to handle MLO link
> decisions in firmware? I haven't thought about this much at all,
> but
> if we require separate MLO_LINK type wdevs for each link that might
> be tricky?
Are you saying that these devices want to totally handle the MLO link
establishments with in the firmware ?
Let me take an example here. I have taken a 2 link MLO for a reference.
Such devices want to still represent the station interface with
NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with in
the firmware ?
Technically, the _STATION interface here is connected to 2 BSSID’s .
Can I know What would _STATION(wdev)->current_bss represent here ?
> 3) I keep thinking about moving much "associated" state into the STA
> struct we maintain in the kernel, and actually maintaining the
> *links* only as "multiple associations". This also gets tricky with
> the link MAC addresses in a way, though that could be handled. It
> might also be an easier way to manage some of that state problem
> from my question 1)?
>
> Any thoughts on this? I'm definitely not saying this would be easy,
> but would it simplify things regarding the userspace APIs and the
> offload question in 2)?
Can I know how these “multiple associations” would be represented as to
the user space ?
With your proposal above, the userspace applications shall still see a
single NL80211_IFTYPE_STATION and multiple links are maintained within
this
wdev ?
Fine , this would work as long as these links are with in the same
wiphy.
Let me present the two use cases we considered MLO for.
1)single wiphy to represent multiple bands on which the MLO Links can be
formed :
In this case the _STATION interface would be on a single wiphy and yeah
your
proposal would hold good. We initially thought on similar lines. Thanks.
2) single wiphy for each supported band: Say there are two wiphy’s here
, each
representing the respective bands 2G and 5G/6G. In this specific case,
the non
MLO solution had two _STATION interfaces connecting to the AP’s on
respective bands.
We are aiming to enhance this design for MLO . In this case, the MLO
Links spawn
across different wiphy’s and at the same time has to be backward
compatible for
the non MLO connection ( dual STA ) .
To suite the above two use cases , we proposed the introduction of
_MLO_LINK wdev
and the _STATION interface to link all the _MLO_LINK wdev’s that are
part of the
respective MLD connection.
Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice
versa to have
both the MLO and non MLO connection (Dual STA).
> Any other designs than the MLO_LINK wdev that you have considered
> and discarded, and if so for which reasons?
>
>
>> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link”
>> on the non-AP MLD.This would not be required for an AP MLO.
>
> FWIW, I don't buy the part about this not being required for an AP MLD.
>
>> The following explains our design for AP.
>> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance
>> for
>> non-MLO / legacy client and an MLO link for AP-MLD.
>> To be specific, For a 2 link AP MLD , there will be 2
>> NL80211_IFTYPE_AP
>> wdev's created.
>
> This will not work if there's a need (and possibly spec requirement) to
> have an MLD address that's different from *all* the link addresses. It
> will also be difficult to manage that one of the AP interfaces would
> have to be defacto the MLD, but (at least in theory) any one of the AP
> interfaces could be removed for 'degraded' operation.
>
> I suspect will also not work right if you want to have AP_VLAN on the
> AP
> MLD.
>
> IMHO it'd be better for things to be symmetric like you suggest for the
> client side.
>
> Now, I can see the need for legacy interoperability, but then it seems
> it would probably be better to do this the other way around and declare
> a new AP_MLD interface type (with a netdev) that doesn't maintain its
> own beacons etc. but just has its own MAC address (the AP MLD address)
> and bubbles up the data frames exchanged on the MLD.
OK. A new AP_MLD with a netdev to represent the MLD. I guess this is to
only facilitate the need for a different MLD address over the MLO link
addresses?
Taking an example , A 2 MLO AP would have the following . Please correct
me .
Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP
instance
for a non MLD AP ( for the legacy clients to connect ). These two wdev’s
maintain
their own beacon’s and do have the corresponding netdev’s.
A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. The
two
_IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD
interface
for the MLD address ?
We had seen some concerns on this model and please allow me to get back
to you
as early as possible.
Regards,
Sunil
On 2021-02-12 22:33, [email protected] wrote:
> Hi ,
> Thanks for your response.
>
>>> The switch / change interface among the STA or MLO Link shall happen
>>> only in the disconnected state.
>>> At this point, (in the disconnected state) these MLO Link wdev’s are
>>> not
>>> linked to the STA interface ( either on the same / different wiphy ).
>>> These shall be linked after the Association to an MLO AP.
>>> The intention here is to have the wdev in the right mode ( STA or MLO
>>> Link ) before the connect / Association is triggered.
>>> This wdev is put in to a MLO_LINK_DEVICE, before the connect /
>>> association is triggered on the respective MLD (IFTYPE_STA) interface
>>> for an MLO connection.
>>> This wdev is put in the IFTYPE_STA mode, before triggering a connect
>>> /
>>> association on this interface.
>>>
>>> This should be applicable for different drivers too.
>>>
>>> Please let us know if there are any caveats in this design
>>
>>
>> Just to summarize, to see if I'm understanding it correctly.
>>
>> You're basically saying that on the client side
>>
>> 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with
>> whatever
>> MAC address it may have, and does not maintain its "own"
>> association
>> to an AP;
>> 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the
>> DEVICE
>> it's long enough) are added to it, with appropriate link addresses
>> selected for them;
>> 3) this configuration can only happen while none of them are
>> connected.
>>
>> Right?
>
> No . Our intention was the NL80211_IFTYPE_STATION interface to also
> represent
> the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents
> other MLO
> Links of an MLO connection.
> This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev
> shall
> link all such MLO_LINK’s which are part of the same MLD connection.
> That way , there will be a single netdev interface exposed to the
> applications
> for the data transfer and these MLO_LINK wdevs along with
> NL80211_IFTYPE_STATION
> wdev represent the corresponding connection/link status with the MLD
> AP.
> Please note that in this case the NL80211_IFTYPE_STATION Acts as both
> the MLD
> and one of the MLO Link’s.
>
>>
>> Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK
>> could share a MAC address with the MLD (_STATION), although I hear
>> that
>> there's still a discussion right now on MLD-addressed and
>> link-addressed
>> management frames, so I think we need to wait until we know that for
>> sure.
>>
>> A couple of questions:
>>
>> 1) How do we present this to userspace, is that it? Wouldn't the
>> _STATION (MLD) interface ideally still have *some* visible
>> wireless
>> state, and show which network it's connected to? It might be very
>> awkward to require all userspace tools to be updated to know about
>> and query for _MLO_LINKs.
>>
>> Obviously, wpa_supplicant needs to be aware of these and can
>> handle
>> it just fine, so I'm more concerned about other userspace. After
>> all, people still use tools built on wireless extensions
>
> As I have mentioned above , the _STATION is both the MLD and one of the
> MLO Links.
> This shall still have the connected state with its MLO Link
> representing
> the connection info with the AP.
> The other MLO Link of a 2 Link MLO connection to the AP (for example)
> is
> represented by the _MLO_LINK wdev.
> Userspace tools can still see this _STATION as both the MLD and non MLD
> station interface connection.
> For an MLD connection this _STATION interface will also link with the
> corresponding _MLO_LINK wdev’s and thus any
> MLO aware user applications can as well get the connection stats of the
> corresponding MLO Links along with _STATION link through the _STATION
> interface.
>
>>
>> 2) In some ways related to 1), but in other ways also not - perhaps
>> we
>> need to anticipate that some devices will want to handle MLO link
>> decisions in firmware? I haven't thought about this much at all,
>> but
>> if we require separate MLO_LINK type wdevs for each link that
>> might
>> be tricky?
>
> Are you saying that these devices want to totally handle the MLO link
> establishments with in the firmware ?
> Let me take an example here. I have taken a 2 link MLO for a
> reference.
> Such devices want to still represent the station interface with
> NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with
> in
> the firmware ?
> Technically, the _STATION interface here is connected to 2 BSSID’s .
> Can I know What would _STATION(wdev)->current_bss represent here ?
>
>
>> 3) I keep thinking about moving much "associated" state into the STA
>> struct we maintain in the kernel, and actually maintaining the
>> *links* only as "multiple associations". This also gets tricky
>> with
>> the link MAC addresses in a way, though that could be handled. It
>> might also be an easier way to manage some of that state problem
>> from my question 1)?
>>
>> Any thoughts on this? I'm definitely not saying this would be
>> easy,
>> but would it simplify things regarding the userspace APIs and the
>> offload question in 2)?
>
> Can I know how these “multiple associations” would be represented as to
> the user space ?
> With your proposal above, the userspace applications shall still see a
> single NL80211_IFTYPE_STATION and multiple links are maintained within
> this
> wdev ?
> Fine , this would work as long as these links are with in the same
> wiphy.
>
> Let me present the two use cases we considered MLO for.
>
> 1)single wiphy to represent multiple bands on which the MLO Links can
> be formed :
> In this case the _STATION interface would be on a single wiphy and yeah
> your
> proposal would hold good. We initially thought on similar lines.
> Thanks.
> 2) single wiphy for each supported band: Say there are two wiphy’s here
> , each
> representing the respective bands 2G and 5G/6G. In this specific case,
> the non
> MLO solution had two _STATION interfaces connecting to the AP’s on
> respective bands.
>
> We are aiming to enhance this design for MLO . In this case, the MLO
> Links spawn
> across different wiphy’s and at the same time has to be backward
> compatible for
> the non MLO connection ( dual STA ) .
> To suite the above two use cases , we proposed the introduction of
> _MLO_LINK wdev
> and the _STATION interface to link all the _MLO_LINK wdev’s that are
> part of the
> respective MLD connection.
> Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice
> versa to have
> both the MLO and non MLO connection (Dual STA).
>
>> Any other designs than the MLO_LINK wdev that you have considered
>> and discarded, and if so for which reasons?
>>
>>
>>> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO
>>> Link”
>>> on the non-AP MLD.This would not be required for an AP MLO.
>>
>> FWIW, I don't buy the part about this not being required for an AP
>> MLD.
>>
>>> The following explains our design for AP.
>>> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance
>>> for
>>> non-MLO / legacy client and an MLO link for AP-MLD.
>>> To be specific, For a 2 link AP MLD , there will be 2
>>> NL80211_IFTYPE_AP
>>> wdev's created.
>>
>> This will not work if there's a need (and possibly spec requirement)
>> to
>> have an MLD address that's different from *all* the link addresses. It
>> will also be difficult to manage that one of the AP interfaces would
>> have to be defacto the MLD, but (at least in theory) any one of the AP
>> interfaces could be removed for 'degraded' operation.
>>
>> I suspect will also not work right if you want to have AP_VLAN on the
>> AP
>> MLD.
>>
>> IMHO it'd be better for things to be symmetric like you suggest for
>> the
>> client side.
>>
>> Now, I can see the need for legacy interoperability, but then it seems
>> it would probably be better to do this the other way around and
>> declare
>> a new AP_MLD interface type (with a netdev) that doesn't maintain its
>> own beacons etc. but just has its own MAC address (the AP MLD address)
>> and bubbles up the data frames exchanged on the MLD.
>
> OK. A new AP_MLD with a netdev to represent the MLD. I guess this is
> to
> only facilitate the need for a different MLD address over the MLO link
> addresses?
>
> Taking an example , A 2 MLO AP would have the following . Please
> correct me .
> Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP
> instance
> for a non MLD AP ( for the legacy clients to connect ). These two
> wdev’s maintain
> their own beacon’s and do have the corresponding netdev’s.
> A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. The
> two
> _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD
> interface
> for the MLD address ?
>
> We had seen some concerns on this model and please allow me to get back
> to you
> as early as possible.
Continuing with this 2 link MLO example further, our thought is to
bridge the
2 netdev’s associated with each MLO Link ( MLD AP ) / AP instance ( non
MLD AP ).
Thus, the bridge interface shall represent the network interface for the
non MLD &
MLD AP to the network stack.
Adding further, it is this bridge interface that gets routed over the
network stack
and thus the destination / source MAC address of the IP frames from / to
non MLO / MLO
clients associated to the AP would be the bridge MAC address.
If this is agreed, then in the above topology the MLD MAC Address /
netdev is not used
and this MAC address is used as the destination MAC only for certain
frames
( EAPOL frames , from our study till now ) .
So, we were debating if we need a separate netdev to represent the MLD
MAC address.
Would it be needed for RX / TX of EAPOL frames also from the hostapd /
user space ?
IMHO No, as these frames could as well be exchanged over the NL
interface , isn’t ?
Another thought is to just consider this MLD MAC address as a logical
entity
(without associating to the netdev) which is different address from the
Link addresses.
That said, can this model of “AP_MLD interface type ( with a netdev ) “
made optional
and left for the driver architectures to use it ( separate netdev for
the MLD MAC ) ?
Regards,
Sunil
On 2021-02-18 22:56, [email protected] wrote:
> On 2021-02-12 22:33, [email protected] wrote:
>> Hi ,
>> Thanks for your response.
>>
>>>> The switch / change interface among the STA or MLO Link shall happen
>>>> only in the disconnected state.
>>>> At this point, (in the disconnected state) these MLO Link wdev’s are
>>>> not
>>>> linked to the STA interface ( either on the same / different wiphy
>>>> ).
>>>> These shall be linked after the Association to an MLO AP.
>>>> The intention here is to have the wdev in the right mode ( STA or
>>>> MLO
>>>> Link ) before the connect / Association is triggered.
>>>> This wdev is put in to a MLO_LINK_DEVICE, before the connect /
>>>> association is triggered on the respective MLD (IFTYPE_STA)
>>>> interface
>>>> for an MLO connection.
>>>> This wdev is put in the IFTYPE_STA mode, before triggering a connect
>>>> /
>>>> association on this interface.
>>>>
>>>> This should be applicable for different drivers too.
>>>>
>>>> Please let us know if there are any caveats in this design
>>>
>>>
>>> Just to summarize, to see if I'm understanding it correctly.
>>>
>>> You're basically saying that on the client side
>>>
>>> 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with
>>> whatever
>>> MAC address it may have, and does not maintain its "own"
>>> association
>>> to an AP;
>>> 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the
>>> DEVICE
>>> it's long enough) are added to it, with appropriate link
>>> addresses
>>> selected for them;
>>> 3) this configuration can only happen while none of them are
>>> connected.
>>>
>>> Right?
>>
>> No . Our intention was the NL80211_IFTYPE_STATION interface to also
>> represent
>> the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents
>> other MLO
>> Links of an MLO connection.
>> This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev
>> shall
>> link all such MLO_LINK’s which are part of the same MLD connection.
>> That way , there will be a single netdev interface exposed to the
>> applications
>> for the data transfer and these MLO_LINK wdevs along with
>> NL80211_IFTYPE_STATION
>> wdev represent the corresponding connection/link status with the MLD
>> AP.
>> Please note that in this case the NL80211_IFTYPE_STATION Acts as both
>> the MLD
>> and one of the MLO Link’s.
>>
>>>
>>> Wrt. MAC addresses, I suppose from our pure software POV the
>>> _MLO_LINK
>>> could share a MAC address with the MLD (_STATION), although I hear
>>> that
>>> there's still a discussion right now on MLD-addressed and
>>> link-addressed
>>> management frames, so I think we need to wait until we know that for
>>> sure.
>>>
>>> A couple of questions:
>>>
>>> 1) How do we present this to userspace, is that it? Wouldn't the
>>> _STATION (MLD) interface ideally still have *some* visible
>>> wireless
>>> state, and show which network it's connected to? It might be very
>>> awkward to require all userspace tools to be updated to know
>>> about
>>> and query for _MLO_LINKs.
>>>
>>> Obviously, wpa_supplicant needs to be aware of these and can
>>> handle
>>> it just fine, so I'm more concerned about other userspace. After
>>> all, people still use tools built on wireless extensions
>>
>> As I have mentioned above , the _STATION is both the MLD and one of
>> the
>> MLO Links.
>> This shall still have the connected state with its MLO Link
>> representing
>> the connection info with the AP.
>> The other MLO Link of a 2 Link MLO connection to the AP (for example)
>> is
>> represented by the _MLO_LINK wdev.
>> Userspace tools can still see this _STATION as both the MLD and non
>> MLD
>> station interface connection.
>> For an MLD connection this _STATION interface will also link with the
>> corresponding _MLO_LINK wdev’s and thus any
>> MLO aware user applications can as well get the connection stats of
>> the
>> corresponding MLO Links along with _STATION link through the _STATION
>> interface.
>>
>>>
>>> 2) In some ways related to 1), but in other ways also not - perhaps
>>> we
>>> need to anticipate that some devices will want to handle MLO link
>>> decisions in firmware? I haven't thought about this much at all,
>>> but
>>> if we require separate MLO_LINK type wdevs for each link that
>>> might
>>> be tricky?
>>
>> Are you saying that these devices want to totally handle the MLO link
>> establishments with in the firmware ?
>> Let me take an example here. I have taken a 2 link MLO for a
>> reference.
>> Such devices want to still represent the station interface with
>> NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with
>> in
>> the firmware ?
>> Technically, the _STATION interface here is connected to 2 BSSID’s .
>> Can I know What would _STATION(wdev)->current_bss represent here ?
>>
>>
>>> 3) I keep thinking about moving much "associated" state into the STA
>>> struct we maintain in the kernel, and actually maintaining the
>>> *links* only as "multiple associations". This also gets tricky
>>> with
>>> the link MAC addresses in a way, though that could be handled. It
>>> might also be an easier way to manage some of that state problem
>>> from my question 1)?
>>>
>>> Any thoughts on this? I'm definitely not saying this would be
>>> easy,
>>> but would it simplify things regarding the userspace APIs and the
>>> offload question in 2)?
>>
>> Can I know how these “multiple associations” would be represented as
>> to
>> the user space ?
>> With your proposal above, the userspace applications shall still see a
>> single NL80211_IFTYPE_STATION and multiple links are maintained within
>> this
>> wdev ?
>> Fine , this would work as long as these links are with in the same
>> wiphy.
>>
>> Let me present the two use cases we considered MLO for.
>>
>> 1)single wiphy to represent multiple bands on which the MLO Links can
>> be formed :
>> In this case the _STATION interface would be on a single wiphy and
>> yeah your
>> proposal would hold good. We initially thought on similar lines.
>> Thanks.
>> 2) single wiphy for each supported band: Say there are two wiphy’s
>> here , each
>> representing the respective bands 2G and 5G/6G. In this specific case,
>> the non
>> MLO solution had two _STATION interfaces connecting to the AP’s on
>> respective bands.
>>
>> We are aiming to enhance this design for MLO . In this case, the MLO
>> Links spawn
>> across different wiphy’s and at the same time has to be backward
>> compatible for
>> the non MLO connection ( dual STA ) .
>> To suite the above two use cases , we proposed the introduction of
>> _MLO_LINK wdev
>> and the _STATION interface to link all the _MLO_LINK wdev’s that are
>> part of the
>> respective MLD connection.
>> Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice
>> versa to have
>> both the MLO and non MLO connection (Dual STA).
>>
>>> Any other designs than the MLO_LINK wdev that you have considered
>>> and discarded, and if so for which reasons?
>>>
>>>
>>>> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO
>>>> Link”
>>>> on the non-AP MLD.This would not be required for an AP MLO.
>>>
>>> FWIW, I don't buy the part about this not being required for an AP
>>> MLD.
>>>
>>>> The following explains our design for AP.
>>>> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance
>>>> for
>>>> non-MLO / legacy client and an MLO link for AP-MLD.
>>>> To be specific, For a 2 link AP MLD , there will be 2
>>>> NL80211_IFTYPE_AP
>>>> wdev's created.
>>>
>>> This will not work if there's a need (and possibly spec requirement)
>>> to
>>> have an MLD address that's different from *all* the link addresses.
>>> It
>>> will also be difficult to manage that one of the AP interfaces would
>>> have to be defacto the MLD, but (at least in theory) any one of the
>>> AP
>>> interfaces could be removed for 'degraded' operation.
>>>
>>> I suspect will also not work right if you want to have AP_VLAN on the
>>> AP
>>> MLD.
>>>
>>> IMHO it'd be better for things to be symmetric like you suggest for
>>> the
>>> client side.
>>>
>>> Now, I can see the need for legacy interoperability, but then it
>>> seems
>>> it would probably be better to do this the other way around and
>>> declare
>>> a new AP_MLD interface type (with a netdev) that doesn't maintain its
>>> own beacons etc. but just has its own MAC address (the AP MLD
>>> address)
>>> and bubbles up the data frames exchanged on the MLD.
>>
>> OK. A new AP_MLD with a netdev to represent the MLD. I guess this is
>> to
>> only facilitate the need for a different MLD address over the MLO link
>> addresses?
>>
>> Taking an example , A 2 MLO AP would have the following . Please
>> correct me .
>> Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP
>> instance
>> for a non MLD AP ( for the legacy clients to connect ). These two
>> wdev’s maintain
>> their own beacon’s and do have the corresponding netdev’s.
>> A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon.
>> The two
>> _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD
>> interface
>> for the MLD address ?
>>
>> We had seen some concerns on this model and please allow me to get
>> back to you
>> as early as possible.
>
> Continuing with this 2 link MLO example further, our thought is to
> bridge the
> 2 netdev’s associated with each MLO Link ( MLD AP ) / AP instance (
> non MLD AP ).
> Thus, the bridge interface shall represent the network interface for
> the non MLD &
> MLD AP to the network stack.
> Adding further, it is this bridge interface that gets routed over the
> network stack
> and thus the destination / source MAC address of the IP frames from /
> to non MLO / MLO
> clients associated to the AP would be the bridge MAC address.
> If this is agreed, then in the above topology the MLD MAC Address /
> netdev is not used
> and this MAC address is used as the destination MAC only for certain
> frames
> ( EAPOL frames , from our study till now ) .
> So, we were debating if we need a separate netdev to represent the MLD
> MAC address.
> Would it be needed for RX / TX of EAPOL frames also from the hostapd /
> user space ?
> IMHO No, as these frames could as well be exchanged over the NL
> interface , isn’t ?
>
> Another thought is to just consider this MLD MAC address as a logical
> entity
> (without associating to the netdev) which is different address from
> the Link addresses.
> That said, can this model of “AP_MLD interface type ( with a netdev )
> “ made optional
> and left for the driver architectures to use it ( separate netdev for
> the MLD MAC ) ?
>
> Regards,
> Sunil
Hi ,
Can you please help us review the proposal for MLO AP and STA.
The following is the high level summary of MLO behavior for both the
modes, based on your earlier suggestions.
MLO STA ( non – AP )
1) An MLD is represented by the NL80211_IFTYPE_STATION wdev.
2) Each MLO Link is represented by a new wdev type -
NL80211_IFTYPE_MLO_LINK
3) Each MLO Link wdev represent the connection information of the
respective link with the MLO AP.
4) The NL80211_IFTYPE_STATION wdev behavior would change based on if the
connection is MLO vs non MLO.
a) For a non MLO NL80211_IFTYPE_STATION Wdev, the current_bss (wdev)
represents the current connected bss information.
b) For an MLO, NL80211_IFTYPE_STATION Wdev will fetch the
current_bss info from the respective NL80211_IFTYPE_MLO_LINK Wdev.
5) Thus, the NL80211_IFTYPE_STATION wdev will maintain the list of all
such NL80211_IFTYPE_MLO_LINK Wdev's for an MLO station.
6) These NL80211_IFTYPE_MLO_LINK Wdev’s can be either on the same or
different wiphy as that of NL80211_IFTYPE_STATION Wdev. This is to
facilitate the dual band architectures, where each wiphy represents the
respective band.
7) Can either of following options be considered to represent a MLD STA.
Leave up to the driver architectures to use the same.
a) Having a separate wdev for an MLD STA. This provides an option to
set any link specific attributes ( e.g., MAC address) via MLO Link wdev
while ML specific attributes can be set via MLD STA wdev
b) No separate wdev / netdev representation for the MLD STA. We
wanted to explore if a NL80211_IFTYPE_STATION wdev can as well act as
one of the MLO Link’s. For the architectures that can support same MLO
Link and MLD.
This will allow driver to support the model of MLD mac being same
as link mac address or different.
MLO AP
1) For AP , NL80211_IFTYPE_AP wdev shall represent both – distinct AP
instance (for non-MLO client associations) and an AP in AP MLD for MLO
client associations.
2) The MLO Links for the AP are represented by the respective
NL80211_IFTYPE_AP wdev's.
3) Can either of following options be considered to represent a MLD AP.
Leave up to the driver architectures to use the same.
a) A new wdev interface type NL80211_IFTYPE_MLD_AP represents the
MLD for an MLO AP. This NL80211_IFTYPE_MLD_AP Shall not have its own
beacon, but will have a netdev associated to it, which represents the
MLD of MLO AP.
b) No separate wdev / netdev representation for the MLD AP. Hostapd
is aware of/derives the MLD MAC address and uses the regular MLO Link AP
wdevs(any) for all the required ML mgmt and EAPOL interactions.
This is for
the architectures where there are no Data frames ( apart from
EAPOL ) destined to MLD.
The MLO Link AP’s are added to the bridge interface and data
frames are forwarded via bridge, practically. This also helps in
architectures where large number of virtual AP’s are the requirement but
resources such
as the net devices are a constraint.
Regards,
Sunil