802.11r enabled on both bands per AP doesnt work

michael-dev michael-dev at fami-braun.de
Fri Aug 18 00:58:27 PDT 2017 

Hi Weedy,

I works realiably for me for some time now.

See 
https://blog.fem.tu-ilmenau.de/archives/1002-HowTo-enable-WiFi-roaming-with-hostapd-and-VLANs.html

Regards,
M. Braun

Am 17.08.2017 23:17, schrieb 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

More information about the Hostap mailing list