I have a question about the r7800. Did anybody manage to get 802.11r working? Clients tend to disconnect immediately after the roam. They do reconnect quickly though. I tried on both WPA2 802.1X (CCMP) as well as WPA PSK (CCMP). The latter is my guestnet which i have running via a tagged VLAN.
Thank you
Yep. 802.11r works great with wpa2. There are many old recommendations for 802.11r configuration which are unnecessary now. On the GUI you just have to turn it on and it works, don’t specify any further advanced options beyond the default (unless you know what you are doing / have a highly custom setup).
Installing the dawn software package I’ve been tinkering with other roaming options too.
OpenWrt SNAPSHOT, r13628-870588b6eb
-----------------------------------------------------
root@OpenWrt:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option txpower '22'
option legacy_rates '0'
option country 'US'
option beacon_int '101'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ft_over_ds '1'
option ssid '*******'
option ft_psk_generate_local '1'
option key '*******'
option ieee80211r '1'
option encryption 'psk2+ccmp'
option ieee80211k '1'
option bss_transition '1'
option ieee80211v '1'
Thx for the config. I update miy config to be exactly like that (except i used "config wifi-iface 'wifinet2'", default_radio0/1 is my 802.1x network, but I assume should still work). I am on the lastest stable, but it still disconnects just after it roams. Do you think it makes sense to try the lastest snapshot? Or the exact snapshot you are using? Where can i download exactly that one?
Thank you, Ramon
P.S. im also using wpad-wolfssl. Note sure if that matters
I run hynman’s latest master build (Select his latest sysupgrade, I run the CT drivers so select the master folder that doesn’t have the ath10k text at the end of the name):
Ok thx. I tried that, but didnt help. 802.11r should just work on latest stable, right?
Could it be due to the 2 VLANs that i have running?
Seems they set up ft_bridge = br-mgnt here:
https://blog.fem.tu-ilmenau.de/archives/1002-HowTo-enable-WiFi-roaming-with-hostapd-and-VLANs.html
Not sure if they set up a separate bridge for this. and also not sure why the APs would need to communicate if psk_generate_local=1.
Also a switch "CONFIG_VLAN_ASYNC=y" needs to be added to compile hostapd with VLAN async?
I have the 802.1X network on VLAN 1, and the WPA2-PSK on VLAN 3.
thanks
Out of the box 802.11r works with the defaults:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3cc56a5534b8b49a7e9ba57edf9878ec32bdd27a
As you add layers of complexity and additional networks... there are many things that could make it not work. If it’s not clear how it affects your setup - simplify your network back to the default config, test, and slowly add the features you want to find what the issue is.
Still cant get it to work. Here is a part of the log when the client roams to the new AP. It always disconencts exactly 10 seconds after it gets associated. Its 100% reproducible. Must be some kind of timeout.
Anything else i can do in terms of logging?
Sun Jul 5 21:05:41 2020 daemon.info hostapd: wlan1-2: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Jul 5 21:05:41 2020 daemon.notice hostapd: wlan1-2: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Sun Jul 5 21:05:51 2020 daemon.notice hostapd: wlan1-2: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sun Jul 5 21:05:51 2020 daemon.info hostapd: wlan1-2: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
Sun Jul 5 21:05:52 2020 daemon.info hostapd: wlan1-2: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Jul 5 21:05:53 2020 daemon.info hostapd: wlan0-2: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Sun Jul 5 21:05:53 2020 daemon.info hostapd: wlan0-2: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Sun Jul 5 21:05:53 2020 daemon.notice hostapd: wlan0-2: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Sun Jul 5 21:05:53 2020 daemon.info hostapd: wlan0-2: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session EFAF915AF4E5943E
Sun Jul 5 21:05:53 2020 daemon.info hostapd: wlan0-2: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
I’d start a new thread with information about your clients and config to get focused attention. 
Hi ACwifidude,
Thanks for the all the help 
maybe i will do that. But im afraid im just stuck, tried a million things, though its not that exraodinary what i want, I just want 2 AP with guestnet on both and clients able to do roaming on the main and guestnet without disconnecting and sleeping without access issues when they wake up... sigh
Thanks,
Ramon
For what it is worth. My laptops/phones roam between an R7800 and a Wrt1900AC-V2.
I haven't configured 80211r nor v and it just works flawlessly without me having to touch it. i can can have skype/team calls throughout the house and walk from one end to the other and I don't even hear a hiccup in the audio.
The only thing i've done is to set the SSID identical for both devices, on both 2.4 and 5ghz.
Lucky you!
I switched off 802.11r, to see if its better, its not really better the STA does not get disconnected, but is unable to reach the internet for a while.
But I noticed this just after i changed the setting:
Mon Jul 6 15:42:30 2020 daemon.notice hostapd: wlan0: interface state DFS->ENABLED
Mon Jul 6 15:42:30 2020 daemon.notice hostapd: wlan0: AP-ENABLED
Mon Jul 6 15:42:30 2020 kern.info kernel: [71416.682067] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-2: link becomes ready
Mon Jul 6 15:42:30 2020 daemon.notice netifd: Network device 'wlan0' link is up
Mon Jul 6 15:42:30 2020 daemon.notice netifd: Network device 'wlan0-1' link is up
Mon Jul 6 15:42:30 2020 daemon.notice netifd: Network device 'wlan0-2' link is up
Mon Jul 6 15:44:14 2020 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=xx:xx:xx:xx:xx:xx ifname=wlan1-2 vlan_id=0) failed: -2 (No such file or directory)
Maybe thats the root cause of my issues,
Looks a bit like: https://bugs.openwrt.org/index.php?do=details&task_id=2286
Maybe there is just a bug with VLANs, but well then i have an issue either way...
Several users have reported issues with virtual inferfaces. Turn off the virtual and run just one SSID per radio frequency. For simplicity I would use a different SSID per radio frequency and see what your results are.
I found a mistake in the lan bridging which may have caused some of the issues I had. I am now running the latest master now with 802.11k and v enabled, but without 802.11r (I guess something is not implemented right with VLANs). The result is that the roaming is now really smooth. So im going to leave it like this for now (until the vlan 802.11r things get cleared up).
Thanks everybody for the help.
Ramon
I'm planning to push tsens support for ipq806x upstream and I'm testing some thing... I notice that there is an upstream driver that is almost identical to ours... So i'm asking here @hnyman how can i check if values output by this driver are correct?
Here is some output of the temp
root@OpenWrt:/# cat /sys/devices/virtual/thermal/*/temp
29897
29900
30022
29899
29903
29899
30021
30022
30022
30020
30021
root@OpenWrt:/# cat /sys/devices/virtual/thermal/thermal_zone0/temp
29897
root@OpenWrt:/# cat /sys/devices/virtual/thermal/*/temp
29897
29900
30022
29899
29903
29899
30021
30022
30022
30020
30021
They should be good or completely wrong?
If I remember right, @dissent1 backported/modified the upstream driver for us.
Values should be millicelcius, so 30000 = 30'C and sounds like a cold device right after boot. Normal values for should be around 50000-55000 for router in light use.
Please check the discussion in the thread below and the PRs linked there (for pointers how our driver is related to the upstream one)
Thx for the data.
I can notice that the (i don't know why) unused 9860 driver in the upstream kernel is more or less a 1:1 copy of our driver and vary only of some part that are not supported upstream... (the configurable trip point)
The output I got was from using this not used driver...
I'm searching some reason to not use this driver and propose our custom one.
From what i can see i think driver 9860 and ipq806x use the same tsens version or actually they are just the same driver and one of them made to the upstream kernel.
It would not be anything new for QCA SoC-s of the same generation to share a lot of stuff, specially power and thermal management, basic peripherals etc.
Sometimes its identical and sometimes with minor changes.
From the thread i can read that msm8960 ipq8064 and apq8064 are all twins... So i think i will follow this path and just propose the ipq8064 support using the msm8960 driver. (and also add some code so we can remove the hack we use to make the driver use the gcc regs)
Any experience with the schedutil governor?