Random network requests failures on router clients

kambala · January 18, 2026, 11:46am

Hi. I'm using Xiaomi Mi Router 3G v1 that runs 24.10.5, WAN uplink is 100 Mbit from ISP, only NAT IPv4 address is provided.

Sometimes I notice that random network requests fail, for example:

web page suddenly stops loading, file fails to download in browser
updates from iOS AppStore can't install
apps fail to make network requests

In all cases a simple re-attempt (but could be on second or third try) succeeds.

This can happen to both wired and wireless clients, I mostly use macOS and iOS devices and noticed the issue there. Noticed the issue right on the day 1 since I started using the router.

At first I thought that the router is buggy somehow, so I've temporarily switched to the good old ASUS WL-500W and hooked 1 wired and wireless client to it and haven't seen these issues.

My another suspect is my home server seeding torrents, it's connected by wire to the router. I've recently stopped seeding and so far not seeing any network issues on router clients. But it's not seeding like 10 MB/s all the time, and IIRC when I looked at the speed at the moment of failure it wasn't that high.

A few weeks ago I changed ISP. The previous one was providing me fiber connection and also a router (not running OpenWrt) that received the fiber as WAN, uplink was 200-300 Mbit and I haven't seen any kind of issues described above. The router was Sercomm v4, it has similar CPU as my Xiaomi if I understood correctly (and also 256 RAM), so hardware doesn't seem to be an issue.

Router's RAM usage is always below 50%, CPU also doesn't go higher than 1.0 normally, actually it's usually below 0.50. When seeding torrents number of connections is around 4k according to the router's web gui.

Not quite sure how to troubleshoot / fix this or reproduce reliably, hope for the community help.

detailed config

# ubus call system board
{
	"kernel": "6.6.119",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "Xiaomi Mi Router 3G",
	"board_name": "xiaomi,mi-router-3g",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.5",
		"revision": "r29087-d9c5716d1d",
		"target": "ramips/mt7621",
		"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
		"builddate": "1766005702"
	}
}

# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd24:802c:c937::/48'
	option packet_steering '1'

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

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

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

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option norelease '1'

# cat /etc/config/firewall

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

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

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option masq6 '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 redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'torrent mini'
	option src 'wan'
	option src_dport '49743'
	option dest_ip '192.168.1.109'
	option dest_port '49743'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'torrent debsrv'
	option src 'wan'
	option src_dport '14051'
	option dest_ip '192.168.1.100'
	option dest_port '14051'

brada4 · January 18, 2026, 12:15pm

Are you behind double nat?

kambala · January 18, 2026, 12:27pm

yep

only NAT IPv4 address is provided

brada4 · January 18, 2026, 12:44pm

Freezes look like path mtu fails, try wan mtu 1500 -4 -8 -12 for wan interface if the providers uplink is one of those pppoe or vlan or both to fit in the pipe. You dont need wan metric parameter nor masq6, otherwise all looks default and expected to work perfectly.

kambala · January 18, 2026, 1:36pm

thanks! Set it to 1496, let's see if it makes any difference.

I set metric as instructed by CF WARP instructions when trying to configure it on the router, but not using it currently, so removed.

Execuse me, what is masq6? IPv6 assignment from ISP?

brada4 · January 18, 2026, 1:47pm

masq6 is if you get 1 ip6 address from your mobile ISP and do something like ip4 nat to fit home network behind it. You can remove the parameter, it has no effect whatsoever. I just identified those few parameters that are different from defaults.

kambala · January 18, 2026, 2:10pm

thanks, that's exactly what I thought.

Just observed the issue again. Torrents on the home server were seeding at 50-70 Mbit/s, and Qt application couldn't make network requests with "connection refused" really often. As soon as I stopped seeding, the errors were gone. Will try to lower MTU even more then.

Here's router's load at that time:

brada4 · January 18, 2026, 2:32pm

Openwrt does not refuse new connections, it would be timeout. Likely you are killing upstream nat. Just halve your torrent connections.

lleachii · January 18, 2026, 2:48pm

Login to the LuCI web GUI. Tell us what "Active Connections" says on the main Overview page when this occurs.

kambala · January 18, 2026, 5:14pm

at that time it was 5k-something

kambala · January 20, 2026, 10:17am

I've reduced torrent connections by a few times, now it's (previously it was 500/200/50/50 IIRC):

However, number of connections according to OpenWrt didn't really go down and I still experience the issue from time to time, even when upload speed isn't that high it seems. Also, when I check number of active connections on the home server with ss -s, it's always below 300.

My LAN has 2 active wired clients (the server and a Mac), 1 active wireless Mac and a few "sleeping" wireless clients (iPhone, iPad, Apple TV).

Is my only option to bug ISP to do something with their switch then?

brada4 · January 20, 2026, 10:45am

UDP "connections" live relatively long, make it TCP?

kambala · January 20, 2026, 11:07am

changed to TCP only, now OpenWrt shows 8k+ connections at a really low upload speed 2 MB/s and the issue manifests again. Previously I never saw it to be higher than 6.5k.

kambala · January 20, 2026, 12:07pm

now did the contrary: disabled TCP in qBt settings leaving only μTP (which is UDP I guess), and now no more issues it seems. Will be observing during the next days.

brada4 · January 20, 2026, 12:16pm

Check sysctl net.netfilter syn_sent and udp timeouts are triggered by a single packet and keeps 450-490B ram till expiring.
Basically you will get a lot seminal states for first x (depends on files, more for rare files, minute for debian iso) minutes until stable peer connections are set up and data transfers go ahead.

kambala · January 20, 2026, 5:13pm

I have

net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_udp_timeout = 60

does it make sense to lower them?

brada4 · January 20, 2026, 5:47pm

Just an obdervation of the fact that conntrack states can exceed number of beneficial connections. Nothing to fix.

timur.davletshin · January 20, 2026, 7:09pm

https://forum.openwrt.org/t/when-running-a-torrent-the-vless-connection-to-the-server-via-podkop-is-disconnected/ - probably related and probably not. But qBittorrent has odd defaults IMO. Long story short: problem is in qBittorrent's defaults, not OpenWrt's faults. Prefer uTP over TCP (uTP uses less agressive congestion control algo) and, if you can, setup fq_codel on your client PC. Kernel-space TCP congestion control is too agressive and easily overloaded by bittorrent.

kambala · January 21, 2026, 6:58pm

thanks!

so far with UDP-only all seems ok with high number of active connections, but I don't think I saw high upload speeds yet.

I've also found out a qBt (or rather libtorrent) setting μTP-TCP mixed mode algorithm which was at "prefer TCP" by default, now I changed it to "peer proportional (throttles TCP)" and also reverted back to using both UDP and TCP, will see how it goes once.

if you can, setup fq_codel on your client PC

I guess by "client PC" you mean the PC that is seeding torrents? Do I understand correctly that it'd mostly affect only that PC and not all LAN devices? If so, then it's not really needed to me as the home server basically does nothing else most of the time w.r.t. network.

timur.davletshin · January 21, 2026, 7:15pm

That's the part I described as 'odd defaults'. uTP was designed exactly for that reason - need for less aggressive algorithm.

Yep. But it is a bit complex. qBittorrent has DSCP support (unlike broken in my dated Transmission 3.0) and you should use it. But on the other hand Transmission can employ less aggressive congestion control algorithms even for TCP connections. I use Transmission with LP congestion control for TCP + DSCP (and SQM on OpenWrt). It works well. I can make VoIP calls even on highest load. Regarding fq_codel: I have no idea what distribution you use, some already come with it, others use fifo.