Hi,
I'm wondering on the following aspects of the talk:
- on slide 28, he says full WPA-EAP is slow for roaming. But of the
472ms shown in the packet trace, 363ms are actually after the EAP
handshake SUCCESS message and before Key 1/4 message (frame 105499 delta
value)- and thus cannot be attributed to EAP (nor WPA) but the AP
internals. Still, FT improves but the baseline should be only 109ms (for
the authentication).
- on slide 31, the authentication + reply + reassociation + replay OTA
handshake is 0.002ms (with the AP having to do all the R0<->R1
communication and key derivation). On slide 34, for over-DS, we have 2ms
for forwarding the action frame and getting the reply alone and
additionally the STA waits another 57ms after the over-DS handshake is
completed before it actually sends its reassocation request, which takes
<1ms here.
So while it might be true that the tested devices/firmware is slower
when using over-DS, it looks more like implementation details of the
specific measured devices/device types to me.
Regards,
M. Braun
Am 29.09.2021 00:53, schrieb James Prestwood:
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
