but awifidude image is from 6 days ago, does it contain this fix 22.03 image for r7800 dated 2022 08 01?
ACwifidude was referring to the following modified PPPoE patch he did a while ago (May 2022) in order to get it compiled in 5.10, so the build dated 2022 08 01 only had that patch (that unfortunately did not work with NSS acceleration for PPPoE).
commit 76281bddc698167750449393bba063aaa80ca863
Author: ACwifidude
Date: Sun May 8 08:53:12 2022 -0500
fix pppoe patch
Give @ACwifidude some time to merge the following new pull requests from tishipp and make appropriate changes (adding 3 additional kmod packages). Hope the build will have no major hiccup. You can then test to see if PPPoE offloading may work.
- back PPPoE offloading
- add DS-Lite offloading
- add L2TPV2 offloading
3 Likes
ok now I understand. sometimes the translations are not what they seem. thanks, waiting
yes.
both pppoe and ds-lite offloading work well.
cpu load is zero while running speedtest.
pppoe patch is taken fom robimarko’s branch.
ds-lite patch is taken from quarkysg’s branch.
4 Likes
I have built images based on 22.03.RC6 + all 6 tishipp commits + 4 additional required packages (kmod-qca-nss-drv-tunipip6, kmod-qca-nss-drv-l2tpv2, kmod-pppol2tp, ds-lite). The ath10k non-ct images include the latest ath10k firmware 2022-07-08.
Sorry I cannot test PPPoE since my provider is a WISP. If you're "courageous" enough, you can try them out. I did not upload the build-specific kmod packages, but can upload them if you may need them.
ath10k-ct:
ath10k (non-ct):
3 Likes
bcp38 depends on ipset, which in turn depends on kmod-ipt-ipset and accordingly uses iptables(-legacy) instead of having native nftables support. Mixing this (with fw4/ nftables being the default in 22.03~ and up) creates issues, from rather cosmetic ones up to race condition like behaviour with nftables and iptables having a different view of what netfilter is supposed to do (and the rule order).
Like any other package, it would be great if bcp38 would learn to use nftables directly and to integrate better into an fw4 based environment - at the moment it's easier not to install bcp38 (if that's the only reason for iptables-legacy being pulled in), than to deal with the mixture of ipt and nft.
1 Like
I'll look into it. bcp38 does not just do SAV but also prevents rfc1918 addresses from exiting your firewall to wander the net. I was pleased to hear @ACwifidude was shipping it (until now) by default.
2 Likes
Thanks for this! several dumb questions for someone not starting with a fresh configuration:
working in luci ...
-
is NSS hardware automatically used or do I configure it somewhere?
-
what about firewall->Routing/NAT Offloading ... set hardware offloading? clear software offloading?
-
stop using SQM?
any other config settings to touch or conflicts to watch?
thanks again!
M.
As long as your current device is running 21.02.x or later, you can upgrade to NSS image. Prior to the upgrade, make you sure you disable SQM as well as both Software Offloading and Hardware Offloading, as the NSS Offloading does not depend on any of these offloading settings.
If you want NSS-based SQM after upgrading to NSS image, you can enable NSS fq_codel by executing the following commands (and adding them to /etc/rc.local so they would be automatically executed after reboots). Be sure to change the example D/U speeds 600/200 Mbps accordingly. Set them to values that are about 5% less than your actual D/U speeds.
# Bring up nssifb interface
modprobe nss-ifb && ip link set up nssifb
# Shape ingress traffic to 600 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 600Mbit 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 200 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 200Mbit 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
that burst size is insanely large.
Thanks again - I disabled software+hardware NAT offload.
And it crashed after about 35 minutes of light web browsing. I don't know if there's a crash log anywhere ... I'll poke around before reverting to mainline 22 rc6
Ramoops should be in /sys/fs/pstore/ if they're generated.
Try to run without NSS fq_codel as it seems to make things a bit flaky in terms of random crashes.
was not running with NSS fq_codel; I just disabled irqbalance and am giving it one more go.
Is this build configured to write a ramoops?
does ramoops persist in /sys/fs/pstore beyond the next reboot?
Yes, ramoops is enabled: CONFIG_PACKAGE_kmod-ramoops=y
Ramoops will be persistent after warm reboots. They will only be gone after cold reboots (power-cycling).
Random reboots triggered by watchdog will not create ramoops.
Are you using ACwifidude's images or my images? My images have a bunch of new commits by tishipp and are only intended for people who wants to test PPPoE with NSS offloading.
no ramoops file after a reboot - no power cycle. probably bitten by the watch dog.
it's not coming up with the wireless showing good status ...
status/overview of radio0:
radio0
Type: Qualcomm Atheros QCA9984 802.11nac
Channel: 0 (0.000 GHz)
Bitrate: -
...but the connection is up and I'm using it. for this reply.
going to do a hard reboot just to get everything back to square 0.
Can you try to load the ath10k-ct image.
sorry, no - There's enough options in flight to make black box testing unworkable for me. I'm reverting to 22.03-rc6.
thanks for the help!
M.