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
