802.11r enabled on both bands per AP doesnt work

[michael-dev]

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