On 8/22/2023 7:16 PM, Johannes Berg wrote:
On Tue, 2023-08-22 at 06:04 -0400, Wen Gong wrote:
It is 100% ratio to reproduce the issue with this change.
Add "mgmt->u.assoc_resp.status_code = 1" in ieee80211_rx_mgmt_assoc_resp().
Don't think that adds any value, but I guess I can always remove it.
change the "mgmt->u.assoc_resp.status_code = 1" is only a way to
reproduce the bss hold
issue. you can remove it when upstream this patch.😁
+ /* use the addr of assoc_data link which is set in ieee80211_mgd_assoc() */
not sure that's so useful? but anyway
The reason I'm even writing this message is that you didn't think this
change through:
Yes, you can remove the comment when upstream this patch.
- const u8 *addr;
+ u8 addr[ETH_ALEN] __aligned(2);
That has some other consequences you need to adapt to, in particular
/* need to have local link addresses for MLO connections */
WARN_ON(cr.ap_mld_addr && !cr.links[link_id].addr);
makes no sense anymore. Not sure if that's the only one.
After this patch, the cr.links[link_id].addr will be a valid local link
address from
struct cfg80211_rx_assoc_resp, so I think it is not needed remove now.
Another is here in __cfg80211_connect_result():
for_each_valid_link(cr, link) {
if (WARN_ON(!cr->links[link].addr))
goto out;
johannes
