On 9/6/2022 3:28 PM, Johannes Berg wrote:
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
Thanks.
Now I hit an issue is: wpa_supplicant reject the authentication from AP
while connecting.
because the addr of authentication is replaced the link
bssid(00:03:7f:12:99:99) with MLD address(aa:03:7f:12:99:99) in
mac80211's ieee80211_prepare_and_rx_handle().
wls1: SME: Ignore authentication with unexpected peer aa:03:7f:12:99:99
log:
wls1: SME: Trying to authenticate with 00:03:7f:12:99:99
EAPOL: External notification - portValid=0
wls1: State: SCANNING -> AUTHENTICATING
Not configuring frame filtering - BSS 00:00:00:00:00:00 is not a Hotspot
2.0 network
wls1: Determining shared radio frequencies (max len 1)
wls1: Shared frequencies (len=0): completed iteration
nl80211: Authenticate (ifindex=3)
* bssid=00:03:7f:12:99:99
* freq=5180
* SSID=GONGWEN-WKK-MLO
* IEs - hexdump(len=0): [NULL]
* Auth Type 0
* mlo link id=2
* mld address=aa:03:7f:12:99:99
nl80211: Authentication request send successfully
RTM_NEWLINK: ifi_index=3 ifname=wls1 wext ifi_family=0 ifi_flags=0x1003
([UP])
nl80211: Event message available
nl80211: Drv Event 19 (NL80211_CMD_NEW_STATION) received for wls1
nl80211: New station aa:03:7f:12:99:99
nl80211: Event message available
nl80211: Drv Event 37 (NL80211_CMD_AUTHENTICATE) received for wls1
nl80211: MLME event 37 (NL80211_CMD_AUTHENTICATE) on
wls1(00:03:7f:37:12:16) A1=00:03:7f:37:12:16 A2=aa:03:7f:12:99:99
nl80211: MLME event frame - hexdump(len=42): b0 00 f0 00 00 03 7f 37 12
16 aa 03 7f 12 99 99 aa 03 7f 12 99 99 e0 b8 00 00 02 00 00 00 ff 0a 6b
00 00 07 aa 03 7f 12 99 99
nl80211: Authenticate event
wls1: Event AUTH (10) received
wls1: SME: Ignore authentication with unexpected peer aa:03:7f:12:99:99
