802.11r enabled on both bands per AP doesnt work

[Deviance]

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 at gmail.com>:
> 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 at gmail.com>:
>> 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 at fami-braun.de> 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 at fami-braun.de>:
>>>>>
>>>>> 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 at fami-braun.de>:
>>>>>>>
>>>>>>>
>>>>>>> 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 at lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/hostap
>>>
>>>
>>> _______________________________________________
>>> Hostap mailing list
>>> Hostap at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/hostap