Frequent Disruptive Packet Loss and High Latency

Router Model: Netgear R6900 v2
cat /etc/openwrt_release

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='25.12.2'
DISTRIB_REVISION='r32802-f505120278'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 25.12.2 r32802-f505120278'
DISTRIB_TAINTS=''

I recently flashed OpenWRT onto my router since it had reached Netgear's end of service life and I'd been wanting to try OpenWRT for a while anyway. While I've been pleased with much about it, I immediately noticed issues with my Steam Link constantly stuttering and dropping quality. I was worried it was an issue with OpenWRT but considering the age of the Steam Link and the many issues I've had with it already, I hadn't bothered looking into it. I've also been having issues when playing Old School RuneScape that I'd previously chalked up to the fact that I'm on an older laptop (though with a nearly brand new wireless adapter) and the same has been the case for my girlfriend, but recently it has had extremely noticeable and frequent stuttering and even complete connection loss which prompted me to look into the possibility that the issue is related to the router. All devices mentioned are in the room directly beside the router and did not have these same problems prior to switching to OpenWRT.

I tried pinging a few sites from my laptop and found there to frequently be 5% or more packet loss and then tried pinging the router's IP with the same results. The latency average tends to range from 3-30ms with max latency tending to be 30-200ms both when pinging from my laptop and when pinging from the router. Latency is extremely inconsistent. I have also ssh-ed into my Steam Link and tried pinging the router several times which doesn't frequently show any packet loss, 1% at most when I've tested, but the average latency tends to be around 60-100ms with a maximum of 200+ which is the same when I ping the Steam Link from the router. When using the Steam Link's analytics overlay, it shows very little packet loss but frequent and significant frame loss, often 30% or more.

When testing from my desktop connected through ethernet, it performs completely normally with very little latency and no packet loss. I've been searching everywhere for solutions but haven't found anything that seems to address the problem. If there is any additional information needed to diagnose the issue, let me know.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Screenshot 2025-10-20 at 8.14.14 PM

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Which routing/connection devices are in use? Is there a ISP modem or router?

Or does your Openwrt box directly connect to ISP via wall rj45 socket, or so?

One possible generic reason could be a subnet conflict with an ISP router, e.g. both using 192.168.1.x so that the OpenWrt router has that subnet both on wan and lan. (The router's OEM firmware may have defaulted to some other subnet like 192.168.0.x, which could explain why the problem started after adopting OpenWrt and got the conflict.)

What is the wan IP address of the OpenWrt router? (And the Lan address is the default 192.168.1.1 ?)

Info requested by lleachii at the bottom.

There's only the OpenWRT router in question connected to the ISP via wall rj45 socket.

I'm hesitant to share the wan IP on a public forum, particularly since it's a static IP, what is it needed for? As for the lan address, it is the default 192.168.1.1

It would almost make sense for there to be some kind of subnet conflict, particularly since at some point prior to flashing the OpenWRT firmware, the router had unexpectedly changed from its original default of 192.168.1.1 to 10.0.0.1. That was confusing to me but I wasn't having any issues so I never really looked into it and assumed it had something to do with a recent firmware update. I can't imagine what would have caused that though. No new devices were added anywhere into the network.

ubus call system board
{
	"kernel": "6.12.74",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "Netgear R6900 v2",
	"board_name": "netgear,r6900-v2",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "25.12.2",
		"firmware_url": "https://downloads.openwrt.org/",
		"revision": "r32802-f505120278",
		"target": "ramips/mt7621",
		"description": "OpenWrt 25.12.2 r32802-f505120278",
		"builddate": "1774469393"
	}
}
cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	list ipaddr '127.0.0.1/8'

config globals 'globals'
	option dhcp_default_duid '0004c1efadd77abc41bbb1898fe77af21b1a'
	option ula_prefix 'fd19:9cf3:6157::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	list ipaddr '192.168.1.1/24'
	option ip6assign '60'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

config rule 'gndnsrl'
	option mark '0x8260035'
	option lookup '53'

cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '2g'
	option channel '9'
	option htmode 'HT20'
	option country 'US'
	option disabled '0'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid '**********'
	option encryption 'psk2'
	option disabled '0'
	option key '**********'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option band '5g'
	option channel '128'
	option htmode 'VHT160'
	option country 'US'
	option disabled '0'
	option cell_density '3'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid '**********'
	option encryption 'psk2'
	option disabled '0'
	option key '*********'

cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/odhcpd.leases'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
	option piodir '/tmp/odhcpd-piodir'
	option hostsdir '/tmp/hosts'

config host
	option ip '192.168.1.12'
	list mac '**:**:**:**:**:**'
cat /etc/config/firewall

config defaults
	option syn_flood '1'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone 'gnunetvpn'
	option name 'gnunetvpn'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone 'gnunetexit'
	option name 'gnunetexit'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config forwarding 'gnexitfwd'
	option src 'gnunetexit'
	option dest 'wan'

config zone 'gnunetdns'
	option name 'gnunetdns'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config rule 'gndnsrl'
	option name 'Mark-local-DNS-for-GNUnet'
	option proto 'udp'
	option dest_port '53'
	option extra '-m owner ! --gid-owner 452-453'
	option target 'MARK'
	option set_mark '136708149'

config rule 'gndnsrl2'
	option name 'Mark-forwarded-DNS-for-GNUnet'
	option enabled '0'
	option src '*'
	option proto 'udp'
	option dest_port '53'
	option target 'MARK'
	option set_mark '136708149'

In this case, only the first two blocks should be sufficient. Like 43.44.x.y.

You have a second routing table?

Firewall option extra is not valid in this version.

(Is there important networking information you failed to discuss?)

You don't specify any [existing] networks on these 3 zones.

Is WAN 192.168.1.x?

(If so, it's not public.)

Again, the information is needed to know if there's a conflict.

In that case, WAN IP is 184.174.x.y

Not that I was ever aware of.

As far as I recall from setting things up, I never knowingly set that option. I don't remember really doing anything with the firewall when I set it up. I'm pretty sure I just left the firewall more or less default.

There aren't, or at least there shouldn't be. I'm honestly not sure where those zones came from unless they were added recently when I installed some gnunet-related packages due to logread showing a lot of errors related to gnunet in one way or another and I was wondering if those errors had anything to do with the problem. I've considered removing gnunet but wasn't sure if it had any important function in OpenWRT since I don't know much about it.

I installed adblock after getting the router running and my girlfriend installed a couple more packages she was interested in all through the LuCI interface (the only one we remember was zerotier, though reading the gnunet description in the software list looks like one she would have added). Other than adblock, we haven't configured or used any of them at this point. If it would help, I could add the full list of software installed, but I don't want to needlessly make a long post with the full list from "apk info" if it's unnecessary.

Did you have these issues before installing packages?

I honestly don't know. We didn't really do much before installing packages. I looked into the adblock pretty much as soon as OpenWRT was up and running and while getting that set up, we added the others.

I suggested resetting to default settings and not installing the extra packages. For example:

Why did you install this if you don't know much about it?

This, i can understand. It's really useful.

This... can become problematic. Not every combination of additional packages will work together.
Gnunet, for example is just a alpha release. I wouldn't install a package in this early
state on my main router.
What is your goal? If you want to test out some packages that might or not might be interesting or beneficial, i'd suggest to get a additional router and put it between your main router (with only the important packages installed) and your client devices.
In the case you brick it, you can just reset it to default and start from scratch without endangering your main internet connection.

I've gone ahead and uninstalled gnunet and everything else that appeared to be something installed after setting up OpenWRT with the exception of adblock as well as nmap since nmap doesn't leave active processes when not in use.

At present, I'm seeing noticeably less packet loss than previously, though it's still being disruptive but inconsistently between devices and times (some devices have it worse at some times and others at other times). I'm also still seeing large, inconsistent spikes in latency and the Steam Link is still seeing significant frame loss (mostly at 13% and pretty much never below 5%). I'm hesitant to reflash the firmware and start from scratch just because I don't want to have to get set everything up again and make sure every device is reconnected. At this rate, I am seriously considering that, but I'm also not confident that the problem will be solved that way. Is there any other way to remove any additional software that I've forgotten was added manually and doesn't require setting everything up again?

Gnunet seems like it might fit in with some projects we've been working on with some p2p stuff, but we need to play around with it some. I guess we'll just toss it on another router when we're ready to work on that.

I performed a soft factory reset about a week ago. Initially I thought it was better, though there was still not-unnoticeable packet loss and large latency spikes. After a few days I put ad block back on and didn't notice any significant change in packet loss and latency. A few days later, I started noticing even worse packet loss and latency spikes than before, sometimes rendering online games unplayable. The problem is still inconsistent across devices and times (e.g. sometimes my laptop has it bad, sometimes my phone has problems, sometimes my girlfriend's laptop has issues, but not necessarily every device at once). The issues did not get this bad immediately after putting ad block back on, only after a few days.

I am still at a loss for what's going on here.

Are these devices connected via wireless?