Have you got this working reliably now? Can you break down the config edits so I can try this? On 28 July 2017 at 00:41, michael-dev <michael-dev@xxxxxxxxxxxxx> wrote: > Hi, > > sounds like a very reasonable configuration. > > I would propose to > 1. test manually using wpa_supplicant wpa_cli (I think that should be the > ROAM command) > in order to exclude the phone as behaving faulty > 2. dig into hostapd logs (e.g. after increasing verbosity if needed) > in order to look for further hints of what is actually happening > > Regards, > M. Braun > > Am 27.07.2017 16:44, schrieb Deviance: >> >> Hey, >> >> Thanks for reply. >> >> LEDE is using 1 hostapd process per band, so doing those two BSS with >> one hostapd process without scripting something myself is a no-go. >> >> I'm actually using ft_over_ds=0, thats the only parameter I did not >> write, thought it had no difference in telling. Both BSS on the same >> AP are using the same bridge (thus network). And both APs are bridging >> those BSS/networks to the same network. >> >> Other non FT related arguments I'm using/adding: >> okc=1 >> rsn_preauth=1 >> rsn_preauth_interfaces=<same bridge as in "bridge="> >> disassoc_low_ack=1 >> >> >> Is the story different now? What should I do now, you got me confused :-/ >> >> Thanks and Best Regards, >> Luka >> >> >> 2017-07-27 15:56 GMT+02:00 michael-dev <michael-dev@xxxxxxxxxxxxx>: >>> >>> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
