Let me repeat so there won't be any confusion. With 2x BSS (1x BSS per 1x AP <-- any single band simultaneously) smartphones ROAM. With 4x BSS (2x BSS per 1x AP <-- both bands simultaneously) smartphones do NOT roam. 2017-08-19 9:31 GMT+02:00 Deviance <devianca@xxxxxxxxx>: > Hey. > > With Galaxy S7 + S8 I have not. The point in doing this is because of > smartphones... > > I did however test it manually with commands to force it to roam and > it roams between all 4x BSS (2x AP = each 2x BSS: 2,4GHz+5GHz) with > Ubuntu 17.04 LiveCD. > > I'm clueless on what to do next. I don't believe it's the clients > issue, because S7 and S8 should be the best one can get. > > Best Regards > > 2017-08-17 23:17 GMT+02:00 Weedy <weedy2887@xxxxxxxxx>: >> 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
