Hi,
Am 26.07.2017 18:34, schrieb Deviance:
AP1: 2,4 GHz -> AP2: 2,4 Ghz works
AP1: 2,4 GHz -> AP2: 5 Ghz works
Whats the proper way of testing this (commands), as it will greatly
quicken the
process?
wpa_supplicant comes with a control interfaces you can use to force
roaming.
You can use wpa_cli to control wpa_supplicant.
See e.g. wpasupplicant.py (def roam) and test_ap_ft.py in hostapd repo
for (scripted) examples.
You want the FT_DS and ROAM command.
Also, you mentioned extra steps for local RRB communication.
Basically, hostapd currently does not receive the RRB packets from linux
kernel when they are send from another process on the same interface.
Using a bridge of distinct dummy interfaces where hostapd is
sending/receiving on the dummy interface works for example, or just use
one hostapd process for both local interfaces.
Maybe you'll need to start hostapd manually on OpenWRT for this (just
pass both config files as arguments).
ft_psk_generate_local=1
Though, RRB issues should not matter as due to ft_psk_generate_local=1
your testcase should not do any RRB communication.
Also, you don't give any RRB configuration (e.g. keys) in your config
files, so RRB communication would be doomed to fail in all test cases.
AP1: 2,4+5 GHz -> AP2: 2,4+5 Ghz breaks
Using different hostapd procceses on different interfaces without RRB
communication, there is not much left how they should disturb roaming to
an other hostapd proccess.
Though, there is one thing they both need to do: in case your phone uses
over-ds roaming, some packets still need to be forwarded between the
APs.
As your configuration listing lacks bridging that covers all four BSS,
this should fail for all test cases. But if the bridging is there (just
not given in the mail), maybe there is an issue when both hostapd
processes try to listen on the same bridge interface to receive over-ds
packets. You can use ft_over_ds=0 in hostapd.conf to disable over-ds
roaming.
The hostapd log should indicate to you if the phone even tried to roam
and whether it used OVER_DS or OVER_AIR.
This could then be fixed the same way as for RRB communication (see
above).
Last, (part of) the issue might be your phones not liking the same SSID
on both bands or having trouble to choose which BSS to roam to or (not)
trying another BSS if roaming to the selected target BSS does not work.
Regards,
M. Braun
2017-07-26 17:48 GMT+02:00 michael-dev <michael-dev@xxxxxxxxxxxxx>:
Hi,
802.11r is for roaming between BSS within an ESS (IEEE 802.11-2016
section
13.1 second sentence).
When an AP sends on multiple frequencies, it usually spans multiple
BSS. So
for roaming to be possible, these BSS need to part of the same ESS and
thus
share the same SSID. For FT, they also need to share the same mobility
domain identifier.
802.11r cannot be used for band steering, that is the AP forcing a
client on
a different band, as the client alone decides whether it roams or not.
Further possible issues:
- a client might not choose to roam depending on its policy (which
might
depend on signal strengh or limit the band)
- using different hostapd procceses on the same AP for each band
needs
extra steps for local RRB communication
(and depending on your hostapd version also when both bands are
managed
from the same hostapd process)
How did you test 802.11r roaming? What do you observe when the client
is
"stuck"?
Regards,
M. Braun
12.7.1.7.3 -> PMK-R0 derived from SSID
Am 24.07.2017 00:52, schrieb Deviance:
802.11r on one band (2,4GHz or 5GHz) per AP works with:
mobility_domain=e612
nas_identifier=<unique per BSS>
ft_psk_generate_local=1
wpa_key_mgmt=WPA-PSK FT-PSK
While using those parameters for both bands per AP, client wont roam
to higher/lower frequency on the same AP, neither to the other AP. It
looks like the client is stuck.
Am I misunderstanding the whole concept here: FT can only be used for
clients to roam between APs and not bands on the same AP or are the
parameters incorrect for this setup (both bands per AP)?
hostapd v2.7-devel
latest LEDE trunk
Archer C7 v2 (all APs)
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
