Hi, > The 3 commit below > wifi: mac80211: mlme: transmit assoc frame with address translation > https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?h=mld&id=4ca04ed36478e21b037fc379a7e6f52d0e6d8d52 > > wifi: mac80211: support MLO authentication/association with one link > https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?h=mld&id=81151ce462e533551f3284bfdb8e0f461c9220e6 > > wifi: mac80211: do link->MLD address translation on RX > https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?h=mld&id=42fb9148c078004d07b4c39bd7b1086b6165780c (Just noting that they're not part of this patchset, they were there before) > changed to use MLD address for send > authentication/assoc request for station and > changed to use MLD address of rx management packet include > authentication/assoc response received by station from AP. Yes. > Does it has any description about the MLD adress in authentication/assoc > request/assoc response in IEEE P802.11be™/D2.0 or other sepcification? Not _really_. I don't think the spec ever really talks about this since it simply doesn't (need to) care what you do inside your software stack. However, I believe there are (or will be) cases where even for management frames we will not want to make a determination which link to use to transmit - since they're "addressed to the MLD" (see D2.0 35.3.14 Multi-link device individually addressed Management frame delivery). Note also that for protected management frames, the MLD addresses become part of the AAD. Today, auth/assoc frames cannot be encrypted (though that may quite possibly change for assoc frames in the future), and for them also only a single link can be selected. However, I thought that from a software POV it would still be better if as many MLD-addressed frames actually carried MLD addresses in the software stack as possible, to unify things with the encryption requirements etc. The only exception to this is the first received authentication frame on the AP which cannot be translated in the stack/driver/firmware since we don't have a station entry for the new station yet, so hostapd has to be prepared to handle that very first frame with link addresses. johannes
