Does anyone want to test my new build?
I've modified a few things in ACwifidude's build.
kmod-ovpn-dco package and others are enabled.
3 Likes
Dear ocformula,
I will be much obliged to give your build a try. Thanks for all you do.
Peace
Hello, not sure it's the right place to ask that, sorry in advance if it's not the case
I have 2 R7800 running NSS enabled builds from @ACwifidude , based on 22.03 stable (2 different snapshots at different dates).
I'd like to play a little bit with mdadm tool and RAID stuff but can't install anything due to kernel dependency missing for the raid kernel modules that opkg wants to install. I'm a little bit puzzled on how I should proceed to get and install the right packages versions.
Should I configure opkg to use another packages repository?
Should I use another build based on master or 23.05?
Regards, Etienne.
The modules you need are gone. Once a rebase including a kernel bump was done they disappeared for good.
Besides not sure if @ACwifidude builds the raid modules.
You will need to build your own image.
You could also try any of the builds I have posted on this thread (usually long posts, sorry). The modules you need should be in their repos. You should be able to sysupgrade to any of those builds keeping your configuration and then either manually copy packages in and install, or better yet point opkg to GitHub (details on my posts) to have it install what you need.
thankds @apccv for the reply. You're confirming what I was thinking, I couldn't retrieve modules versions corresponding to my image as it's a snapshot and modules versions in that repository evolve in time.
I already checked @ACwifidude packages repository and raid modules are not present.
So the solution would be to rebuild my own NSS enabled image, based on a stable release of OpenWRT in order to maintain the availability of modules in time, which is somehow what you did if I understand well.
edit: and anyway, thanks for the length of your posts, there are valuable info there.
https://forum.openwrt.org/t/is-openvpn-dco-supported/165801
Unless you've hacked in openVPN 2.6x, doesn't your build have 2.5x, which doesn't support DCO?
In case anyone wants to try it out... here is the 23.05.0-rc2 "as close to vanilla as possible with NSS support" build.
Images for all supported devices in the bin directory.
Feel free to check the commit history on this or any of the previous repos. It is usually clear from it which commits need to be cherry-picked to add NSS to the vanilla image.
config.nss has the basic ipq806x build conf plus 9 lines to add NSS support. Same packages as the vanilla build. Everything else you might need is available in repo. If there is interest I can post the ImageBuilder online and add a link here.
Similar to previous builds:
- All
genericimages are built. All modules are built. - Key for package signature verification is in
opkg-keyfolder and can be copied to/etc/opkg/keysdirectory after flash to use this repo for packages. -
/etc/opkg/distfeeds.confcan be updated after flash to point to this repo for packages. Replacehttps://downloads.openwrt.org/releases/23.05.0-rc2/targets/ipq806x/generic/packages/url withhttps://raw.githubusercontent.com/APCCV/OpenWRT-23.05.0-rc2-NSS/v23.05.0-rc2/bin/targets/ipq806x/generic/packages/. Should look like this:
#src/gz openwrt_core https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ipq806x/generic/packages
src/gz openwrt_core https://raw.githubusercontent.com/APCCV/OpenWRT-23.05.0-rc2-NSS/v23.05.0-rc2/bin/targets/ipq806x/generic/packages
src/gz openwrt_base https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/base
src/gz openwrt_luci https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/luci
src/gz openwrt_packages https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/packages
src/gz openwrt_routing https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/routing
src/gz openwrt_telephony https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/telephony
#src/gz openwrt_nss https://downloads.openwrt.org/releases/23.05.0-rc2/packages/arm_cortex-a15_neon-vfpv4/nss
In all it's glory:
BusyBox v1.36.1 (2023-06-26 11:20:39 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.0-rc2, r23228-cd17d8df2a
-----------------------------------------------------
Seems to be doing something (testing as an AP)...
root@OpenWrt:~# cat /sys/kernel/debug/qca-nss-drv/stats/virt_if
if_num 33 stats start:
rx_packets = 6081962
rx_bytes = 3986460368
rx_dropped = 54147
tx_packets = 6749073
tx_bytes = 150048410
tx_enqueue_failed = 0
shaper_enqueue_failed = 0
ocm_alloc_failed = 0
if_num 33 stats end:
base node stats begin (shown on if_num 33):
active_interfaces = 4
ocm_alloc_failed = 0
ddr_alloc_failed = 0
base node stats end.
Behaves as expected (WiFi):
2 Likes
Probably yes. The DCO included in the build won't do anything.
I didn't apply any patches, just added a setting in the config file.
I know that the SSL/TLS libraries used in OpenWrt are mbedtls, wolfssl, and openssl.
But most of the NSS support builds I've seen here are built with packages that use openssl, like wpad-openssl, openvpn-openssl, etc.
Is it that NSS has hardware acceleration of SSL/TLS, and only openssl supports it?
1 Like
NSS unfortunately does not accelerate anything with encryption with OpenWrt. OpenSSL is just a preference and is pretty compatible. Any of those SSL libraries should work fine. 
p.s. updated the 23.05 and Master builds today. Added in @KONG sqm scripts for people to play with if they need easier SQM. Thanks @KONG for the great work!
7 Likes
well, i mean, it can
it just breaks at a certain block size and isn't fast enough to justify the trade off
While running the image I built, I saw the following messages in the system log.
Did I configure something incorrectly?
Has anyone seen the following message in the log?
Wed Jul 19 20:29:54 2023 kern.info kernel: [56816.109421] mdio-gpio mdio eth1: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:29:58 2023 kern.info kernel: [56820.502348] mdio-gpio mdio eth1: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:30:02 2023 kern.info kernel: [56824.067577] mdio-gpio mdio eth1: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:26 2023 kern.info kernel: [57208.199587] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:26 2023 kern.info kernel: [57208.207267] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:29 2023 kern.info kernel: [57211.137503] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:29 2023 kern.info kernel: [57211.169930] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:30 2023 kern.info kernel: [57212.257344] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:31 2023 kern.info kernel: [57212.652362] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:31 2023 kern.info kernel: [57212.726622] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:36 2023 kern.info kernel: [57218.018370] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:52 2023 kern.info kernel: [57233.677932] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
Wed Jul 19 20:36:52 2023 kern.info kernel: [57233.702359] mdio-gpio mdio eth0: nss_gmac_xmit_frames: dropping skb
whose build / archive / version ?
any build of openwrt 23.05.0-rc2 with nss
I haven't been active here for a while, for this very reason: I got a x86 mini pc for routing and configured all my R7800's and a single C2600 as dumb AP. But all dumb AP's run the NSS build from ACwifidude. I too want to regularly update devices, router and dumb AP's. Now when I'm honest, I haven't updated those devices the last 7-9 months or so because it's all darn stable. And fast.
I just read this post from @apccv and this is the reason I still use the NSS build from @ACwifidude on my dumb AP's. I haven't done much measurements back then but I came to the same conclusion that what ACwifidude did to implement NSS also benefits wifi. I run my R7800's with a fixed CPU frequency and they're pretty darn stable with that (with a build from somewhere around November 2022).
Now I have been looking at IPQ807x development but don't really need to upgrade for the sake of WiFi speed. I did want speed and stability on my 1Gbit/s symmetrical Ftth connection and good SQM. So I decided to repurpose my routing-R7800 as a dumb AP and purchased a small x86 mini PC (Intel N5105) which hardly breaks any sweat at all. It's a massive overkill on CPU power but it's just about the same in power consumption as a R7800.
The culmination of my efforts and tweaking WiFi with separate vlan's for traffic and dedicated SSID's on 5GHz for user devices and 2.4GHz for IoT devices was when our child had a Teams meeting with someone the other day. The meeting included audio and video. The call was started on the attic, then moved to the second floor through all rooms, then moved to the ground floor, then went outside around the house on a regular laptop and not once did the Teams call stutter. I was working from home during that Teams call. During this walkabout in and around the house with only 5GHz WiFi was an excellent test that showed me fast roaming works as intended too, since I have 3 R7800's and one C2600 scattered throughout the house. All are connected to the x86 mini PC with a LAN cable.
It took me a few years to learn the hard way but I'm very, very pleased with how this has been working so far. With commercial hardware I would've spent around €800 to €1000 I guess. But by using solely OpenWRT and the awesome community I've spent around €110 on used R7800's and a C2600 and around €200 on the N5105 mini PC. And I have more control on what happens in my network.
7 Likes
I wish using a fixed cpu clock with this router family were much more emphasized - to the extent that cpu governors be removed as options. Those who have set a constant cpu clock don't seem to have stability issues, some who use a governor do.
My 0.00002, just because the code offers a feature doesn't mean it should be used or that it actually works. Using a fixed clock also suggests the crashes which do happen can be more actively investigated without wondering about the stability of the underlying system.
[Research idea - load oem firmware and monitor if/how the clocks are scaled.]
Again, my 0.000019. I'll reload 23.05 and power-cycle my r7800 to see if i get a better crash report. I'm happy to use 22.03 for a long time, 23.05 after that.
2 Likes
Love it! Glad you have great results - definitely worth it putting in the time to have ideal physical locations, hardwiring all the devices together, and keeping the fast devices on 5ghz only for good speed / consistent predictable roaming. The small x86 boxes are tempting and probably very enjoyable to have that great performance.
Bad wifi planning and implementation is rampant. Every time we travel my family regularly complements our home setup and wishes the wifi was as good as it is at home (three R7800’s). We have enterprise performance at home without enterprise prices.
@Mpilon all the builds now have the performance governor as the default. I too hope people use this fixed CPU speed to eliminate any crashes from switching frequencies. The minimal thermal difference of on demand isn’t worth it for these devices.
4 Likes
That's exactly my point.
You are doubling your power consumption, since you MUST keep your 7800 as AP
I was decided to pass to x86 (very intrested in N100 with 6W TDP), but the fact i need to keep another device for wifi is a mess
@apccv I've just installed your R7800 build, after trying a few others (again issues). It's looking good so far, speeds are good but I haven't tested SQM yet, doing a long term ping test now to see if any strange things happen, while doing my normal work. Alone in the house now so I can ultimately only annoy myself...
Update: I did the SQM config, configured 385/38 Mbps (95% of isp bandwidth) and the connection is still nice stable, bufferbloat test result now gives me an A. I'm very happy so far!
I guess it depends on your situation; how’s your house constructed? What requirements do you have? I used to have a single R7800 on the groundfloor in my previous house. It was just about in the center of this floor and because the R7800 is great in WiFi transmission, it suited me just fine. I got the first R7800 with a 200/20Mbit/s cable connection so the vanilla OpenWRT was excellent. When I switched to a 500/500Mbit/s Ftth in my previous house I switched to this excellent NSS build. In 2021 I moved to another house, a tiny bit larger but with a bit more concrete and steel. My trusty R7800 couldn’t reach the corners of that other house anymore.
So I had to add more devices, which includes a bit more power consumption overall. For a PoE solution, the requirements for power are going a bit up. WiFi 6 should not increase power consumption according to specs, but we do see an increase in power consumption with newer WiFi routers that also support WiFi 6.
But I understand, needing more than one device for WiFi and routing feels a bit unnecessary. But technology, buildings and needs change… NSS builds like these are great to keep good devices around a bit longer if you ask me. Even with more flexibility.
1 Like