Hello all using KONG 21 r16521+1-b1c3539868 on a R7800 and just wondered has something changed in the way you mount a USB drive (ntfs) as i've tried everything i normally do to mount a drive which isn't working
Drive is listed under Mount Points but can't add to Mounted file systems so i can share via Network Shares, have tested 3 drives so far
Hello Friends,
I'm running KONG 21 r16521+1-b1c3539868 / LuCI branch git-22.052.50801-31a27f3 on my R7800. I'm running an At&t BGW210 in passthrough mode to my R7800 (At&t Fiber connection 350 up/down). IPV6 is finally working. I have both my PC and my wife's iMac wired in (both 25ft cat6 cables). I've replaced the cables, so it's not that.
The problem I'm having is frequent ethernet dropouts on my desktop. I added the performance tweak to startup, and that seemed to slow down the disconnect to once every hour, instead of every minute or so.
My system log is being spammed with this message:
daemon.warn odhcpd[1292]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
(seems to happen every 10-ish minutes or so)
Then my Kernel log is giving me this error frequently:
[ 58.024459] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 58.024601] br-lan: port 2(wlan1) entered blocking state
[ 58.029885] br-lan: port 2(wlan1) entered forwarding state
[ 64.237654] ath10k_pci 0000:01:00.0: Unknown eventid: 36933
[ 64.243690] br-lan: port 3(wlan0) entered blocking state
[ 64.243724] br-lan: port 3(wlan0) entered disabled state
[ 64.248397] device wlan0 entered promiscuous mode
[ 64.253562] br-lan: port 3(wlan0) entered blocking state
[ 64.257965] br-lan: port 3(wlan0) entered forwarding state
[ 64.265897] br-lan: port 3(wlan0) entered disabled state
...etc.
I have both the iMac and my PC now set to static IP in hopes that it would solve the issue, but there was no change.
Any ideas on how to keep my wired connections from dropping out?
@KONG Is there anything in your latest 22.03 NSS build that would stop the default IPv6 configuration working? Something with the new firewall I have to enable or something? Updated from your last 28/02 NSS Trunk build and I'm no longer getting an IPv6 WAN address.
I don't think any firewall stuff should block getting ipv6 address. Unfortunately I don't use ipv6, thus can't really do a quick test. re there any log entries for odhcpc? Is odhcpc6 running on the right interface, e.g.:
odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 eth0.2
Just about to install the 2022-03-26 version so will report back if i see any problems
Just installed using a Billion BiPAC 7800N as a Modem with my R7800 and ipv6 working as normal my end
Thanks @KONG @Eyerex - I'll continue to investigate, It might be an issue with my ISP that just happens to have occurred when I upgraded/re-connected/re-authenticated.
Kong, this is a very nice build. Running very smoothly and a very clean log but for two areas.
I'm using your NSS build from 22.03 -
Preformatted textKONG 21 r19208-3adbc03471 / LuCI branch git-22.083.69105-af8e91c.
The following exceptions pop up:
Mar 29 11:27:54 OpenWrt https-dns-proxy[5213]: [E] 92232.1648553274 (null):582830 612B: Setting HTTP/2 version failed with 1: Error
Mar 29 11:27:54 OpenWrt https-dns-proxy[5213]: [E] 92232.1648553274 (null):582862 Try to run application with -x argument! Falling back to HTTP/1.1 version.
Mar 29 11:27:54 OpenWrt https-dns-proxy[5212]: [E] 92232.1648553274 (null):583040 612B: Setting HTTP/2 version failed with 1: Error
Mar 29 11:27:54 OpenWrt https-dns-proxy[5212]: [E] 92232.1648553274 (null):583060 Try to run application with -x argument! Falling back to HTTP/1.1 version.
Mar 29 11:27:59 OpenWrt procd: /etc/rc.d/S95done: /etc/rc.local: line 10: can't create /sys/devices/system/cpu/cpufreq/ondemand/up_threshold: nonexistent directory
Mar 29 11:27:59 OpenWrt procd: /etc/rc.d/S95done: /etc/rc.local: line 11: can't create /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor: nonexistent directory
Mar 29 11:28:00 OpenWrt privoxy[]: Scheduled startup in 10 seconds
Again, a great build! I really appreciate the effort you put into these releases.
ATT is currently running fiber cabling in my neighborhood, higher speed connections will be available in a couple of months. I'm wondering what kind of problems, if any, anyone experienced moving to a 1G connection. I'm running a r7800 with Kong's latest 21.02 firmware, currently connected to the Inet at 50Mbs.
no access anymore to kong's builds?
ok thanks, but my link to trunk does not work, maybe he removed it
Trunk version is now called v 22.03
Ok no.more master
22.03 working perfectly for 3 days now without an issue. It seems pretty stable. Only to be a little fussy about bugs, SSH session with 22.03 still shows "KONG 21" 
I just realized.....is "flow offloading" option missing in current kong nss firmware? I did my last speed test months ago without issues, but now it seems I cannot reach even a 50% speed of my 1gb connection (EA8500). In network>firewall>general I have no flow offloading checkboxes....
Either you use software flow-offloading (then you don't need nss) XOR you use nss (then flow-offloading would only be harmful).
Actually, I think it may be beneficial to have both and from my understanding, both are mutually exclusive and both works nicely with the netfilter hooks. NSS does not accelerate all traffic, e.g. WireGuard or OpenVPN (what I mean is for the netfilter bypass instead of encryption.)
Having both on may help reduce CPU load for traffic not handled by NSS.
I guess the only way to test this is to have it enabled on a ipq806x routers with NSS and software flow-fofloading enabled.
My assumption (read this as wild guess) would be that enabling flow-offloading would force the offloaded flows from the nss data path into the netfilter processing (where it would take it the software flow-offloading short circuit). Maybe it is smarter, maybe it could be taught about being smarter, but in a sense this feels mutually exclusive. And at least for the bulk if the traffic, nss offloading should be the fastest option.
From what I understand of the NSS flows, it will take over the flows when there are ESTABLISHED or ASSURED flows for both TCP/UDP traffic. When netfilter's connection changes to one of those (for interfaces that's managed by NSS), NSS ECM will notify the NSS firmware that it is ready for NSS to take over from ingress of the input port to the egress port. When this happens the network frames will not go in the Linux network stack. NSS will only periodically update the interfaces stats to the Linux network stack.
I think this is the same strategy the all netfilter offload does, whether it is hardware of software.
For frames received by NSS that's not updated as being offloaded, or when the egress interface is not managed by NSS, it will forward the frame up the Linux network stack. In this instance, netfiler flow-offload will take over. It's like frame being received from the network switch.
So I think NSS and software flow-offload should complement each other.