New OpenWrt installation on a TP-Link Archer C7 v2 is slow - speed cut in half

Hi there,

I just installed OpenWRT and it cut my internet speed in half on my TP-Link Archer C7 v2.

Speedtest.net showed me 270Mbps on the 5g wifi network. After installing OpenWRT the speed has dropped to 123Mbps.

All I did to configure OpenWRT after installing it was to setup the root password, configure the wifi networks (2.4 and 5g), and put in custom DNS servers (Quad9).

I'm fairly familiar with networking and internet connectivity and how most of it all works. I also understand that speedtest.net is not the "authoritative measurement of internet speeds", but it can be a decent measurement. And pings are a lot longer now at around 250+ms each (using the OpenWRT Diagnostics page), browsing is much less snappy (I'm using the same DNS servers as what I set on the TP-Link firmware, Quad9).

Yes, it could be my modem, or my ISP, or the internet at large, or the root beer I spilled on my laptop (just kidding), but I'm pretty much certain that it is the OpenWRT firmware causing the slowdown. I even used pcWRT firmware before this and had similar slowdowns (it's based on OpenWRT).

I've flashed back to the TP-Link firmware twice now and each time using the TP-Link firmware it's been much faster, and much snappier when browsing.

Anything I can do to speed this back up? Please help!

By the way, here are my /etc/config/network and /etc/config/firewall files, in case they help.

/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 'fd1b:ca44:2d68::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

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 'eth0.2'
	option proto 'dhcp'
	option peerdns '0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'wan6'
	option device 'eth0.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

/etc/config/firewall:

config defaults
	option syn_flood	1
	option input		ACCEPT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

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

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

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
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

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
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

# Allow essential incoming IPv6 ICMP traffic
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

# Allow essential forwarded IPv6 ICMP traffic
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


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option dest		wan
#	option proto	tcp
#	option target	REJECT

# block a specific mac on wan
#config rule
#	option dest		wan
#	option src_mac	00:11:22:33:44:66
#	option target	REJECT

# block incoming ICMP traffic on a zone
#config rule
#	option src		lan
#	option proto	ICMP
#	option target	DROP

# port redirect port coming in on wan to lan
#config redirect
#	option src			wan
#	option src_dport	80
#	option dest			lan
#	option dest_ip		192.168.16.235
#	option dest_port	80
#	option proto		tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#	option src		wan
#	option src_dport	22001
#	option dest		lan
#	option dest_port	22
#	option proto		tcp

### FULL CONFIG SECTIONS
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port	80
#	option dest		wan
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp
#	option target	REJECT

#config redirect
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port		1024
#	option src_dport	80
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp

Stock firmware is highly optimized for speed. OpenWrt being a general-purpose firmware will require more CPU power for the same speed, and the Archer C7 does not have a lot of CPU power.

You can improve ping time and "snappiness" by running SQM, but you will have to limit the overall bandwidth to much less than your ISP rate to avoid saturating the CPU.

1 Like

That's not correct, it's doing 2x the speed compared to stock with software offloading here at v21.02.5 , this is related to the nftables issue not working with VLAN SFE.
@anon51220223 have you tried downgrading? Then enable offloading in firewall.

Thanks for your answers.

Makes sense, @mk24. Although, I'm not sure what SQM is.

@anon82289434 No, I haven't tried downgrading yet. In that link you provided he mentions it being to do with PPoE. I don't think I'm using PPoE, though - isn't that a VPN thing? Would 21.02.5 still benefit me, you think?

Also, how would I downgrade, if I were to do such a thing? Just the firmware update page in OpenWrt and upload the older version (21.02.5) of OpenWrt?

It affected VLAN in my case as well which is used by default*
Yes just upload the factory image of the older version and enable offloading in firewall after final configuration.

Okay, thanks, @anon82289434, I will give that a try, thanks again.

Just to confirm - I looked at a few links about downgrading in the meantime - should I use the sysupgrade.bin firmware? Or just the "factory" firmware.bin?

For the Wi-Fi, here is my config doing 420Mbit max on 5G, 140Mbit 2.4G:

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:00.0'
        option band '5g'
        option htmode 'VHT80'
        option channel '48'
        option country 'US'
        option cell_density '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/ahb/18100000.wmac'
        option channel '1'
        option band '2g'
        option disabled '0'
        option htmode 'HT40'
        option country 'US'
        option cell_density '0'
        option noscan '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option wds '1'
        option ssid 'replace'
        option encryption 'psk2+ccmp'
        option key 'replace'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option mode 'ap'
        option ssid 'replace'
        option encryption 'psk2+ccmp'
        option wds '1'
        option key 'replace'
        option network 'lan'

Ethernet to Ethernet routed is doing 650Mbit stock configuration with offloading.
Note that SQM in this router will decrease snappiness, increase buffer bloat, over 70Mbit with cake from my tests, close to 100Mbit with fq_codel.

Installing from OpenWrt should use sysupgrade, from stock factory.

Ok, thanks again @anon82289434 , I really appreciate your help with this.

I downgraded successfully and enabled offloading (software, not hardware, I'm assuming that's correct?). The speedtest.net results went up to around 200Mbps (up from 130), so that is already good news.

I will look at the wireless config file you posted and see if I can port some of that over to mine. What are the biggest changes in it from the default config, you think? I haven't customized mine hardly at all, so maybe it will be easy to add in some of what you did. Are there places in the router GUI that I can make those changes?

Note that SQM in this router will decrease snappiness, increase buffer bloat, over 70Mbit with cake from my tests, close to 100Mbit with fq_codel.

Sorry, I don't think I understood that last sentence. :laughing:

What is SQM?

1 Like

By the way, here's my /etc/config/wireless:

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'
	option country 'CA'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option cell_density '0'
	option country 'CA'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option key '---'
	option ssid '---'
	option encryption 'psk2+ccmp'
	
config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option key '---'
	option ssid '---'
	option encryption 'psk2+ccmp'
	

Looks good, change to 40mhz channel width for 2.4Ghz, and since every new AP around you forces 40Mhz without scanning these days, you may have to force 40Mhz too in the advanced tab section.
On this particular router, channels above 149 for the 5Ghz are superior from my tests. (mountain area no stations around, test with multiple clients including stock)

To explain the popular usage for SQM, read more about bufferbloat.
SQM (Smart Queue Management) is also a mix of handling congestion fairly by scheduling, usually on high latency networks so clients in a nutshell get equal bandwidth (common issue with conservative TCP congestion controller and window sizing) under full saturation, avoiding bandwidth monopoly. and to reduce latency on saturation caused by bufferbloat. You may have to use cake's host-isolation for the first part since realistically many things happen like out-of-order delivery on full saturation, other than queuing and bufferbloat etc...
I may be wrong on few details here and there, correct me if I'm wrong!

It's not installed by default, I'm not sure why this was mentioned here in the first place since it costs a lot of bandwidth and processing power, and it wouldn't have solved your problem, likely the opposite... Packet scheduling helps with responsiveness when other clients are saturating the connection, which I think what @mk24 means, since SQM is one of the most popular uses for installing OpenWrt on consumer hardware.

2 Likes

Ok, I changed to 40mhz on the 2.4Ghz network, and changed to the 153 channel for the 5Ghz network. I mostly use the 5Ghz one.

That bumped the speedtest up to around 210 from 200, so that's a bit better. Still a long ways from 270, though.

Thanks for the explanation about SQM, you sure seem to know your stuff. That's mostly Greek to me. :wink:

Can you recommend anything else that might tip the scales and increase speeds to at least 270Mbps? Because, I'm afraid, if I can't get it back up that high I'll probably just switch back to the TP-Link firmware, to be honest. The only real reason I wanted to try OpenWrt was because of the firewall capabilities and being able to block surreptitious outbound connections, including direct IP address connections. I'm trying to get a Raspberry Pi running Pi-hole set up, as well, which will be a DNS-level blocker, but I'd like a firewall with IP address blocking, as well. I just don't want to give up 25% of my bandwidth to get it. I can still set up the Pi-hole, I think, if I make the Pi be the DHCP server (but I'm still trying to figure that out, as well).

You've been a tremendous help, and I do appreciate it very much, so I don't want to take up too much more of your time, but I wonder if you might have any other recommendations that could improve the speed further?

2 Likes

Try a speed test service that does weighted average instead of median average. It could be the stock is spikey in bandwidth, or vice versa.
dslreports works well, you can also simply download a file and look at the speed for more accuracy when comparing.
You can also check if you're using IPv6 for the speed test compared to stock (disabled by default)

Offtopic alternative setup:

Run OpenWrt on the Pi 4 , plug it to the LAN port of the Archer running stock firmware, disable DHCP on the Archer, plug your internet connection to the LAN port on the Archer as well (not WAN), visit Pi4 web UI, go to Interfaces -> Devices -> Add device and choose MAC VLAN (this is the WAN), go back to Interfaces, Add Interface and choose the newly created MAC VLAN, select DHCP, set firewall to RED zone and now your Pi is doing the routing and LAN DHCP. You can easily install AdGuard Home instead of Pi-hole. There are other ad-block OpenWrt specific apps as well that are one-click install.

Your Archer is now a dumb AP, make sure to change it's LAN IP to avoid conflict with the Pi.

MAC VLAN will limit you to ~500/500 up/down since you're using one link, performance should be better too since the Pi is a bit overkill for non-VPN usage.

3 Likes

Thanks again for the replies, this all helps me enormously since I'm new to OpenWrt.

@mmstano I enabled packet steering, and I am now getting as high as 220Mbps, so thank you for that. How exactly would I overclock the CPU with the performance governor? Is that in the OS or in OpenWrt?

@anon82289434 I'm using speedtest.net only because that was the test I did when on the TP-Link firmware, so I just want to be consistent. I'd have to flash back to the TP-Link to get another set of readings from another website or test and I can't be bothered to do that right now. Maybe later. But I understand your point. And that is an interesting alternative setup you proposed with the Pi as the router, I will think more about it.

Also, I turned off the 'WAN6' interface in the hopes that would turn off IPv6 routing - is that the right way to stop IPv6 in OpenWrt?

Got it, thank you, @mmstano . I'll have a look around and see what I can find. I'll have to think about it some more, too.

I also just noticed that my Channel Analysis page of OpenWrt has issues.

I went to it trying to see the channels that the 5g networks around me are using, but it doesn't get past 'Starting Wireless Scan' - the spinner just keeps spinning.

If I click on the 2.4Ghz tab, that works and shows the networks in the graph.

Then, if I click the main router Status page I get an 'Unable to connect' error in my browser (Firefox). If I hit reload after a few seconds it then loads.

I have tried a number of times now but the Channel Analysis page just will not scan for 5g networks, and the Status page is always unresponsive afterward for a few seconds. It's as if it ties up some resources in OpenWrt pretty seriously. A bug, I'm guessing, or something I've done? I do remember it worked in v22.03.3 so maybe it got fixed since v21.02.5?

Depending on your regulatory domain (and driver, firmware), scanning (which is needed for the channel analysis) might not be possible while the interface is up and tuned into a (DFS-) channel, this is not a bug.

1 Like

Okay, thanks, @slh . Although, I didn't think channel 161 is a DFS channel (in Canada)?