| Message ID | 20220902141259.377789-1-johannes@sipsolutions.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | another set of MLO patches | expand |
On 9/2/2022 10:12 PM, Johannes Berg wrote: > Alright, here's another set of MLO patches :-) > > I'm preparing everything here for link switching (which is also in > wireless-next/mld-wip branch already), along with some fixes to > avoid VLANs/4-addr and various other fixes that came up during > this work. Not all of them are related, e.g. the SW scan stop just > came up due to the new hwsim checks. > > johannes > Hi Johannes, The 3 commit below 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. Does it has any description about the MLD adress in authentication/assoc request/assoc response in IEEE P802.11be™/D2.0 or other sepcification? 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 >
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
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
On Tue, 2022-09-06 at 15:58 +0800, Wen Gong wrote: > > 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 > Well, OK, you obviously are adjusting the supplicant to work with MLO (otherwise you wouldn't get an MLO connection in the first place), so yeah, this is part of the adjustments needed. Ilan/Andrei have all of this working, maybe we can share the patches even before rebase etc. johannes
On 9/6/2022 4:03 PM, Johannes Berg wrote: > On Tue, 2022-09-06 at 15:58 +0800, Wen Gong wrote: >> 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 >> > Well, OK, you obviously are adjusting the supplicant to work with MLO > (otherwise you wouldn't get an MLO connection in the first place), so > yeah, this is part of the adjustments needed. > > Ilan/Andrei have all of this working, maybe we can share the patches > even before rebase etc. > > johannes Thanks. It is good to share me the wpa_supplicant patches ASAP. And I have another question: When mac80211 use the MLD addr in authentication/assoc request, finally, it should be replaced with one link's address in air port, right? It means the MLD addr will never exist in mac80211 header of packet in the air port, right?
Hi Ilan Peer, Andrei Otcheretianski, Johannes, Could you share me the patches of wpa_supplicant/hostapd for MLO? It is not need rebased to latest git://w1.fi/hostap.git, I only need to test it now. I see you have many patches in the hostap@lists.infradead.org with below links, but not found any patches for MLO. https://patchwork.ozlabs.org/project/hostap/list/?series=&submitter=25407&state=*&q=&archive=&delegate= https://patchwork.ozlabs.org/project/hostap/list/?series=&submitter=62065&state=*&q=&archive=&delegate= On 9/6/2022 4:03 PM, Johannes Berg wrote: > On Tue, 2022-09-06 at 15:58 +0800, Wen Gong wrote: >> 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 >> > Well, OK, you obviously are adjusting the supplicant to work with MLO > (otherwise you wouldn't get an MLO connection in the first place), so > yeah, this is part of the adjustments needed. > > Ilan/Andrei have all of this working, maybe we can share the patches > even before rebase etc. > > johannes
> > Well, OK, you obviously are adjusting the supplicant to work with MLO > > (otherwise you wouldn't get an MLO connection in the first place), so > > yeah, this is part of the adjustments needed. > > > > Ilan/Andrei have all of this working, maybe we can share the patches > > even before rebase etc. Hi, Our implementation is based on our internal tree, so it will take some time to cleanup and port it for upstream. Hopefully I will have some time to work on it this and next week and maybe we will be able to share something initial. Andrei > > > > johannes > > Thanks. > > It is good to share me the wpa_supplicant patches ASAP. > > And I have another question: > > When mac80211 use the MLD addr in authentication/assoc request, > > finally, it should be replaced with one link's address in air port, right? > > It means the MLD addr will never exist in mac80211 header of packet in the > air port, right?
On 9/12/2022 9:17 PM, Otcheretianski, Andrei wrote: >>> Well, OK, you obviously are adjusting the supplicant to work with MLO >>> (otherwise you wouldn't get an MLO connection in the first place), so >>> yeah, this is part of the adjustments needed. >>> >>> Ilan/Andrei have all of this working, maybe we can share the patches >>> even before rebase etc. > Hi, > Our implementation is based on our internal tree, so it will take some time to cleanup and port it for upstream. > Hopefully I will have some time to work on it this and next week and maybe we will be able to share something initial. > > Andrei Thanks, waiting for your patches. Does your patches of supplicant only support single link or support muti-link of MLO? >>> johannes >> Thanks. >> >> It is good to share me the wpa_supplicant patches ASAP. >> >> And I have another question: >> >> When mac80211 use the MLD addr in authentication/assoc request, >> >> finally, it should be replaced with one link's address in air port, right? >> >> It means the MLD addr will never exist in mac80211 header of packet in the >> air port, right?
On 9/12/2022 9:17 PM, Otcheretianski, Andrei wrote: >>> Well, OK, you obviously are adjusting the supplicant to work with MLO >>> (otherwise you wouldn't get an MLO connection in the first place), so >>> yeah, this is part of the adjustments needed. >>> >>> Ilan/Andrei have all of this working, maybe we can share the patches >>> even before rebase etc. > Hi, > Our implementation is based on our internal tree, so it will take some time to cleanup and port it for upstream. > Hopefully I will have some time to work on it this and next week and maybe we will be able to share something initial. May I get your patches? > > Andrei >>> johannes >> Thanks. >> >> It is good to share me the wpa_supplicant patches ASAP. >> >> And I have another question: >> >> When mac80211 use the MLD addr in authentication/assoc request, >> >> finally, it should be replaced with one link's address in air port, right? >> >> It means the MLD addr will never exist in mac80211 header of packet in the >> air port, right?
Hi Ilan/Andrei, Will you send your patches of wpa_supplicant to upstream?
Hi Ilan/Andrei, Will you send your patches of wpa_supplicant for MLO to upstream?
> Hi Ilan/Andrei, > > Will you send your patches of wpa_supplicant for MLO to upstream?
Hi Andrei, Is below all your patches for MLO in wpa_suppplicant for station mode? [00/13] MLD STA: Add SME MLO support https://patchwork.ozlabs.org/project/hostap/list/?series=329909&state=* On 10/19/2022 6:04 PM, Wen Gong wrote: > Hi Ilan/Andrei, > > Will you send your patches of wpa_supplicant for MLO to upstream?
> Hi Andrei, > > Is below all your patches for MLO in wpa_suppplicant for station mode? Hi Wen, We have few more for station side, like SAE/PMKSA support and some additional configs - but this is mostly what I have. SAE support patch is somewhat similar to patches sent by Veerendranath. We have more stuff for AP side (mostly for testing purposes), hwsim tests etc.. I'm starting to clean this up and will send it as well. Andrei
On 11/28/2022 10:05 PM, Otcheretianski, Andrei wrote: >> Hi Andrei, >> >> Is below all your patches for MLO in wpa_suppplicant for station mode? > Hi Wen, > We have few more for station side, like SAE/PMKSA support and some additional configs - but this is mostly what I have. > SAE support patch is somewhat similar to patches sent by Veerendranath. > We have more stuff for AP side (mostly for testing purposes), hwsim tests etc.. I'm starting to clean this up and will send it as well. > > Andrei Thanks Andrei, did you tested your station with single link or 2 link or more link?
> Thanks Andrei, did you tested your station with single link or 2 link or more > link? Tested with 1 and 2 links, but should also work with more links as well Andrei
On 11/29/2022 2:59 PM, Otcheretianski, Andrei wrote: >> Thanks Andrei, did you tested your station with single link or 2 link or more >> link? > Tested with 1 and 2 links, but should also work with more links as well > > Andrei Thanks a lot!