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.
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.
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?
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.
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.
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.
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.
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?
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)
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.
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?
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.
