Entering f when asked by procd
Can you try with the reset button?
Maybe it has a different behaviour
No, that cant be its waiting for both in the same function in 30_failsafe_wait
No problem on my side after almost 3 days of uptime, can get you stats later this evening if needed.
@tiagogaspar8 @dchard I have added the BSS color collision support to the 5.15 branch.
Pending hostapd patches applied with some minor fixes after backporting the nl80211 UAPI header from newer hostapd.
Now, he_bss_color
is set always by using random data from /dev/urandom
to pick an integer from 1-63 unless you manually set it in UCI.
Now everything should be there to handle BSS color collisions though it still needs to be tested, I don't really have a way of making that kind of a setup currently.
Its pushed, so any kind of testing would be awesome.
Just tried the newly built image (r0-040667e).
Looks like the roaming problem is still there. ssdk_sh that I used to fix this is not installed by default and not in the standard feed.
Since I saw the qca-ssdk-shell mentioned during menuconfig, I tried compiling it from within ipq807x-latest (without adding it from your nss-packages.git). Unfortunately the build fails:
job4:~/git/robiwrt > make -j1 V=s package/qca-ssdk-shell/compile
make[1]: Entering directory '/home/joachim/git/robiwrt'
make[2]: Entering directory '/home/joachim/git/robiwrt/package/libs/toolchain'
rm -rf /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc.installed /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc
mkdir -p /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc
install -d -m0755 /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc/lib /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc/usr/bin
cp -fpR /home/joachim/git/robiwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-11.2.0_musl/lib/ld-musl-*.so* /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc/lib/
cp: cannot stat '/home/joachim/git/robiwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-11.2.0_musl/lib/ld-musl-*.so*': No such file or directory
make[2]: *** [Makefile:725: /home/joachim/git/robiwrt/build_dir/target-aarch64_cortex-a53_musl/toolchain/.pkgdir/libc.installed] Error 1
make[2]: Leaving directory '/home/joachim/git/robiwrt/package/libs/toolchain'
time: package/libs/toolchain/compile#0.12#0.03#0.15
ERROR: package/libs/toolchain failed to build.
make[1]: *** [package/Makefile:116: package/libs/toolchain/compile] Error 1
make[1]: Leaving directory '/home/joachim/git/robiwrt'
make: *** [/home/joachim/git/robiwrt/include/toplevel.mk:230: package/qca-ssdk-shell/compile] Fehler 2
Normal? User error? Should I still add nss-packages to the feed? Hope you can help me out
So I can remove the manual bSS color option from the wireless config file? Building on its way
Looks like you are getting stuck on the toolchain, can't say that I saw this error ever.
How are you building?
@dchard Yes, if it's not present in UCI wireless config a random number is used, that works.
However, we gotta test and see whether BSS color CCA works, this requires 2 AP-s.
I will try to utilize the AX3600 for that and use the same BSS color to see whether CCA gets triggered cause ath11k FW should monitor that and then propagate CCA to mac80211 and all the way to hostapd
- 1017 git clone https://github.com/robimarko/openwrt robiwrt
- 1018 cd robiwrt
- 1019 git checkout ipq807x-latest
- 1020 ./scripts/feeds update -a
- 1021 ./scripts/feeds install -a
- 1022 make menuconfig EDIT: only changing target system and profile (3600)
- 1023 make package/qca-ssdk-shell/compile
That's all.
Usually I did this (and I am now using a ssdk_sh from such a build - so I'm fine - roaming tests pending...)
git clone https://github.com/robimarko/nss-packages.git
cd ~/git/jobawrt
echo "src-link nss $HOME/git/nss-packages" >>feeds.conf
./scripts/feeds update nss
./scripts/feeds install -a -p nss
make menuconfig
make package/qca-ssdk-shell/compile
Ahh, you gotta select the qca-ssdk-shell in menuconfig as well, then you can manually only compile it.
Since its really asked, I can add it do the CI default packages, its rather small anyway
Thanks, noted.
Well, I can manage now without default package, but if it is already there: very welcome - and I saw others recently using it too.
Thrown away the clone and redid all steps to check: still doesn't work, same error
make[2]: Entering directory '/home/joachim/git/robiwrt/package/libs/toolchain'
rm -rf /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc.installed /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc
mkdir -p /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc
install -d -m0755 /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/lib /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/usr/bin
cp -fpR /home/joachim/git/robiwrt/staging_dir/toolchain-mips_24kc_gcc-11.2.0_musl/lib/ld-musl-*.so* /home/joachim/git/robiwrt/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/lib/
cp: cannot stat '/home/joachim/git/robiwrt/staging_dir/toolchain-mips_24kc_gcc-11.2.0_musl/lib/ld-musl-*.so*': No such file or directory
I reconsidered - please add it to the CI
EDIT: tried to configure it as module and as builtin, just in case
Ok, I will add it tommorow, gotta go to sleep now
Did you manage to figure out what was happening with the failsafe issue?
Finally I had some time and managed to make a build of your recent push, and it seems to be working well!
I cannot test it on my side sadly but it is indeed selecting random colours and broadcasting them, I'll be watching to see if it changes due to a collision
Thanks for the effort of backporting this!
Not really, gave up on it and moved onto the BSS color
Flashed 3 times your images an my ax3600 via luci and still no update. Is this problem not solvable?
i upgrade with this script:
cat /opt/upgrade.sh
#!/bin/ash
/etc/init.d/wpad stop
sleep 5
sysupgrade /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-sysupgrade.bin
sleep 20
reboot -f
exit 0
just put the sysupgrade file in /tmp/ before
I moved to your latest 5.15 (040667e) and tested BSS color updates on the 2.4GHz radio2 in AX mode.
- It does take on a random colour if unspecified, as observed in /tmp/run/*.conf
- I manually caused a BSS color collision by setting a second AP (same RF channel, same SSID) to the color that had been randomly-chosen by the first. I hope I triggered/tested the scenario correctly, but could see no evidence of the random-colour AP detecting or deciding to change:
- No update to color in /tmp/run/*.conf - though perhaps that's as expected?
- With hostapd increased from default loglevel 2 to 0 for that phy, no message related to (EVENT_BSS_COLOR_COLLISION / BSS color collision on %s") in the output of logread (there was a lot of extra hostapd debug spew - so the loglevel was working)
- Is BSS color clash a client-reported thing, rather than detected by the APs? Just in case, I arranged it so the two clashing APs (same channel, same SSID, same colour) were the only two visible and connectable. No reports of collision on the APs. I kicked the clients between the two APs too. Clients were an Intel AX210 on Windows 10 (AX mode / AX-rate MCS was active), and a Pixel 4a 5G on Android 12 (no AX).
Thanks for testing, there are prints that tell you when nl80211 request for color change has been seen, however, OpenWrt strips most of the prints in the 410-limit_debug_messages.patch
especially since these are marked as debug level.
You won't see a change in the hostapd config file, it should just randomly pick another color unless all are taken.
Collision is detected by the AP, more precisely its firmware and then its propagated down the stack to hostapd.
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath11k?h=ath-next&id=886433a984254c6d2c2074688dc8f48c40b1c070
One more, and maybe crucial thing. On both APs with the clash active I saw regular/repeated:
daemon.err hostapd: nl80211: kernel reports: integer out of range
This didn't appear even once on the third AX3600 running the same build but without the channel/SSID/color clash.
Since moving the two test APs back to non-clashing scenario the integer out of range error hasn't appeared again.