802.11r enabled on both bands per AP doesnt work

[Weedy]

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