Hi Michael, On Tue, 2021-09-28 at 17:30 +0000, Michael Yartys wrote: > Hi > > Thanks a lot for the detailed write-up! > > In case you're interested, I remember seeing a talk from WLPC 2019 > Prague about how over-the-DS performed worse than over-the-air: > https://www.youtube.com/watch?v=4Ua2lI6HBhE&t=1178s > > This is only based on one type of test, and the performance might be > better in other situations, but it looks like you don't save on > anything (the roam takes longer actually) with over-the-DS. Just a comment on this: It really depends on how you do FT-over-DS. If you wait to start FT- over-DS until the time of roam its going to take longer. But if you instead start the FT-over-DS action sequence to all neighbors early (like after the initial connection) you can immediately reassociate to your FT target when needed. Thanks, James > > Michael > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Monday, September 27th, 2021 at 22:59, michael-dev > <michael-dev@xxxxxxxxxxxxx> wrote: > > > Hi, > > > > DHCP does not matter here, as it is provided independently from the > > way > > > > wifi authentication works. > > > > With FT, there is for each connected station the AP called "R0" - > > the > > > > AP, that the station completed its first FT-SAE handshake with (for > > the > > > > current session). The current connected AP is called "R1". After > > > > connecting first, the current AP is both R0 and R1. > > > > So when connecting to a new AP reusing its existing FT session, > > that new > > > > AP also behaves as an R1 AP and contacts the R0 AP. Which of your > > APs > > > > becomes R0 or R1 depends on which is the first the STA connects to > > - so > > > > both need to be able to act as R0 and R1 and learn of each other in > > both > > > > R0 and R1 role. > > > > R0 <-> R1 communication takes place using the MAC addresses > > configured > > > > with r0kh/r1kh config setting using a hostapd-specific protocol. > > With > > > > ft_psk_generate_local=1, (only) this communication is skipped with > > > > FT-PSK and the R1 just does the required computations itself to > > make up > > > > the results. > > > > In order for the STA to save an RTT of being effectively > > disconnected > > > > when roaming, it can complete its handshake with the new R1 by > > sending > > > > the packets to its current R1, which the forwards it to the new R1 > > > > (normally over wire). This is called over-DS and is independed from > > > > R0<->R1 communication. If over-DS is not used (either because the > > STA > > > > does not want to or the AP has ft_over_ds=0), this STA <-> new AP > > > > handshake is done over WiFi (as would any non-FT handshake). This > > packet > > > > forwarding does not depend on r0kh/r1kh configuration, as the > > target MAC > > > > adress is provided by the STA. > > > > Regards, > > > > M. Braun > > > > Am 26.09.2021 22:41, schrieb Michael Yartys: > > > > > Hi > > > > > > I suspected that would be the case. > > > > > > So the APs need to communicate for FT-SAE to work, but how does > > > that > > > > > > communication take place? In my setup one R7800 acts as the > > > "main" > > > > > > router and provides IP addresses through DHCP while the other one > > > is > > > > > > connected to it via Ethernet and is simply a dumb AP. Do the APs > > > > > > communicate via Ethernet or via WiFi? > > > > > > Michael > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > > > On Sunday, September 26th, 2021 at 22:32, michael-dev > > > > > > michael-dev@xxxxxxxxxxxxx wrote: > > > > > > > Hi, > > > > > > > > this is not possible by the way the EAP authentication backing > > > > FT-SAE > > > > > > > > works. > > > > > > > > Regards, > > > > > > > > M. Braun > > > > > > > > Am 23.09.2021 11:08, schrieb S330錢小偉qianxiaowei: > > > > > > > > > Dear Braun, > > > > > > > > > > Do we have plans to support functions similar to > > > > > ft_psk_generate_local > > > > > > > > > > on FT-SAE? > > > > > > > > > > As we know, before ft_psk_generate_local is not supported, we > > > > > also > > > > > > > > > > need to manually configure r0kh and r1kh. > > > > > > > > > > This is not very friendly for home users who have APs from > > > > > different > > > > > > > > > > manufacturers. > > > > > > > > > > Thanks to the emergence of ft_psk_generate_local, which makes > > > > > FT-PSK > > > > > > > > > > very simple Well! > > > > > > > > > > If FT-SAE can also support such a function, it would be > > > > > great!!! > > > > > > > > > > Thanks. > > > > > > > > > > Best Regards! > > > > > > > > > > > On Sep 23, 2021, at 4:13 PM, michael-dev > > > > > > michael-dev@xxxxxxxxxxxxx > > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > you're missing most of the required settings in section > > > > > > IEEE 802.11r > > > > > > > > > > > > configuration of > > > > > > > > > > > > https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf ;. > > > > > > > > > > > > You don't need r0kh/r1kh only if only using FT-PSK with > > > > > > > > > > > > ft_psk_generate_local, because otherwise both hostapd > > > > > > instances need > > > > > > > > > > > > to communicate to faciliate roaming (exchange keys etc.) - > > > > > > which > > > > > > > > > > > > they cannot unless r0kh/r1kh is configured. > > > > > > > > > > > > Regards, > > > > > > > > > > > > M. Braun > > > > > > > > > > > > Am 13.08.2021 09:34, schrieb Michael Yartys: > > > > > > > > > > > > > --- LAPTOP 1 --- > > > > > > > > > > > > > > interface=wlp18s0 > > > > > > > > > > > > > > driver=nl80211 > > > > > > > > > > > > > > ssid=test1 > > > > > > > > > > > > > > hw_mode=g > > > > > > > > > > > > > > channel=1 > > > > > > > > > > > > > > auth_algs=3 > > > > > > > > > > > > > > wmm_enabled=1 > > > > > > > > > > > > > > nas_identifier=first_example > > > > > > > > > > > > > > wpa=2 > > > > > > > > > > > > > > wpa_passphrase=testingstuff123 > > > > > > > > > > > > > > wpa_key_mgmt=SAE FT-SAE > > > > > > > > > > > > > > wpa_pairwise=CCMP > > > > > > > > > > > > > > ieee80211w=2 > > > > > > > > > > > > > > sae_pwe=2 > > > > > > > > > > > > > > mobility_domain=a1b2 > > > > > > > > > > > > > > ft_over_ds=0 > > > > > > > > > > > > > > ft_psk_generate_local=0 > > > > > > > > > > > > > > --- LAPTOP 2 --- > > > > > > > > > > > > > > interface=wlp18s0 > > > > > > > > > > > > > > driver=nl80211 > > > > > > > > > > > > > > ssid=test1 > > > > > > > > > > > > > > hw_mode=g > > > > > > > > > > > > > > channel=6 > > > > > > > > > > > > > > auth_algs=3 > > > > > > > > > > > > > > wmm_enabled=1 > > > > > > > > > > > > > > nas_identifier=second_example > > > > > > > > > > > > > > wpa=2 > > > > > > > > > > > > > > wpa_passphrase=testingstuff123 > > > > > > > > > > > > > > wpa_key_mgmt=SAE FT-SAE > > > > > > > > > > > > > > wpa_pairwise=CCMP > > > > > > > > > > > > > > ieee80211w=2 > > > > > > > > > > > > > > sae_pwe=2 > > > > > > > > > > > > > > mobility_domain=a1b2 > > > > > > > > > > > > > > ft_over_ds=0 > > > > > > > > > > > > > > ft_psk_generate_local=0 > > > > > > > > > > > > Hostap mailing list > > > > > > > > > > > > Hostap@xxxxxxxxxxxxxxxxxxx > > > > > > > > > > > > http://lists.infradead.org/mailman/listinfo/hostap > > > > > > > > > > This message including any attachment is intended only for > > > > > the use of > > > > > > > > > > the addressee(s) and may contain privileged and confidential > > > > > > > > > > information. If you are not the intended recipient, you are > > > > > hereby > > > > > > > > > > notified that any dissemination of this message is strictly > > > > > > > > > > prohibited. Disclosure, copying, distribution, or use of the > > > > > contents > > > > > > > > > > of this e-mail by persons other than the intended recipient > > > > > may > > > > > > > > > > violate applicable laws. Abuse or dissemination by the > > > > > intended > > > > > > > > > > recipient is also forbidden. Please kindly return the e-mail > > > > > and > > > > > > > > > > delete it if you have received this message in error. Thank > > > > > you. > > > > > > > > > > 本郵件內容涉及商業或私人秘密，非收件人請勿散佈或使用，收件人亦應遵守保密義務不得散佈或濫用本郵件，否則可能違反相關法令。如 > > > > > 因傳遞錯誤，請立即刪除並回覆通知寄件人。感謝您。 > > _______________________________________________ > Hostap mailing list > Hostap@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
