[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hostap
Subject:    RE: [PATCH 29/50] AP: Handle TX status for MLD AP
From:       "Otcheretianski, Andrei" <andrei.otcheretianski () intel ! com>
Date:       2023-02-22 13:59:58
Message-ID: DM6PR11MB3897CC2A3CF584862C247F0EF5AA9 () DM6PR11MB3897 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]

> > hostapd_data *hapd, const u8 *buf,
> > 			       size_t len, u16 stype, int ok)  {
> > 	struct ieee80211_hdr *hdr;
> > -	struct hostapd_data *orig_hapd = hapd;
> > +	struct hostapd_data *orig_hapd = hapd, *tmp_hapd;
> > 
> > 	hdr = (struct ieee80211_hdr *) buf;
> > -	hapd = get_hapd_bssid(hapd->iface, get_hdr_bssid(hdr, len));
> > -	if (!hapd)
> > -		return;
> > +	tmp_hapd = get_hapd_bssid(hapd->iface, get_hdr_bssid(hdr, len));

> Given that we have a common i802_ bss for all link hapds, the incoming
> bss(hapd) here will always be the first link bss If we have a 2.4G+5G mld, how
> will a 5G legacy(non-ml) stations tx_status will be routed to right link hapd
> (i.e., 5G)?

Right, it looks that this part wasn't handled properly. I will fix it by saving the \
cookie per link. This way link_id will be available in TX_STATUS events.

Andrei
> > +	if (tmp_hapd) {

_______________________________________________
Hostap mailing list
Hostap@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/hostap


[prev in list] [next in list] [prev in thread] [next in thread]