Search Linux Wireless

Re: [PATCH] wifi: cfg80211: Correctly handle Medium Synchronization Delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, 2024-10-30 at 10:55 +0800, Lingbo Kong wrote:
> Currently, when the driver attempts to connect to an AP MLD with multiple
> APs, the cfg80211_mlme_check_mlo_compat() function requires the Medium
> Synchronization Delay values from different APs of the same AP MLD to be
> equal, which may result in connection failures.
> 
> This is because when the driver receives a multi-link probe response from
> an AP MLD with multiple APs, cfg80211 updates the Elements for each AP
> based on the multi-link probe response. If the Medium Synchronization Delay
> is set in the multi-link probe response, the Elements for each AP belonging
> to the same AP MLD will have the Medium Synchronization Delay set
> simultaneously. If non-multi-link probe responses are received from
> different APs of the same MLD AP, cfg80211 will still update the Elements
> based on the non-multi-link probe response. Since the non-multi-link probe
> response does not set the Medium Synchronization Delay
> (IEEE 802.11be-2024-35.3.4.4), if the Elements from a non-multi-link probe
> response overwrite those from a multi-link probe response that has set the
> Medium Synchronization Delay, the Medium Synchronization Delay values for
> APs belonging to the same AP MLD will not be equal. This discrepancy causes
> the cfg80211_mlme_check_mlo_compat() function to fail, leading to
> connection failures. Commit ccb964b4ab16
> ("wifi: cfg80211: validate MLO connections better") did not take this into
> account.

The specification confuses me a bit and I am probably missing
something.

> To address this issue, add a u16 type member to the struct cfg80211_bss to
> store the Medium Synchronization Delay. When the driver receives a probe
> response with the Medium Synchronization Delay set, update this member’s
> value; otherwise, do not update it. Additionally, modify the parameter list
> of cfg80211_mlme_check_mlo_compat() so that this member variable can be
> directly accessed within the cfg80211_mlme_check_mlo_compat() function viaq
> a pointer to the struct cfg80211_bss. This will allow checking whether the
> Medium Synchronization Delay values from different APs of the same AP MLD
> are equal.

This feels like a recipe for failures. Whether or not an ML-Probe
Response is seen should not generally affect the validity of a BSS.
Which means that the validity check itself may be incorrect.

Maybe we should only compare the values if the subfield has been
included?


That said, do you understand when exactly the subfield should be
included? It seems that it may be carried in the "(Re)Association
Response", in which case it would be consistent anyway.

The ML probe response part seems a bit specific. Could it be that this
is intended to be used by NSTR APs only, in which case there would not
be a beacon on the secondary AP. If that is the case, then there
wouldn't be much of an inconsistency (though we would still need to be
a bit careful).

Benjamin

> 
> Fixes: ccb964b4ab16 ("wifi: cfg80211: validate MLO connections better")
> Signed-off-by: Lingbo Kong <quic_lingbok@xxxxxxxxxxx>
> ---
>  include/net/cfg80211.h |  4 ++++
>  net/wireless/mlme.c    | 11 +++++++----
>  net/wireless/scan.c    | 15 +++++++++++++++
>  3 files changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 27acf1292a5c..ebeb305c1d0c 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2956,6 +2956,8 @@ struct cfg80211_bss_ies {
>   * @cannot_use_reasons: the reasons (bitmap) for not being able to connect,
>   *	if @restrict_use is set and @use_for is zero (empty); may be 0 for
>   *	unspecified reasons; see &enum nl80211_bss_cannot_use_reasons
> + * @med_sync_delay: Medium Synchronization delay as described in
> + *	IEEE 802.11be-2024 Figure 9-1074q.
>   * @priv: private area for driver use, has at least wiphy->bss_priv_size bytes
>   */
>  struct cfg80211_bss {
> @@ -2986,6 +2988,8 @@ struct cfg80211_bss {
>  	u8 use_for;
>  	u8 cannot_use_reasons;
>  
> +	u16 med_sync_delay;
> +
>  	u8 priv[] __aligned(sizeof(void *));
>  };
>  
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 4dac81854721..ae00c36779d2 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -326,7 +326,9 @@ void cfg80211_oper_and_vht_capa(struct ieee80211_vht_cap *vht_capa,
>  }
>  
>  static int
> -cfg80211_mlme_check_mlo_compat(const struct ieee80211_multi_link_elem *mle_a,
> +cfg80211_mlme_check_mlo_compat(const struct cfg80211_bss *bss_a,
> +			       const struct cfg80211_bss *bss_b,
> +			       const struct ieee80211_multi_link_elem *mle_a,
>  			       const struct ieee80211_multi_link_elem *mle_b,
>  			       struct netlink_ext_ack *extack)
>  {
> @@ -340,8 +342,7 @@ cfg80211_mlme_check_mlo_compat(const struct ieee80211_multi_link_elem *mle_a,
>  		return -EINVAL;
>  	}
>  
> -	if (ieee80211_mle_get_eml_med_sync_delay((const u8 *)mle_a) !=
> -	    ieee80211_mle_get_eml_med_sync_delay((const u8 *)mle_b)) {
> +	if (bss_a->med_sync_delay != bss_b->med_sync_delay) {
>  		NL_SET_ERR_MSG(extack, "link EML medium sync delay mismatch");
>  		return -EINVAL;
>  	}
> @@ -426,7 +427,9 @@ static int cfg80211_mlme_check_mlo(struct net_device *dev,
>  		if (WARN_ON(!mles[i]))
>  			goto error;
>  
> -		if (cfg80211_mlme_check_mlo_compat(mles[req->link_id], mles[i],
> +		if (cfg80211_mlme_check_mlo_compat(req->links[req->link_id].bss,
> +						   req->links[i].bss,
> +						   mles[req->link_id], mles[i],
>  						   extack)) {
>  			req->links[i].error = -EINVAL;
>  			goto error;
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index 1c6fd45aa809..6ad935475484 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -1899,6 +1899,13 @@ cfg80211_update_known_bss(struct cfg80211_registered_device *rdev,
>  	 */
>  	if (signal_valid)
>  		known->pub.signal = new->pub.signal;
> +
> +	/* update medium synchronization delay when its value is not
> +	 * the default.
> +	 */
> +	if (new->pub.med_sync_delay != IEEE80211_MED_SYNC_DELAY_DEFAULT)
> +		known->pub.med_sync_delay = new->pub.med_sync_delay;
> +
>  	known->pub.capability = new->pub.capability;
>  	known->ts = new->ts;
>  	known->ts_boottime = new->ts_boottime;
> @@ -2224,6 +2231,7 @@ cfg80211_inform_single_bss_data(struct wiphy *wiphy,
>  	int bss_type;
>  	bool signal_valid;
>  	unsigned long ts;
> +	const struct element *ml;
>  
>  	if (WARN_ON(!wiphy))
>  		return NULL;
> @@ -2267,6 +2275,7 @@ cfg80211_inform_single_bss_data(struct wiphy *wiphy,
>  	tmp.pub.use_for = data->use_for;
>  	tmp.pub.cannot_use_reasons = data->cannot_use_reasons;
>  	tmp.bss_source = data->bss_source;
> +	tmp.pub.med_sync_delay = IEEE80211_MED_SYNC_DELAY_DEFAULT;
>  
>  	switch (data->bss_source) {
>  	case BSS_SOURCE_MBSSID:
> @@ -2321,6 +2330,12 @@ cfg80211_inform_single_bss_data(struct wiphy *wiphy,
>  		break;
>  	case CFG80211_BSS_FTYPE_PRESP:
>  		rcu_assign_pointer(tmp.pub.proberesp_ies, ies);
> +		ml = cfg80211_find_ext_elem(WLAN_EID_EXT_EHT_MULTI_LINK,
> +					    ies->data, ies->len);
> +		if (ml)
> +			tmp.pub.med_sync_delay =
> +				ieee80211_mle_get_eml_med_sync_delay(ml->data + 1);
> +
>  		break;
>  	}
>  	rcu_assign_pointer(tmp.pub.ies, ies);
> 
> base-commit: e7e2957f403ba4655199f2ba9920c1a015a7be44






[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux