Have Master, 23.05, and 22.03 builds for ipq806x devices with hardware offloading using the two NSS cores. All Master and 23.05 R7800 builds are tested before positing (router boots + wifi works). I don't own a C2600, EA7500v1, EA8500, G10, NBG6817, R7500v1, R7500v2, or d7800 (builds for these are untested - make sure you known how to tftp if you get in trouble)
Maximum ipq806x performance for Gigabit WAN connections.
Simple and compatible with master (able to flash back and forth if you like testing different builds)
Optimize support for 802.11 v/k
Simple set of packages focused on statistics / graphs / monitoring
NSS drivers for NAT offloading & SQM offloading (NSS Fq_codel)
USB / LEDs / Drive mounting works
Longer wait for failsafe button
OpenSSL Luci + Luci stats
Ath10k-ct or ath10k drivers builds. The builds with the “ath10k” in the name are running mainline firmware and drivers. The builds with no additional description are running the OpenWRT default ath10k-ct firmware and drivers.
Extras: IPv6 support, adblock, ddns, htop, openvpn-openssl, and wireguard.
Luci SQM and normal SQM config doesn’t work. Have to use custom config.
Appreciate feedback and improvements relative to the goals of the build
Appreciate config recommendations to optimize performance and 802.11 v/k
Appreciate developer support to fix bugs and maximize the potential of ipq806x with NSS hardware offloading support.
Master + NSS Hardware Offloading Download: (sysupgrade and factory image in bin folder)
Ipq806x Targets (most devices):
OpenWrt 23.05 (Stable) + NSS Hardware Offloading Download: (sysupgrade and factory image in bin folder)
Ipq806x Targets (most devices):
OpenWrt 22.03 (Stable) + NSS Hardware Offloading Download: (sysupgrade and factory image in bin folder)
Wireless Performance: (with the below settings on a R7800 using an iphone 2x2 client)
If you are building for one type of router you can change the first section of the diffconfig on github to just one device if you are building for a particular model (delete all the routers you don’t want to build for, follow the instructions below after the # sign):
# delete the “multi profile” line
# delete the line ending in ""
My diffconfig file is set up for ath10k-ct driver/firmware. If you want to use ath10k driver/firmware instead - use the diffconfig-ath10k file.
When your diffconfig is to your liking - this is how to prep and build (I have a 4 CPU system, change the last line to the number of CPUs in your system):
./scripts/feeds update -a && ./scripts/feeds install -a && cp diffconfig .config && make defconfig && ./scripts/getver.sh
Rebasing with Master, OpenWrt 23.05, or OpenWrt 22.03 (make sure you are in the openwrt folder, rebase with the latest updates - then you can build as per above)
#Remove “rebase” commit (this gives you a clean build environment - it deletes the final bin content and diffconfig files, I’d copy the diffconfig to a separate folder before running this command)
git reset --hard HEAD~1
git remote add upstream https://git.openwrt.org/openwrt/openwrt.git
git fetch upstream && git rebase upstream/master
#OpenWrt 23.05 Rebase:
git fetch upstream && git rebase upstream/openwrt-23.05
#OpenWrt 22.03 Rebase:
git fetch upstream && git rebase upstream/openwrt-22.03
If you need further help the OpenWrt wiki is well written and has further build system usage instructions:
Recommended configuration (build is the master defaults (CPU has been further optimized as per below), you’ll have to do all the rest yourself):
Firewall Software & Hardware offloading disabled
Use the default performance CPU governor (this is the build default)
Optionally you can use on demand settings (some report less stability):
uci set irqbalance.irqbalance.enabled=0; uci set network.globals.packet_steering=0; uci commit
Custom NSS fq_codel startup script if SQM is desired (below is set to 900/900). Recommend setting to 5% below your ISP provided speed and then adjusting from there as per your testing. Maximum is ~900Mbit.
ip link set up nssifb
# Shape ingress traffic to 900 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 900Mbit burst 1Mb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
# Shape egress traffic to 900 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 900Mbit burst 1Mb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
uci set wireless.default_radio0.ieee80211v=1; uci set wireless.default_radio0.ieee80211k=1; uci set wireless.default_radio0.bss_transition=1; uci set wireless.default_radio0.wnm_sleep_mode=1; uci set wireless.default_radio0.time_advertisement=2; uci set wireless.default_radio0.time_zone=CST6CDT,M3.2.0,M11.1.0; uci commit
Make custom DNS internal sites work (if you have custom sites):
ifconfig br-lan promisc
turn custom internal sites off:
ifconfig br-lan -promisc
kmods don’t install like normal on this build. If you want a custom set of kmods the best solution is to build from scratch (see above). Here is the full listing of packages that are built when I build:
Been a Kong fan forever but with a long holiday break I figured I give your minimal build a try since we have similar setups with multiple R7800s as APs and I'll have time to troubleshoot. Fast transitioning was a reason I briefly tried other builds over the summer to use DAWN but never felt it improved transitioning. Can you please post what you settled on now for a reliable DAWN configuration with the latest builds?
Note: One issue I've always had on my network setup is that I'm not able to use FT over DS and must use FT over the Air or else I get a long pause on my devices when they switch APs. If that is required for DAWN to work properly then that maybe part of the issues I've seen in the past.
802.11 v and k are still not a 100% in OpenWRT - I’ve included and activated as much as is out there and my transitions are pretty smooth. My APs all are hardwired to the original router and I’ve found ft over ds offers the best setup.
This is what I’ve added beyond turning on the majority of the dawn features (I don’t think the broadcast command does anything):
uci set dawn.@network.broadcast_ip='192.168.1.255'; uci commit dawn
uci add_list umdns.@umdns.network='wan'; uci commit umdns
This is my config- I’ll defer to @PolynomialDivision to see if he has any more tips on optimizing 802.11 k,v with the recent master commits + his dawn package
I was thinking of doing that but never done it before as I just used to flash Kongs build that already have those enabled, but if you can guide me on how to do that I would appreciate it, either here or drop me a PM. thanks.
@ACwifidude The last image I grabbed from you (20201208 OpenWrt SNAPSHOT r15149+64-28a9ac74cc) seemed to be the most stable so far. It ran over a week before rebooting. At least 10 days...
I logged in this afternoon and noticed that it rebooted ~ 3 days ago and decided to grab this 'latest' image (R7800-20201219-MasterNSS-sysupgrade.bin) but this did not load on my router. I had to do a tftp reinstall after I did a force install When I try to load this image over the one from 20201208, I get this:
Sun Dec 20 17:46:57 CST 2020 upgrade: Image metadata not present Sun Dec 20 17:46:57 CST 2020 upgrade: Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.
Did I do something wrong? I have images from your archive from 20201022 through the 20201208 and all 'just flashed' and rebooted.
That worked. I must have had a bad download or 'did it wrong' somehow. I'm now on OpenWrt SNAPSHOT r15241+72-3ab695368a.
The only issue I have had is the spontaneous reboot. It reboots pretty quickly, so it is not a huge deal, but, still... To me it feels like a stack issue or some memory issue because it 'just happens'. Does not seem to be dependent on wifi or 'heavy use'. Is there something I could be doing to diagnose the spontaneous reboot?