[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt 19.07.0 first release candidate

Hi,
The OpenWrt community is proud to announce the first release candidate of the upcoming OpenWrt 19.07 stable version series. It incorporates over 3700 commits since branching the previous OpenWrt 18.06 release and has been under development for about one a half years.
With this release the OpenWrt project brings all supported targets back to a single common kernel version and further refines and broadens existing device support. It also provides initial support for the new ath79 target, the future device tree based successor of the popular ar71xx target.
Some selected highlights of this release since the previous OpenWrt 18.06 version are:
Updated toolchain:
musl libc 1.1.24
uClibc-ng 1.0.31
glibc 2.27
gcc 7.4.0
binutils 2.31.1
Updated Linux kernel
4.14.151 for all targets
Flow offloading bugfixes
Network userland:
Fixes in network and wireless configuration handling
Bugfixes in DHCPv6 client and server
WPA3 configuration support
System userland:
Sysupgrade support for backup and upgrade capability checks
Bugfixes in the process manager, system message bus, embedded web server and the configuration management library
Platform and Driver Support
Dropped adm5120, adm8668, ar7, au1000, ixp4xx, mcs814x, omap24xx, ppc40x, ppc44x and xburst targets
Updates and new device support across all targets
Web interface:
Client side rendering of views for improved performance
Security fixes
For a detailed list of changes since branching of the 18.06 release series, see https://openwrt.org/releases/19.07/changelog-19.07.0
Known issues:
Sysupgrade from ar71xx to ath79 and vice versa is not officially supported, a full manual reinstall is recommended to switch targets for devices supported by both ar71xx and ath79
Images for some device became too big to support a persistent overlay, causing such models to lose configuration after a reboot. If you experience this problem, please report the affected device and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image
Some optional GUI packages crash with an error about missing "cbi.lua", install the "luci-compat" package to fix these
Any outstanding issues reported at https://bugs.openwrt.org/
For latest information about the 19.07 series, refer to the wiki at:
https://openwrt.org/releases/19.07/
To download the v19.07.0-rc1 images, navigate to:
https://downloads.openwrt.org/releases/19.07.0-rc1/
As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.
Have fun!
The OpenWrt Community

4 Replies
49

[Assistant]
jow:
Images for some device became too big to support a persistent overlay, causing such models to lose configuration after a reboot.
This problem I found in the router hg556a

1 Reply

Thanks again for all that you and the contributors have done to make this happen!!

1

cool! Something new to play with this weekend! Thanks


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [HOWTO] Resizing root partition on x86 (March 2023 edition)

This HOWTO is intended for users who have some experience in general computing and system administration but are relatively new to OpenWrt. It is loosely based on the relevant sections of the official OpenWrt on x86 Hardware page:
https://openwrt.org/docs/guide-user/installation/openwrt_x86
Changes from the previous edition
The Diagnostics section added (a big thank-you to
@efahl
for the suggestion!)
The Resize the Root File System section: command listings have been updated to match the current guidance on the wiki
The Root Cause
The origins of OpenWrt lie far outside of the x86 ecosystem. As a result, it is distributed in a way that is not common in the x86 ecosystem. There is no installation media and no installer; rather, one must copy the installation image to the target system's hard drive or SSD. Because of this, a new installation of OpenWrt 22.x.x. typically has a boot drive with approximately 120 MB of total space, regardless of the actual capacity of the drive. There are two ways to reclaim the remaining capacity. One is to resize the root partition of the OpenWrt installation, and this is what this HOWTO is about. The other is to create one or more additional partitions, but we will not cover it here (it's a general Linux topic for which multiple tutorials are available).
The Complication
There are four mainstream images one can use to implement an OpenWrt system on x86 hardware. They form a sort of 2x2 matrix:
generic-ext4-combined-efi.img.gz is an image that produces a UEFI system with an ext4 file system on the root partition
generic-ext4-combined.img.gz is an image that produces a BIOS system with an ext4 file system on the root partition
generic-squashfs-combined-efi.img.gz is an image that produces a UEFI system with a SquashFS file system on the root partition
generic-squashfs-combined.img.gz is an image that produces a BIOS system with a SquashFS file system on the root partition
Both the nature of the firmware (BIOS vs. UEFI) and the type of file system on the root partition (ext4 vs. SquashFS) have implications for partition resizing. So the first step in resizing your root partition is to know what kind of system you have or, said another way, which image was used to install the system.
Resizing the root partition on a BIOS system is simpler. Only two steps are required:
Resize the root partition (done the same way for ext4 and SquashFS), and
Resize the root file system (done differently depending on whether the file system is ext4 or SquashFS)
On a UEFI system, there is an additional step required. UEFI, unlike BIOS, keeps track of partition identifiers. At boot, UEFI will allow the system to load only from a partition it recognizes. When we resize the root partition, its ID will change, so we'll have to communicate those changes to the UEFI. This is done by editing the grub configuration file located at /boot/grub/grub.cfg. In order to know what changes to make to this file, it helps to see how partition configuration has changed. In other words, it is a good idea to have a record of both partition configurations, old and new. So in case of a UEFI system, we end up with a four-step process:
Capture the initial partition configuration (done the same way for ext4 and SquashFS),
Resize the root partition (done the same way for ext4 and SquashFS),
Update /boot/grub/grub.cfg (done the same way for ext4 and SquashFS), and
Resize the root file system (done differently depending on whether the file system is ext4 or SquashFS)
A note on safety
Technically, both resizing operations (resizing a partition and resizing a file system), if done on "live" drives, carry a risk of file system corruption. So in a perfect world, we should be doing this with the relevant drive unmounted (this can be achieved by booting the device from a USB stick). In practice, however, this works in an overwhelming majority of cases, especially when the device is essentially idle.
With this in mind, let's get some supplies.
Preparations
You will need a few utilities, which you probably don't have installed. So let's get them:
opkg update && opkg install lsblk fdisk losetup resize2fs
These should take us through the process.
Diagnostics
So far so good, but what if I don't know which image was used to install OpenWrt? Say, someone else did the installation or I simply forgot? Here are two simple tests.
First, let's figure out the ext4 vs. SquashFS question:
df -Th
This command will output a list of filesystems with types indicated. Look for a filesystem named /dev/root. Its type will be either ext4 or squashfs.
How about BIOS vs. UEFI, then? Also not very hard:
ls /sys/firmware/efi
On a UEFI system, a directory named /sys/firmware/efi must exist. So if the command above gives you a normal-looking directory listing, your system is UEFI; if you get an error message that says No such file or directory, your system is BIOS.
Capture the Current Partition Configuration
If you have a BIOS system, skip this section and go straight to Resize the Root Partition. On a UEFI system, run:
lsblk -o PATH,SIZE,PARTUUID
This will tell you the current partition layout, including each partition's unique identifier. Save this for future reference. If you're working over SSH, I would suggest saving it on the administrator's computer. Copy it from the terminal and save it as a text file. If you have a monitor and keyboard connected to your device, save it into a text file on the device. For example:
lsblk -o PATH,SIZE,PARTUUID > /root/lsblk_old.txt
Just in case, you may want to copy this file to a USB stick.
Next, you may want to take a look at the grub configuration file:
cat /boot/grub/grub.cfg
The goal is to see where partitions' unique identifiers are used and, therefore, where you will need to replace them when the time comes. Take a look at this example:
root@OpenWrt:~# lsblk -o PATH,SIZE,PARTUUID
PATH        SIZE PARTUUID
/dev/sda    120M
/dev/sda1    16M c959470f-01
/dev/sda2   104M c959470f-02

root@OpenWrt:~# cat /boot/grub/grub.cfg
serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1 --rtscts=off
terminal_input console serial; terminal_output console serial

set default="0"
set timeout="5"
set root='(hd0,msdos1)'

menuentry "OpenWrt" {
        linux /boot/vmlinuz root=PARTUUID=c959470f-02 rootwait console=tty0 console=ttyS0,38400n8 noinitrd
}
menuentry "OpenWrt (failsafe)" {
        linux /boot/vmlinuz failsafe=true root=PARTUUID=c959470f-02 rootwait console=tty0 console=ttyS0,38400n8 noinitrd
}
root@OpenWrt:~#
It's easy to see that partition /dev/sda2 has a unique identifier c959470f-02, and that identifier is used in grub configuration in two places to designate a root partition, first for the normal boot, then for the failsafe mode. So now you have a mind map of what you will be doing a little later.
Resize the Root Partition
This is done nearly identically in all cases by running an interactive fdisk session. The listing below shows a mix of fdisk output and manual inputs. To distinguish the manual inputs, I have enclosed them [[in double square brackets]]; the [[]] sequence indicates pressing Enter with no visible input. Obviously, when you enter commands or data, you won't need any square brackets; I'm just using them as markers. It's a bit confusing, but I can't come up with a better formatting scheme right now. So here goes:
root@OpenWrt:~# [[fdisk /dev/sda]]

Welcome to fdisk (util-linux 2.37.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

Command (m for help): [[p]]

Disk /dev/sda: 59.63 GiB, 64023257088 bytes, 125045424 sectors
Disk model: ADATA_IM2S3134N-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc120d9f5

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *      512     33279     32768   16M 83 Linux
/dev/sda2       33792    246783    212992  104M 83 Linux

Command (m for help): [[d]]
Partition number (1,2, default 2): [[2]]

Partition 2 has been deleted.

Command (m for help): [[n]]
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): [[p]]
Partition number (2-4, default 2): [[2]]
First sector (33280-31277231, default 34816): [[33792]]
Last sector, +/-sectors or +/-size{K,M,G,T,P}
    (33792-125045423, default 125045423): [[]]

Created a new partition 2 of type 'Linux' and of size 59.6 GiB.
Partition #2 contains a squashfs signature.

Do you want to remove the signature? [Y]es/[N]o: [[n]]

Command (m for help): [[w]]

The partition table has been altered.
Syncing disks.

root@OpenWrt:~#
A few important notes:
This has worked despite the "bad idea" warning.
Technically, we didn't "extend" the partition; rather, we deleted one, then created a new one starting at the same location and gobbling up all available disk space. However, since there was no write command in-between, the net result was a new, larger partition that "inherited" all data located on the old small partition.
The number 33792 specified in response to the First sector prompt came from the disk information table produced in response to the p command.
Depending on what kind of system you have, you may or may not be asked whether you want a primary or extended partition. Otherwise, the process should be identical.
To verify that the partition has been resized, you can run fdisk -l or start another interactive session (fdisk /dev/sda) and issue a p command to show the partition layout followed by a q command to quit.
Update grub Configuration
If you have a BIOS system, skip this section and go straight to Resize the Root File System. On a UEFI system, run:
lsblk -o PATH,SIZE,PARTUUID
Compare the output to its earlier version that you saved. You will see that the unique identifier for the /dev/sda2 partition has changed. Use your new identifier to replace the old one in grub configuration. For example, if you use vi, you can do:
vi /boot/grub/grub.cfg
From your earlier review of grub configuration, you would know how many instances of partition ID require replacement. Make the changes, save the file, and exit the text editor.
Resize the Root File System
This is the final step, and it is done differently depending on whether you have an ext4 file system or a SquashFS file system. You should take care to execute the commands given below one by one (meaning, don't paste all of them into the command line at once; allow one command to finish before entering the next one).
Watch the output of the resize2fs command. Normally, you would see some indication of file system size change. If, on the other hand, resize2fs indicated it has nothing to do, reboot your device and repeat this step in its entirety. Rebooting will ensure that the changes made during the previous steps are applied to the system.
On an ext4 System
BOOT="$(sed -n -e "\|\s/boot\s.*$|{s///p;q}" /etc/mtab)"
PART="${BOOT##*[^0-9]}"
DISK="${BOOT%${PART}}"
ROOT="${DISK}$((PART+1))"
LOOP="$(losetup -f)"
losetup ${LOOP} ${ROOT}
resize2fs -f ${LOOP}
reboot
On a SquashFS System
BOOT="$(sed -n -e "\|\s/boot\s.*$|{s///p;q}" /etc/mtab)"
PART="${BOOT##*[^0-9]}"
DISK="${BOOT%${PART}}"
ROOT="${DISK}$((PART+1))"
LOOP="$(losetup -n -l | sed -n -e "\|\s.*\s${ROOT#/dev}\s.*$|{s///p;q}")"
resize2fs -f ${LOOP}
reboot
Concluding Notes
If all of the above worked, congratulations! You have successfully resized the root partition on your OpenWrt device. You may want to reboot your device to ensure that everything starts up correctly.
Early in this guide, we discussed the two options for reclaiming disk space, extending the root partition and creating additional partitions. Those are not mutually exclusive; it is entirely possible to use them together (extending the root partition part-way and setting up new partition or partitions in the still-free disk space). Read up on fdisk and its use in partition setup; this will allow you to create all kinds of configurations.

2 Replies
27

[Assistant]
Very well written. This howto shouldn't be necessary, but that's another discussion.
You should consider maintaining it on the OpenWrt Wiki site.

2 Replies
4

VA1DER:
You should consider maintaining it on the OpenWrt Wiki site.
Usually when I mentioned it in other threads to the OP, responses are in the categories of:
the Wiki doesn't suit OP's writing style
people can just find it here

2 Replies

lleachii:
the Wiki doesn't suit OP's writing style
I tend to think the other way around: my writing style doesn't suit the wiki. The wiki is a great source for users with some experience; it's occasionally terse, but that's not a problem given the audience. I, on the other hand, tend to write for someone new. Also, I tend to disagree with some of the wiki's mantras, specifically 2 (Avoid duplicating information within this wiki) and 3 (Avoid duplicating upstream documentation). In my opinion (and it's only an opinion), they sometimes clash with mantra 1 (Articles must be easy to read), which (again, in my opinion) is the most important mantra.
Perhaps more importantly, since you and I last had this conversation, I actually applied for a wiki account, tried to contribute to the wiki, and quickly found the wiki authoring process to be somewhat on the clunky side. Here on the forum, the author's workflow is such that I actually enjoy writing. On the wiki, it's just not. I guess it's the author's UI showing its age...

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [Solved] 802.11ax worse than 802.11ac with mt76 driver?

I just upgraded one of my access points from an Archer C6 v3.2 to a Redmi AX6S.
Since the new device has support to 802.11ax on the 5Ghz band, I`ve decided to do some tests.
While in the same room 802.11ax has a higher throughput than 802.11ac (tested with iPerf3 on a wired Linux machine and and iPhone 13Pro), the performance of 802.11ax in another room across one brick wall is much worse than 802.11ac (see results below).
I had the assumption that 802.11ax would always have a superior performance than 802.11ac in any situation. Is my understanding wrong or may this be an issue of the m76 driver support to 802.11ax?
Unfortunately I did not test with the stock firmware to be able to compare results.
I repeated the test multiple times, and the results were consistent.
Test Environment: iperf3 server running on a wired Linux machine (1Gbps), iperf3 client running on an iPhone 13 Pro at a distance of about 5 meters from the access point with a brick wall in the way. Test performed with 5Ghz radio @80MHz, channel 149.
Wireless AP: Redmi AX6S running OpenWrt 22.03.0-rc1.
Wireless Config (802.11ac):
Results:

Solved by dsouza in post #533
Update: see comments in section "EDIT 6 (2024-01-10)" at the end of this message. This issue is likely fixed now for all mt76 devices. I did a 23.05 build and included
@Anteus
patch in the build, and I can confirm that this patch (which disables VHT160/AC 160Mhz) solved the 802.11ax issue with iPh…
1 Reply
6

[Assistant]
I just tested with a master snapshot build, and the performance in this situation was even worse.
So I believe it might be an issue with the m76 driver and 802.11ax support, but I cannot be certain of that.
Since 802.11x performance on the same room is excellent, and the issue only appears in an adjacent
room with a brick wall in the middle, my hypothesis is that is may have something related to beamforming that might be kicking in in this situation but for some reason is not working well with the m76 driver.
I will wait for another AX6S I've purchased to be delivered (possibly in the upcoming weeks0, and before flashing OpenWrt on it I will do the same test with the stock firmware in order to make sure it is indeed a firmware/driver issue. I will post here again when I have this data.

1 Reply

Hi !
can you post the output of iw list please ?

1 Reply
1

2x AX3200 providing a Mesh network on 5 GHz at channel 100 through steel slab.
iw dev mesh0 station dump:
name value
signal: -72 [-79, -73, -79, -79] dBm
signal avg: -73 [-80, -74, -80, -81] dBm
Toffset: 18446744073072000958 us
tx bitrate: 408.3 MBit/s 80MHz HE-MCS 3 HE-NSS 3 HE-GI 1 HE-DCM 0
tx duration: 621189412 us
rx bitrate: 432.3 MBit/s 80MHz HE-MCS 2 HE-NSS 4 HE-GI 0 HE-DCM 0
rx duration: 53020275 us
client -> server:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  1.97 GBytes   282 Mbits/sec   26             sender
[  5]   0.00-60.01  sec  1.96 GBytes   281 Mbits/sec                  receiver
client <- server (-R):
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  1.55 GBytes   222 Mbits/sec    7             sender
[  5]   0.00-60.00  sec  1.55 GBytes   222 Mbits/sec                  receiver
The difference is not as bad as yours.
The devices are on: 22.03-SNAPSHOT r19290-ad5a507df3 and SNAPSHOT r19511-c59704334c

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Announcing the OpenWrt/LEDE merge

Both the OpenWrt and LEDE projects are happy to announce their unification under the OpenWrt name.
After long and sometimes slowly moving discussions about the specifics of the re-merge, with multiple similar proposals but little subsequent action, we're happy to announce that both projects are about to execute the final steps of the merger.
The new, unified OpenWrt project will be governed under the rules established by the LEDE project. Active members of both the former LEDE and OpenWrt projects will continue working on the unified OpenWrt.
LEDE's fork and subsequent re-merge into OpenWrt will not alter the overall technical direction taken by the unified project. We will continue to work on improving stability and release maintenance while aiming for frequent minor releases to address critical bugs and security issues like we did with LEDE 17.01 and its four point releases until now.
Old pre-15.05 OpenWrt CC releases will not be supported by the merged project anymore, leaving these releases without any future security or bug fixes. The OpenWrt CC 15.05 release series will receive a limited amount of security and bug fixes, but is not yet fully integrated in our release automation, so binary releases are lacking behind for now.
The LEDE 17.01 release will continue to get full security and bug fix support for both source code and binary releases.
We are planning a new major release under the new name in the next few months.
The merged project will use the code base of the former LEDE project. OpenWrt specific patches not present in the LEDE repository but meeting LEDEs code quality requirements got integrated into the new tree. The source code will be hosted at git.openwrt.org with a continuously synchronized mirror hosted at Github. The original OpenWrt codebase has been archived on Github for future reference.
Yet open pull requests to both the old OpenWrt and LEDE repositories will be closed after a 30 day grace period. We encourage people to open new pull requests at the new repository or re-send still unmerged patches.
The remerged OpenWrt project is legally represented by the Software in the Public Interest (SPI) - an US 501(c)(3) non-profit organization which is managing our OpenWrt trademark, handling our donations and helping us with legal problems.
Infrastructure currently available under the lede-project.org domain will be moved to corresponding openwrt.org subdomains and redirects will be put in place where appropriate.
The merger of the OpenWrt and LEDE forums and wikis is not yet fully decided, so all portals will continue to be available under their respective domains until a definite consensus is reached.

36

[Assistant]
Please use lede's forum software. Openwrt's sucks.

15

I second that.
Also put a date on all Announcements including year, month, and day.
A very often overlooked detail on the internet these days. In the timeless and eternal
internet it's hard to know what is fresh information or exactly how old information is.
Lot of news sites recycle old stories this way- no dates included with the story. Bad practice.

6

Similar comments already made in this thread...
OpenWRT/LEDE Merger - WHEN?
Site Feedback and Other Questions
I do not know about you but i do not care how wiki looks as long as it contains information that i am searching for. I frequently find myself searching through old openwrt wiki and i always find what i want. It has a LOT of information in it.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt 19.07.3 service release

Hi,
The OpenWrt community is proud to announce the third service release of OpenWrt 19.07. OpenWrt 19.07.3 focuses on security, stability and device support.
Selected highlights of this service release are:
reduce opkg memory usage
allow to configure WPA3 modes in the LuCI web interface
greatly improve loading performance when using LuCI with HTTPS
update core components (linux kernel, mac80211, etc)
many fixes and improvements for device support
fix security issues in umdns (CVE-2020-11750), relayd (CVE-2020-11752), and other external packages
Security fixes for packages can also be applied by upgrading only the affected packages on running devices, without the need for a full firmware upgrade to OpenWrt 19.07.3.
Nevertheless, we encourage all users to upgrade their devices to OpenWrt 19.07.3 whenever possible.
Full release notes and upgrade instructions are available, as well as a detailed list of all changes since 19.07.2. Make sure to read the known issues before upgrading.
For latest information about the 19.07 series, refer to the wiki page.
To download a OpenWrt 19.07.3 firmware image for your device, head to the
Table of Hardware or navigate directly in the list of firmware images.
As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.
Have fun!
The OpenWrt Community

31

[Assistant]
Great work guys, keep up the good work.
Maybe a glitch.
In a dumbap i want to assign no firewall zone (unspecified) to the lan interface. This worked on my R7800 under 19.07.2 and on my Archer C7 v5 under 19.07.3 but not on my R7800 under 19.07.3.
The option is there but after choosing unspecified and saving the lan interface icon stays green and the zone is still on lan.

1 Reply

Excellent work guys.
I have a problem with the hg556a router the following fix was not added
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=af667c73c5d

Indeed, the fix came too late for 19.07.3, see https://openwrt.org/toh/huawei/hg556a#installation

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: State of TP-Link Archer C7v2|v5 in 2023

Do-It-Yourself build recipe:
Go to https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=ath79%2Fgeneric&id=tplink_archer-c7-v5
Select custom build
Copy & paste the package list
ath10k-firmware-qca988x base-files busybox ca-bundle dnsmasq dropbear firewall4 fstools kmod-ath10k kmod-ath9k kmod-gpio-button-hotplug kmod-nft-offload kmod-usb-ledtrig-usbport kmod-usb2 libc libgcc libustream-wolfssl logd mtd netifd nftables odhcp6c odhcpd-ipv6only opkg ppp ppp-mod-pppoe procd procd-seccomp procd-ujail swconfig uboot-envtools uci uclient-fetch urandom-seed urngd wpad-mesh-wolfssl

luci
bash ca-certificates curl htop iperf3 logrotate lua luafilesystem mailsend terminfo tcpdump snmpd
batctl-full kmod-batman-adv luci-proto-batman-adv
luci-app-attendedsysupgrade
luci-proto-relay relayd
vsftpd
watchcat luci-app-watchcat
and the script to run on first boot (source: https://github.com/Catfriend1/openwrt-presence/blob/master/scripts/imagebuilder/imagebuilder-files/etc/uci-defaults/99-ath9k-set-txq-memory-limit) :
INIT_D_ATH9K_SET_TXQ_FULLFN="/etc/init.d/ath9k-set-txq-memory-limit"
cat << EOF > "${INIT_D_ATH9K_SET_TXQ_FULLFN}"
#!/bin/sh /etc/rc.common

START=99

start() {
 iw phy phy1 set txq memory_limit 8388608
}
EOF
chmod +x "${INIT_D_ATH9K_SET_TXQ_FULLFN}"
${INIT_D_ATH9K_SET_TXQ_FULLFN} enable
${INIT_D_ATH9K_SET_TXQ_FULLFN} start
Click the "build" button and wait for the build to finish.
Scroll down - there, you can download factory and sysupgrade images.
Hi,
this is a follow up to: https://forum.openwrt.org/t/state-of-archer-c7-v2-in-mid-2020
I'll happily provide my build of the official OpenWrt 21.02.0-rc1 release - created by using ImageBuilder. Unfortunately, I've still had to switch from ath10k ct-drivers to non-ct-drivers as the non-ct drivers offer more mesh features (used by batman-adv, for example) and provide more stability over ct drivers.
Because of being requested, I'll share the work and cook book. I've also included batman-adv for encrypted 802.11s mesh support.
Please remember: Use vim or WinSCP to edit /etc/config/wireless in the "radio1" (2.4 GHz) WiFi section and turn LDPC off when using the hardware model TP-Link Archer C7v2. This will improve stability and latency a lot. Here's a sample of the config section: https://github.com/Catfriend1/openwrt-presence/blob/master/scripts/wifimgr/radio-iface/20-tplink-archer-c7v5-radio1
(Links removed)
This also contains
@sammo
's "iw phy phy1 set txq memory_limit 8388608" as a startup script (see /etc/uci-defaults/99-ath9k-set-txq-memory-limit which creates /etc/init.d/ath9k-set-txq-memory-limit to run every startup to adjust the memory limit and avoid the "slowly dying 2.4 GHz WiFi").
This build works very well on my v2 and v5 units. WiFi got blazing fast and bufferbloat defeated a lot.

(measured as a dump-ap with bridged LAN-to-WiFi network interfaces, no NAT, no routing)
Kind regards,
Catfriend1

2 Replies
19

[Assistant]
@Router
What packages , use case did you have when testing the rc? It works pretty well for me, e.g. I had dns server listening and ipv6 disabled.

That's awesome! tnx for maintaining it
I just built a 19.07.7 image yesterday and installed it today on my v5, also using it on bridge.
What's batman-adv used for? How much storage is ur image consuming from /dev/root?
Would u mind sharing ur network config for bridged usage?

To be clear, I do NOT maintain the OpenWrt code/images. I've just used ImageBuilder to "bundle" it from the official image and opkg sources.
df -h shows
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.3M      8.3M         0 100% /rom
tmpfs                    60.3M    108.0K     60.2M   0% /tmp
/dev/mtdblock9            4.8M    340.0K      4.4M   7% /overlay
overlayfs:/overlay        4.8M    340.0K      4.4M   7% /
tmpfs                   512.0K         0    512.0K   0% /dev
I use batman-adv to have on mesh SSID (802.11s) running that carries the traffic of multiple VLAN networks through the batman interface. For example, you can build a mesh network with "only driven by wireless uplink" access points. One VLAN is the management VLAN where I can access the AP's web UI LUCI, one VLAN is a corporate network and one VLAN is a guest network. Without batman-adv, you would have needed to configure multiple WDS SSID for every single VLAN to provide it to a non-wired access point "on the outside".
My configs are:
/etc/rc.local - Avoids uncaught crashing of the ath10k wifi driver.
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

/bin/bash /root/wrtwatchdog start

exit 0
/etc/sysctl.conf - Turns off IPv6 (better network performance, proof still under investigation why that is better)
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
/etc/sysupgrade.conf - Preserve /root on upgrade
## This file contains files and directories that should
## be preserved during an upgrade.

# /etc/example.conf
# /etc/openvpn/

/root
/etc/config/dhcp - turn off DNS server on external interfaces, preserve on lo (for the opkg update) - Note the "list interface 'lo'"
config dnsmasq
 option domainneeded '1'
 option localise_queries '1'
 option rebind_protection '1'
 option rebind_localhost '1'
 option local '/lan/'
 option expandhosts '1'
 option authoritative '1'
 option readethers '1'
 option leasefile '/tmp/dhcp.leases'
 option localservice '1'
 option domain 'mycorp.local'
 option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
 list interface 'lo'

config dhcp 'lan'
 option interface 'lan'
 option ignore '1'

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

config odhcpd 'odhcpd'
 option maindhcp '0'
 option leasefile '/tmp/hosts/odhcpd'
 option leasetrigger '/usr/sbin/odhcpd-update'
 option loglevel '4'
/etc/config/network - Provide the BATMAN hardIF - VL10 (management VLAN) - VL50 (client VLAN)
config interface 'loopback'
 option ifname 'lo'
 option proto 'static'
 option ipaddr '127.0.0.1'
 option netmask '255.0.0.0'

config globals 'globals'
 option ula_prefix 'TO_FILL'

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

config switch_vlan
 option device 'switch0'
 option vlan '1'
 option vid '1'

config switch_vlan
 option device 'switch0'
 option vlan '2'
 option vid '10'
 option ports '0t 1t'

config switch_vlan
 option device 'switch0'
 option vlan '5'
 option vid '50'
 option ports '0t 1t'

config interface 'VL10'
 option proto 'static'
 option delegate '0'
 option ipaddr 'TO_FILL'
 option netmask 'TO_FILL'
 option gateway 'TO_FILL'
 option broadcast 'TO_FILL'
 option igmp_snooping '1'
 option igmp_v3 '1'
 option multicast_querier '0'
 option ifname 'bat0.10 eth0.10'
 list dns 'TO_FILL'
 list dns 'TO_FILL'
 option type 'bridge'

config interface 'VL50'
 option type 'bridge'
 option proto 'static'
 option delegate '0'
 option igmp_snooping '1'
 option igmp_v3 '1'
 option multicast_querier '0'
 option ifname 'bat0.50 eth0.50'

config interface 'bat0'
 option proto 'batadv'
 option routing_algo 'BATMAN_IV'
 option aggregation '1'
 option ap_isolation '0'
 option bonding '0'
 option fragmentation '1'
 option gw_mode 'off'
 option log_level '0'
 option orig_interval '10000'
 option bridge_loop_avoidance '1'
 option distributed_arp_table '1'
 option multicast_mode '1'
 option network_coding '0'
 option hop_penalty '30'
 option isolation_mark '0x00000000/0x00000000'

config interface 'nwi_mesh0'
 option mtu '1532'
 option proto 'batadv_hardif'
 option master 'bat0'
/etc/config/wireless - Provide the 802.11s mesh interface and attach it to "nwi_mesh0" (batman hardIF) - Provide SSID (VLAN 50) where your client machines connect to. The VLAN 50 is driven through the batman-adv wireless mesh tunnel.
config wifi-device 'radio0'
 option type 'mac80211'
 option beacon_int '100'
 option channel '36'
 option hwmode '11a'
 option path 'pci0000:00/0000:00:00.0'
 option htmode 'VHT80'
 option txpower '23'
 option country 'DE'
 option legacy_rates '0'
 option noscan '0'
 option disabled '0'

config wifi-device 'radio1'
 option type 'mac80211'
 option channel '1'
 option hwmode '11g'
 option path 'platform/ahb/18100000.wmac'
 option htmode 'HT40'
 option txpower '20'
 option country 'DE'
 option legacy_rates '0'
 option noscan '0'
 option disabled '0'

config wifi-iface 'wifinet0'
 option device 'radio0'
 option disabled '0'
 option mode 'mesh'
 option mesh_id 'CORPMESH'
 option encryption 'sae'
 option dtim_period '1'
 option disassoc_low_ack '0'
 option key 'TO_FILL'
 option network 'nwi_mesh0'
 option mesh_fwding '0'
 option mesh_rssi_threshold '0'

config wifi-iface 'wifinet1'
 option device 'radio0'
 option disabled '0'
 option mode 'ap'
 option ssid 'CLIENT_WIFI_TO_FILL'
 option network 'VL50'
 option dtim_period '1'
 option disassoc_low_ack '0'
 option encryption 'wpa2+ccmp'
 option auth_server 'TO_FILL_FOR_EAP'
 option auth_port '1812'
 option acct_server '1TO_FILL_FOR_EAP'
 option acct_port '1813'
 option nasid 'TO_FILL_FOR_EAP'
 option ieee80211w '1'
 option wpa_disable_eapol_key_retries '1'
 option auth_secret 'TO_FILL_FOR_EAP'
 option acct_secret 'TO_FILL_FOR_EAP'
/etc/config/firewall
config defaults
 option syn_flood '1'
 option output 'ACCEPT'
 option forward 'REJECT'
 option input 'REJECT'

config include
 option path '/etc/firewall.user'

config zone
 option forward 'REJECT'
 option output 'ACCEPT'
 option network 'VL10'
 option input 'ACCEPT'
 option name 'VL10'

config zone
 option name 'VL50'
 option input 'REJECT'
 option forward 'REJECT'
 option output 'ACCEPT'
 option network 'VL50'

2 Replies
3


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: QoS and nftables … some findings to share

Hi all, every so often there's discussions on the forum about how to do QoS at a level a little higher than just set-it-and-forget-it that SQM offers (which is a great service thanks
@moeller0
and others involved in SQM!). I've been doing custom QoS for several years now and have figured out some stuff I thought I'd share, and we can discuss here.
Warning 1
I don't actually use OpenWrt for my router, only for my access points. So some of this will require some help from you to debug how it works on OpenWrt.
Warning 2
This is for advanced users only, and requires REPLACING YOUR FIREWALL ENTIRELY make sure you UNDERSTAND and take responsibility for your own security and operations. Test this on a spare router or something. I offer this with NO WARRANTY OF ANY KIND as educational material only.
First off...
QoS is hard to do right... so we want to take advantage of the best available tools. And the best available tools for managing packets is nftables. nftables does work on OpenWrt but it completely replaces the firewall and you can't manipulate the firewall through LuCI anymore. So, first thing's first, you need to get nftables working and forget about having iptables anymore. Also you need to get a basic nftables firewall set up that you can customize.
To get started putting nftables on your OpenWrt router, I suggest this:
https://openwrt.org/docs/guide-user/firewall/misc/nftables
But remember, I am actually routing on Debian, so it comes with nftables installed, so hopefully someone who is interested in this topic can post some info on their experiences with setting that up.
Second
You will need an nftables firewall.... here's the bare bones, which assumes your WAN is on eth1 and LAN is on eth0. This firewall lets anything out but only allows things in if they are related to outgoing packets. It masquerades ipv4 on the WAN, and it has some limitations on what can be accepted by the router. If you have a br-lan bridge you will need to alter the use of eth0 here to probably be br-lan, but I'm not sure what nftables thinks is the "in interface" when it's a bridge... so you'll have to test.
I believe this is a safe base for a firewall, but you should check it and test it yourself. This is based on editing down a much more complicated firewall that I use, so it might have bugs or typos.
# A simple stateful firewall with some packet tagging,
# based originally on nftables archlinux wiki
# https://wiki.archlinux.org/index.php/nftables

## this assumes eth0 is LAN and eth1 is WAN, modify as needed

flush ruleset

## change these

define wan = eth1
define lan = eth0

table inet filter {
 chain input {
  type filter hook input priority 0; policy drop;

  # established/related connections
  ct state established,related accept

  # loopback interface
  iifname lo accept

  ## icmpv6 is a critical part of the protocol, we just
  ## accept everything, you can lookin to making this
  ## more restrictive but be careful
  ip6 nexthdr icmpv6 accept

  # we are more restrictive for ipv4 icmp
  ip protocol icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept

  ip protocol igmp accept

  ip protocol icmp meta iifname $lan accept

  ## ntp protocol accept from LAN
  udp dport ntp iifname $lan accept

  ## DHCP accept
  iifname $lan ip protocol udp udp sport bootpc udp dport bootps log prefix "FIREWALL ACCEPT DHCP: " accept

  ## DHCPv6 accept from LAN
  iifname $lan udp sport dhcpv6-client udp dport dhcpv6-server accept

  ## allow dhcpv6 from router to ISP
  iifname $wan udp sport dhcpv6-server udp dport dhcpv6-client accept

  # SSH (port 22), limited to 10 connections per minute,
  # you might prefer to not allow this from WAN for
  # OpenWrt, in which case you should also add an
  # iifname eth0 filter in the front so we're only
  # allowing from LAN

  ct state new tcp dport ssh meter ssh-meter4 {ip saddr limit rate 10/minute burst 15 packets} accept
  ct state new ip6 nexthdr tcp tcp dport ssh meter ssh-meter6 {ip6 saddr limit rate 10/minute burst 15 packets} accept

  ## allow access to LUCI from LAN
  iifname $lan tcp dport {http,https} accept

  ## DNS for main LAN, we limit the rates allowed from each LAN host to reduce chance of denial of service
  iifname $lan udp dport domain meter dommeter4 { ip saddr limit rate 240/minute burst 240 packets} accept
  iifname $lan udp dport domain meter dommeter6 { ip6 saddr limit rate 240/minute burst 240 packets} accept

  iifname $lan tcp dport domain meter dommeter4tcp { ip saddr limit rate 240/minute burst 240 packets} accept
  iifname $lan tcp dport domain meter dommeter6tcp { ip6 saddr limit rate 240/minute burst 240 packets} accept

  ## allow remote syslog input? you might want this, or remove this

  # iifname $lan udp dport 514 accept

  counter log prefix "FIREWALL INPUT DROP: " drop
 }

 chain forward {
     type filter hook forward priority 0; policy drop;

     ct state established,related accept

     iifname lo accept
     iifname $lan oifname $wan accept ## allow LAN to forward to WAN

     counter log prefix "FIREWALL FAIL FORWARDING: " drop
 }
}

## masquerading for ipv4 output on WAN
table ip masq {
 chain masqout {
     type nat hook postrouting priority 0; policy accept;
     oifname $wan masquerade

 }

 ## this empty table is required to make the kernel do the unmasquerading
 chain masqin {
     type nat hook prerouting priority 0; policy accept;

 }

}
Once you have got this working and debugged... you can also add special tables for traffic control, including DSCP tagging and policing... For example I add a table a lot like this to my firewall. You can simply plop in additional tables, there is no limit like in iptables where you have to hook the FORWARD table or whatever.
table netdev retag {
    chain tagin {
       ## mangle priority, retag anything coming from LAN, you
       ## might want to do the same for anything coming from WAN
       ## (assumed to be eth1)

       type filter hook ingress device eth0 priority -149; policy accept;

   ip dscp set cs3 ## convert all to cs3 first, this is my base DSCP tag rather than cs0
   ip6 dscp set cs3

   # tag ntp packets very high priority
   ip protocol udp udp sport ntp ip dscp set cs6
   ip6 nexthdr udp udp sport ntp ip6 dscp set cs6

   ## icmp/icmpv6 gets high priority but you might not want
   ## this!  it does let you find out what the round trip time
   ## for high priority packets is by just using ping though
   ip protocol icmp ip dscp set cs5
   ip6 nexthdr icmpv6 ip6 dscp set cs5

   ## game traffic on ip and ipv6
   udp dport {7000-9000, 27000-27200} ip dscp set cs5
   udp sport {7000-9000, 27000-27200} ip dscp set cs5

   ip6 nexthdr udp udp dport {7000-9000, 27000-27200} ip6 dscp set cs5
   ip6 nexthdr udp udp sport {7000-9000, 27000-27200} ip6 dscp set cs5

   # I have a custom shaper with different classes 1:10, 1:20
   # are realtime, 1:30 is high priority nonrealtime, 1:40 is
   # normal, 1:50 is nfs fileserver bulk, 1:60 is very low
   # priority, if you use cake, you can remove this whole thing
   # and just use layer cake, it will use the DSCP on its own

   meta priority set 1:40 ## default

   ip dscp {ef,cs6} meta priority set 1:10
   ip dscp {cs5} meta priority set 1:20
   ip dscp {af41, af42, af43} meta priority set 1:30
   ip dscp {cs2} meta priority set 1:50
   ip dscp {cs1} meta priority set 1:60

   ip6 dscp {ef,cs6} meta priority set 1:10
   ip6 dscp {cs5} meta priority set 1:20
   ip6 dscp {af41, af42, af43} meta priority set 1:30
   ip6 dscp {cs2} meta priority set 1:50
   ip6 dscp {cs1} meta priority set 1:60

    }
}
This is to get you started, you could add your own tagging here, like you could use rules that detect bulk traffic and tag it cs1, and/or might not want to use my classification scheme, like CS3 as base priority level might not be a good idea on your network. But the point here is that this is custom so YOU make the decisions.
Because this tag table is hooked to "ingress" at extremely high priority, it gets run before queueing in the IFB, which means that you could have one table to tag inbound packets from eth1 and one to tag packets from eth0 and then use SQM on the WAN and the IFB packets will be queued according to the DSCP tags (I believe... please test!)
HOPE THIS GETS YOU STARTED... and would be happy to discuss here for other QoS nerds.

Solved by amteza in post #133
Sure, let's see, slice by slice as Jack "The Ripper" might say. List of "firewall" modules initially installed, only: kmod-nf-conntrack kmod-nf-conntrack6 kmod-nf-nat kmod-nf-reject kmod-nf-reject6 kmod-nfnetlink kmod-nft-core kmod-nft-nat Additional modules that can be installed without problems…
14

[Assistant]
If anyone tries this out and reports bugs in getting stuff going, I will update those scripts in the first post so we can be sure to have a working base config.
Once you've got this going, I can offer some more sophisticated rules for DSCP tagging, particularly for automatically tagging sparse UDP streams like game traffic based on the traffic characteristics itself (packet size and rate etc) as well as down-prioritizing bulk traffic...
But I figure I'll leave that until someone shows some interest and has confirmed they have got this working on some actual OpenWrt device! so have at it!

Ok, so I had one taker
@LeTran
seemed interested in getting this going. To start with we need to get nftables installed. The device is acting as a pure bufferbloat appliance with a bridge between eth0.2 and eth1.3 so there is no firewalling going on anyway.
This is similar to
@mindwolf
with his bump in the wire application, though there I think he's doing routing not bridging.

my Wrt-ac3200 is a pure bridge so update lists is not working. I can't install nftables without internet. What is your suggestion?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Hardware mod tutorial: Replace wifi cards on Linksys WRT-1900AC v1

This is a hardware mod for Linksys WRT-1900AC v1. Follow this guide at your own risk.
The Linksys WRT-1900AC v1 uses the mwlwifi driver for it's wireless adapters. This driver is not maintained and has become unusable recently.
Fortunately, on this router, the adapters are removable. The two wifi chips sit on a common expansion card that is inserted into two standard mini-PCIe slots.
You need:
Hardware knowledge. You must at least be able to replace a computer card.
Philips and slot screwdriver.
Drill, M2 - M2.5 taps and short screws. It may work without taps, but in this case be prepared with extra screws.
At least one replacement wifi card, well supported by OpenWrt and/or Linux kernel, possibly firmware too. Both full-size and half-size mini-PCIe will work. It is preferable to have cards that are single-sided (no components or shield on the back side).
If you plan to use double-sided cards, you need to have (or borrow) a single-sided card (any card) of the same lenght to use as a positioning guide.
If you plan to use double-sided cards, you also need a Fretsaw and knowledge to use it.
OpenWrt knowledge, to install new wifi drivers, possibly by building your own firmware image from source or using the image builder.
Step 1: Open the case.
There are screws inside the feet of the router. (Front and back screws are not the same!) The front part of the case (blue) opens by pulling toward the front of the router, away from the black part of the case.
The black part of the case can be separated into top and bottom part. There are plastic clamps keeping the two parts together. Pull carefully, because they may break.
Step 2: Remove heatsink from the wifi board
Disconnect the antenna cables first.
The part where the antenna cables were connected is the wifi board. It has a separate heatsink with a few tiny screws. Remove it.
After this, it will look like this:
Step 3: Remove the wifi board
There are two screws at the corners of the wifi board, near the antenna connectors. Remove these and pull the wifi card up and toward the front of the router.
After this, the router will look like this:

You can see the mini-PCIe connectors.
Step 4: Mark positions for the mPCIe screw holes
Don't remove the heatsink screws!
Insert your cards into the mPCIe connectors and use a pencil to mark the position of the screw holes on the heatsink. I recommend to mark holes for both half-size and full-size cards, in case you need to change them later.
Make sure there are no mistakes here. Be very accurate! Don't do it if you don't have a precise guide for the screw holes! If the holes are miss-aligned even by a fraction of a mm, the card won't sit properly in the connector and intermittent connections will cause kernel panics.
If your cards are double-sided (have components or a shield on the back side), you won't be able to position them properly because the back side components won't have enough space above the heatsink. The heatsink will need to be cut to make room for back-side components on double-sided cards. You must use a single-sided card to mark the holes for the screws.
Also mark the size of the card's components from the back side.
As an alternative, you may try to cut the heatsink first and mark the screw holes after that. Make sure the heatsink is properly installed and all heatsink screws are tight before marking the holes. Mistakes can't be fixed!
Step 5: Separate the main board from the case and remove the main heatsink
The main board of the router is attached to the bottom part of the case with two screws. (In the image above, the screws are already removed.) Remove the screws and pull the board up from the case.
Disconnect the fan.
Turn over the board and remove the many screws holding the heatsink.

The heatsink has big thermal pads under it. They tend to act as a glue. Do your best to detach the heatsink without breaking the thermal pads. (I couldn't.)
The router will now look like this:

(Note that in the image above, I already did the cutting and drilling from the next step. I had one single-sided card and one double-sided card. I only cut the slot where the double-sided card would be installed.)
Step 6: Cut the heatsink (if needed)
Put away the router board and wifi cards. Very far away! Drilling will produce metal shavings that can cause shorts on electronic components.
If you need to install double-sided cards, cut the heatsink to make space for their back-side components. The heatsink metal is very soft. Use a fretsaw. Make sure you don't cut away the part where the screw holes should be!
Step 7: Drill and thread the mPCIe mounting screw holes
Measure your screws. Drill holes smaller than the screws. Drill and then thread the screw holes. It is VERY important to be precise! Wrong holes can't be corrected. This is the most difficult part of this mod.
Thread the holes. If you don't have taps that small, you can try to drill holes only a tiny bit smaller than the screws and destroy a few screws to make threads by forcing them into the holes.
I recommend to drill holes for both half-size and full-size cards, in case you need to change them later.
CLEAN THE HEATSINK and your workplace! There must be no metal filings left to contaminate the electronic components.
Test-install the new cards on the heatsink BEFORE mounting the heatsink. Make sure the screws are not long enough to protrude on the other side of the heatsink! They will damage the router board if they do. Cut them if too long. Remove the cards.
CLEAN THE HEATSINK AGAIN.
Step 8: Reinstall everything
Install the heatsink on the router board. Pay attention to the broken thermal pads. Replace them if you have thermal pads available. Connect the fan.
Install the new wifi cards. Make sure they sit properly in the slot and they don't move while tightening the screw. I recommend to use only one screw. One of the two holes may be better positioned than the other. If things don't work, or the card is visibly tilted in the slot, try the other screw.
Don't tighten the screws too much. The heatsink metal is weak and threads are easy to strip.
WARNING: Some cards, even if single-sided, have some traces on the back side. In this case, to avoid any shorts with the heatsink, place a thin plastic (or paper) foil under the card.
Install the board in the case. Connect the antenna cables. Don't close case yet.
This how it looks with the new cards:
Step 9: Test the new cards, install drivers
Power up the router and check that the new cards are detected, then close the case.
If they are not detected, check that they are properly inserted in the slots. Try to use the other screw instead. You may also try a cardboard or rubber spacer/washer under the card.
I had a card that was detected intermittently, even though it was propery inserted. I suspect that this router's power is noisy and that card didn't like it.
Install the new drivers and firmware.
Configure your wifi networks again. It is recommended to reset OpenWrt to the defaults (all of it). If not, very weird thing may happen.
Step 10: Done!
Enjoy a your new and very stable wifi network!
Note: A possible easier mod
The router's main board has holes to insert mPCIe mounting nuts/spacers. These holes are completely covered by the heatsink and can't be used.
As an alternative to my mod, a very large cut may be made in the heatsink so that these holes become available. In this case only two mini-PCIe nuts/spacers are needed and I expect that they will be perfectly aligned.
The bad part is that the original board won't have any bottom cooling if it is installed back over such a big hole in the heatsink.
This guide is licensed CC-BY-SA.
I would appreciate if someone adds it to WRT-1900AC page. Thanks!

8

[Assistant]
Nice work!
I have a WRT1900ACv1 - wifi works fine on DD-WRT - I assumed it also worked fine on latest OpenWrt.
The real problem child in the Linksys lineup is the WRT3200ACM - wifi on both DD-WRT and OpenWrt has issues.
Can that model also be modded in this way?

github.com/openwrt/openwrt
mwlwifi: update to version 10.3.9.0-20230311
openwrt:master ← anomeome:mwlwifi408PR
opened
Apr 11, 2023
anomeome
+19 -133
upstream PR 408 improvements, see: [PR408 comments](https://github.com/kaloz/mwl…
Might fix various issues. Somebody fixed pretty big problems. Probably still doesn’t support WPA3.

2 Replies
1

WRT1900ACv1 - supports WPA3 in DD-WRT - I have not tried a recent build of OpenWrt on it, but I suspect a Snaphot build should work.
WRT3200ACM - nothing will get WPA3 working on its wifi chip - just trying to is enough to disable wifi and will require a restore from backup to get wifi working correctly again.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Best router for gigabit WAN

Here are my requirements:
1Gbps LAN-WAN (No Sqm/Qos required)
Having multiple VLAN and Wifi SSIDs
I currently own an archer c7, but it's not capable of doing 1Gbps (caps at 550).
I've been doing my research on this forum and it basically boils down to WRT3200ACM or x86/x86_64 hardware.
In case of going with WRT router, it's capable of routing 1Gbps? Anyone know from first hand experience? The advantage of going with this router is that creating the vlans and other wifi's should be easier as it's the same config as with the c7.
For the other option, is there a recommended combo? I've seen I would need also a managed switch as most devices doesn't have extra ports. The ones I've seen and are within my capacities are J4105 or i3-5005U mini pc's. In case of going with one of those, how is the complexity to connect the different wifis to different vlans after passing through the managed switch?
Wifi AP <----------> Managed Switch <-----------> Router
I will have a ssid on wifi ap that I want on the same vlan as the ones connected on managed switch, and the others ssids on separate vlan.
Thanks in advance!

1 Reply
2

[Assistant]
I've got data over here that suggests the RPi4 is capable of this ... RPi4 routing performance numbers
It required a little tuning from raspbian, but I think that tuning is default in OpenWrt, at least someone suggested it was already done in the hotplug scripts.
It might do even better in a bonded interface situation which would probably let it engage more cores. Even at 850Mbps it was basically 50% idle. it should go higher than that when aggregating across several streams. Most real world situations the remote server won't have a gigabit to devote to one stream anyway.
Its about $100 with power supply, case, fan and SD card on amazon.
Add a smart switch, and an access point and you're all set. The tl-sg108e is the minimum switch I'd advocate. If you're running gigabit WAN you probably are the sort of person who needs more ports. QoS in the switch is useful.
The download stats for the RPi4 OpenWrt image suggests this is a popular option at the moment. several people have mentioned it working for them. basically haven't seen any complaints.
Jeff has some numbers on an x86 alternative, the Odroid H2, search the forum for that.
jghtac32:
how is the complexity to connect the different wifis to different vlans after passing through the managed switch?
It depends on the UI used in your managed switch and AP. generally it's pretty easy, you just set your router to use VLANs on the LAN and guest interfaces and then tell the switch to put the port your routers hooked to into those VLANs... a couple minutes

2

For the RPi4 I would need an usb3 to ethernet port based on your post, you were getting near 1Gbps shaping? If that's the case then without shapping rp4 should easily handle gigabit.
I've checked the Odroid H2 but seems it's a bit hard to get and then I would need to buy the ram since it doesn't include one. From amazon that's nearing the $200 range. I've found this alternative, which uses the same CPU https://www.amazon.com/gp/product/B07YJ7SN9F would that be good enough for gigabit?
In any of the 3 cases, for the switch is something like this is enough? It's the cheapest one I found https://www.amazon.com/dp/B07PLFCQVK/

New data on that thread I just posted today shows that with the right choice of USB ethernet (use a TP-Link UE300) the Pi routes and shapes a full gigabit at about 10% CPU usage on one core, and 5% on a second core (the key was getting a good USB ethernet).
I don't know anything about that switch first hand, but it should do fine based on spec.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt Router model that support 10Gbps?

Hi.
Is there OpenWRT device that support 10Gbps lan? (don't care wan speed. But if support multiple Gbps must be better.)

1 Reply
1

[Assistant]
Mitchell:
don't care wan speed.
You had better purchase a 10GbE switch instead

So... you mean,
there is NO 10Gbps OpenWRT device?

AMD64 / x86_64
But then why would you run OpenWrt at 10Gbps rather than a full distro?
Not to mention, Chelsio and other 10GigE drivers probably aren’t compiled by default.

1 Reply
2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: 802.11ax wifi AP mPCI-E cards

hi
Its almost mid 2020 and as we all deal with this Caronavirus outbreak, does anyone know of any 802.11ax mini PCI-E cards to use in a custom PCI-Engines router ?
I run a apu4b4 board
Ghat

2

[Assistant]
AP mode capable 802.11ax mini-PCIe (or rather M.2) cards don't exist yet.
Yes, there is the Intel AX200, which is useless for AP mode.
Yes, there are apparently the first samples for QCA QCN9074 available for sale from compex (no pricing yet, draw your own conclusions from that… around 200 USD for the 2.4 GHz model, around 200 USD for the 5 GHz model and around 250 USD for the 6 GHz model), but afaik those don't have driver support in ath11k (so far ath11k only covers QCN5024/ QCN5054 running on an ipq807x SOC) yet - and they wouldn't fit into your apu4b4 anyways (oversized, probably also drawing more power than the apu4b4 can provide; 802.11ax cards are running hot and need power). That said, it's questionable if the apu4b4 is fast enough to keep up with 802.11ax to begin with (at least the ethernet side isn't (and I'd be very sceptical what happens if you demand performance from both ethernet and wlan via PCIe concurrently), yes, 802.11ax can be faster than 1 GBit/s ethernet in practice, not just in theory) - and it only has a single mini-PCIe slot available (the other two are only USB XOR SATA and USB-only, but don't offer any PCIe lanes), while you'd need two (and both allowing oversized cards).

2 Replies

slh:
AP mode capable 802.11ax mini-PCIe (or rather M.2) cards don't exist yet.
https://compex.com.sg/shop/wifi-module/802-11ax-wifi-module/pn02-7-2
And soon we might see some MediaTek MT7915D/E based cards.

2

I think those are exactly the ones I referred to above, QCN9074 based and apparently in the ~200 USD range for the 5 GHz model, ~250 USD for the 6 GHz one (I haven't seen a pricing for the 2.4 GHz one so far).


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Tips for getting cheap used x86-based firewall with full Gbit NAT (a PC Engines APU) if you are in the US

While I was watching for old stuff I could play with on ebay I noticed that a few sellers are offering a few "cloud managed routers" (i.e. if you don't pay a subscription they are paperweights) from a company called "simplewan" that looked oddly familiar.
here some pictures (from auctions, not mine) they are bright orange.

The images are a dead giveaway, these devices seem to just be a branded version of PCEngines APU1 (the ones with black USB 2.0 ports) and PCEngines APU2 (the ones with the blue USB 3.0 ports) mini-PC firewall/routers.
These devices are labeled SW301DA or SW302DA but it is unclear if that relates to the hardware inside, the only 100% sure way to tell them apart is the USB ports on the back. Since you probably want the APU2 ones because they are better, ALWAYS watch the photos and send a message to the seller to confirm that you are getting the ones with BLUE USB 3.0 ports.
I've seen some that have been branded by someone else (kumo or xactlink or nextiva) and have a box with a different color (blue or gray) but they are all called "simplewan" in the listings and are obviously the same thing if you look at them from the port side.
PC Engines APU devices are generic mini PC firewalls with a BIOS so it's a good candidate for reuse with OpenWrt or pfSense OPNSense or IPFIre.
This is APU1 board https://pcengines.ch/apu.htm
and this is APU2 board https://pcengines.ch/apu2.htm
The case also acts as a heatsink so it's a fanless device
I bought the ones with USB 3.0 ports and they were indeed APU2C2 from PCEngines (2GB ram, 3x gigabit ports with Intel ethernet).
This is the spec page of the devices I have bought and opened https://pcengines.ch/apu2c2.htm
They seem to be running some random BSD-derived firmware on the same 4GB SLC SDcard PCEngines also sells. Mhh, a free 4GB SLC Sdcard is included boys.
Yes I'm not in the US but I still managed to get heavily discounted prices on a few lots (well below market price in the EU while still paying the import fees) because apparently nobody wants to buy used "cloud managed routers" aka hardware that does not work without paying a businness subscription to simplewan.
But since the hardware is not really locked down, you can just open them, pull the SDcard and flash whatever you want on it. Or install a mSata SSD and run from that. The devices are not "locked" to use only their original firmware.
The brand/logo can be easily removed from the case if you leave the metal part in a bit of "gentle nail polish liquid" (i.e. not straight acetone) overnight for the white ink to soften up and then remove gently with a plastic tool. You need a sealed plastic container for this to work, of course.
This other site (that sells normal PC Engines APU new in EU but is otherwise unrelated to my post) has a few articles you might want to check out, for connecting to these devices using the serial port from Windows https://teklager.se/en/knowledge-base/serial-connection-putty-windows/
And upgrading the coreboot BIOS to a more recent version (which isn't strictly required to use OpenWrt, but newer versions should unlock CPU turbo so it would get some more performance)
https://teklager.se/en/knowledge-base/apu-bios-upgrade/
As for performance, APU2 can NAT at full Gbit on Linux and 650-700 on pfSense (see benchmarks here https://teklager.se/en/knowledge-base/apu2c0-ipfire-throughput-test-much-faster-pfsense/ and in the other article where they mention OpenWrt being at 1Gbit on single or multi streams, because Linux https://teklager.se/en/knowledge-base/apu2-1-gigabit-throughput-pfsense/ ).
It also has AES-NI crypto acceleration.
They mention "with a new bios" for the pfsense performance because new BIOS enables CPU boost to 1.4 Ghz so the CPU can clock higher when only a few cores are loaded (as I said BSDs can only run the interrupts on a single core)
They also show some benchmarks for VPN performance on APU2 and it's 100-150 Mbit/s for OpenVPN (again pfSense is lower and OpenWrt is higher), or 600 Mbit for Wireguard https://teklager.se/en/knowledge-base/apu2-vpn-performance/
APU1 are less powerful than that, and have no AES-NI support but you can still expect around 900 Mbit/s NAT on Linux and closer to 500MBit on pfSense and OPNSense
https://forum.mikrotik.com/viewtopic.php?p=420450&hilit=alix+apu
If you want to upgrade the BIOS on your new APU, please check the article on the wiki where I also uploaded a dedicated OpenWrt image for BIOS flashing https://openwrt.org/toh/pcengines/apu-bios-update

2 Replies
15

[Assistant]
Thnx,
noticed it's $40 or make an offer för the usb3 version.
Might just grab one for fun ,)
480MBps WAN throughput, is kind of a let down, but no real surprise.
voipsupply.com
simplewan_advanced_2_datasheet.pdf
2.65 MB

2 Replies
1

Is anyone interested in these ?
If so, drop me a PM. I can probably get them to EU for roughly €55/piece including shipping and customs, excluding shipping from me to you, within EU (from .se).
No strings attached, no upfront payment (until I'll be sending them to you).

3

frollic:
480MBps WAN throughput, is kind of a let down, but no real surprise.
https://www.voipsupply.com/downloads/dl/file/id/26701/simplewan_advanced_2_datasheet.pdf
Those numbers (and specs) are for the APU1 ones, with USB 2.0 (also see the image in the pdf). Seems these devices were originally all APU1 with 4GB RAM but then PCEngines discontinued them and seems they just started shipping APU2 with 2Gb RAM instead.
Also their numbers are for whatever old BSD the stock "firmware" is based on, which is usually lower performance on NAT than Linux because it is not able to split interrupts on more than one CPU core.
APU2 is a better CPU, it can NAT at full Gbit on Linux and 650-700 on pfSense (see benchmarks here https://teklager.se/en/knowledge-base/apu2c0-ipfire-throughput-test-much-faster-pfsense/ and in the other article where they mention OpenWrt being at 1Gbit on single or multi streams, because Linux https://teklager.se/en/knowledge-base/apu2-1-gigabit-throughput-pfsense/ ).
It also has AES-NI crypto acceleration.
They mention "with a new bios" for the pfsense performance because new BIOS enables CPU boost to 1.4 Ghz so the CPU can clock higher when only a few cores are loaded (as I said BSDs can only run the interrupts on a single core)
They also show some benchmarks for VPN performance on APU2 and it's 100-150 Mbit/s for OpenVPN (again pfSense is lower and OpenWrt is higher), or 600 Mbit for Wireguard https://teklager.se/en/knowledge-base/apu2-vpn-performance/

3


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: 802.11ax Routers

According to the article, D-Link and ASUS launching 802.11ax routers by the end of the year...
ZDNet
D-Link, Asus tout 802.11ax Wi-Fi routers, but you'll have to wait until later in...
At CES 2018, there's acknowledgement that Wi-Fi networks need more speed and support for multiple devices. Get ready for the futuristic router with eight antennas.

3

[Assistant]
I spotted some support for ax in kernel upstream. I believe it is termed as “HE” mode (high efficiency) similar to how we currently have “HT” for high throughout.
No support in luci yet obviously.

Huawei already release ax model based on IPQ8074
https://wikidevi.com/wiki/Huawei_AP7060DN

I wonder if there'll be any viable drivers available for 11ax.

2 Replies
2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Support for Asus ZenWiFi BT8 Tri-band Wifi7 (Mediatek MT7988)

I recently looked for routers having similar hardware as the Banana Pi BPI-R4 and asked if anyone had tried the TP-Link BE805 (not BE800)
At this link you can see wifi7 hardware in different routers and the recently released Asus Zenwifi BT8 (RT-BE14000) has a similar Mediatek setup.
However, I noticed that models that have support for Openwrt all use the MT7988A cpu and Asus has a MT7988D
And there is a older model from TP-Link: TL-7DR7230/7260 - that has the same MT7988D cpu that does not have Openwrt support.
I can get a hold of a Asus Zenwifi BT8 soon, would it be a waste of warranty to open it up and look for a serial connection ?
(there does not seem to be any FCC images)
BTW, I already have a Banana Pi BPI-R4 with Wifi7 - Im just interested in finding more OpenWRT compatible equipment

3

[Assistant]
The MIPS MT7621 SoC family - which is still pretty popular here - had multiple flavours as well. I expect this Asus to be supportable based purely on the SoC. However, it also depends on whether one is able to gain access to the boot loader, or if there is another way to get a shell through e.g. an exploit. That gets progressively harder as manufacturers lock down their hardware more and more every generation.
The other devices you mentioned are most probably unsupported because nobody capable either has them or is interested in porting them. Keep in mind BE hardware is still rather new and not all the necessary code is available or accessible (especially for non-MediaTek SoCs).

1

OK, the Asus BT8 seems to be widely available, at least in Europe and US.
I will probably open it up, take some pictures and get back here

Got the device

There is one 2.5Gbps wan, one 2.5Gbps lan, two 1Gbps lan and one USB 3 port.

To open it up - remove the rubber feet at the bottom to revile some screws.

Then push the front upwards to remove it and unscrew 7 more.

Then you have to pry to remove the top cover (its helpful with a plastic tool for this)

Inside you will find what is actually the wifi cooler - to remove the entire structure from the case you just snap off the two plastic holders on the right and left of the cooler.

The other side has the cpu cooler

And with the cooler removed we see...

The MT7988DV cpu

And what do you know - how convenient
This is as far as I have gotten, have not even tried to connect it (or even start the device) yet.

1 Reply
6


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Comparative Throughput Testing Including NAT, SQM, WireGuard, and OpenVPN

Overview
While there's been a lot of individuals testing various routers, the question still always seems to come up, "What can I expect from Router X?"
I won't say that my testing is going to definitively answer those questions, but at least it should be a self-consistent data set.
To be very clear, this is a benchmark. Like most benchmarks, the performance you get in your own environment may be different. If you have a craptastic ISP, a lossy ISP connection, a flakey cable, hosts pummeling your LAN with broadcast traffic, a different traffic distribution, a poorly implemented router, or any of an uncountable number of other things, the results you see may not meet the levels reported here. It is your responsibility to use any information provided here to assist you in making your decision.
Testing Outline
Testing was performed using flent which provides "stress testing" by using multiple streams. The three tests shown are tcp_8down, tcp_8up, (with ICMP ping) and RRUL (4 up, 4 down, with 3 UDP ping and ICMP ping). IPv4 was used. The standard, 60-second test duration (for an overall 70-second run duration) was used. These multi-stream tests are more stressful than single-stream testing.
This testing uses full (1500 MTU), TCP packets. If your traffic consists of a large fraction of small packets (such as VOIP), the PPS (packet-per-second) rate will be much higher for a given bandwidth. These effects are not explored in this thread, though they may further limit the performance in your environment.
Flow offloading is not enabled in the config. At the present time (September, 2019) it apparently does not work on master. (2019-09-27 – Appears to now be resolved on master)
Current testing does not include irqbalance. Earlier testing included irqbalance running from boot for multi-core devices. Note that it needs to be enabled in /etc/config/irqbalance to have an effect. At least one device under some conditions seems to perform worse with irqbalance enabled (IPQ4019). It has been hypothesized that the overhead of running irqbalance at the limits of performance is behind that observation. Performing tests with your device in your environment is suggested.
Default CPU-speed governors and settings were used. Many suggest that "tweaks" here can improve start-up and steady-state performance. If your tweaks let you exceed these numbers in practice, that's great!
SQM using piece_of_cake.qos was applied to the WAN interface for NAT/routing, or to the VPN's tunnel interface for WireGuard and OpenVPN. The same bandwidth target was applied for upstream as well as downstream. Overhead of 22 was used for Ethernet, 82 for WireGuard1, and 95 for OpenVPN2. The overhead values are believed to be close to correct, but are not prescriptive.
After staring at too many of these runs early on in this effort, I realized how much of a judgement call it was to look at a run and say if it was good or bad. Also, the sheer number of runs needed, even at just over a minute each, pushed me to automate the testing (even automated, the full set of runs takes five or six hours per device). I settled on the following criteria for a "good" SQM run:
Coefficient of variance of bandwidth of all eight TCP streams under 1%, or
Standard deviation of bandwidth of all eight TCP streams under 0.02 Mbps
Basically, if the streams go out of balance from each other by a "tiny" bit, then SQM is starting to break down. The second criteria comes into play for low-bandwidth runs (typically under 10 Mbps, aggregate), where the output from flent for a single stream might be 0.12 Mbps and the variance gets dominated by the rounding precision and/or single packets become significant in the flow measurement variance.
When the ICMP-ping time exceeded 10 ms, the highest throughput with a ICMP-ping time of under 10 ms is shown as well.
The number shown is the reported throughput, not the SQM bandwidth-target setting.
LuCI is not "logged in" as early testing on a single-core device suggested that this can significantly degrade throughput performance. LuCI is installed and nginx / OpenSSL is installed and running. Running LuCI and generating page content will likely reduce the performance seen on single-core devices.
Wireless is not enabled.
WireGuard and OpenVPN were installed on Debian 10 ("Buster") on two upper-range x86_64/AMD64 machines. An AMD Ryzen 5 2600X was configured as the VPN "server" and netserver host and an Intel i3-7100T was driving the test as the "LAN" client. OpenVPN is configured for UDP, without compression. The test harness is capable of over 900 Mbps rates for Ethernet and WireGuard using netperf (effectively at the media limits with iperf3). It is capable of ~500 Mbps for OpenVPN.
As I'm not recommending any specific devices in this thread, I've listed them by target, clock speed, number of cores, and the SoC.
All tested devices have at least 128 MB of RAM.
Speeds are in Mbps, aggregate, as reported by flent (which uses netperf). Non-SQM runs are the median of five runs. SQM runs required two "successes" with less than two non-successful runs at a given bandwidth target. The parenthetical numbers are the median ping time in ms. Results rounded to at most two significant figures.
With a minimum step size in the SQM bandwidth-target search around 5%, differences of around 5-10% may not be signficant in the SQM results. As ping time often increases abruptly as SQM starts to get overstressed (which is where these results are measured), I wouldn't consider ping time for SQM results as more than "interesting information" about the benefits of SQM when the router is stressed, not just the line.
Note that the RRUL test has upstream and downstream flows "competing" with each other. Especially noted in VPN testing, there can be a huge imbalance between the two without SQM, with one direction or the other dominating, or even effectively excluding the other.
Remember, the tcp_8up or tcp_8down tests' numbers don't imply that you can get that throughput in both directions simultaneously. Look at the RRUL numbers for simultaneous throughput. Remember that the RRUL numbers are already the total of upstream and downstream.
I would suggest selecting a device that exceeds your needs by a comfortable margin as measures of performance other than throughput (such as latency and stream "fairness") are often much better at slightly lower bandwidths than at the limits of performance.
Q&A
Router X's ping time is so high. Router Y's is lower and it's cheaper. Router X sucks!
Remember that this is a test to estimate the limits of performance, not to estimate latency under reasonable operating conditions. You shouldn't be regularly pushing your router this hard. At reasonable rates, the tested routers should all provide reasonable latency of a couple milliseconds or less, with another couple added if a VPN is involved for the slower SoCs. Even just backing down the SQM bandwidth target a small amount can significantly reduce the latency.
The note says that downstream OpenVPN dominates the results. Does that mean it only works well in one direction?
As with ping time, these numbers are at the limits of performance. When CPU or other limits come into play, "balance" can be greatly impacted by the code involved, kernel prioritization, implementation details of the TCP stack and Ethernet drivers, and the like. Virtually all of the OpenVPN tests without SQM and with competing upstream and downstream streams resulted in virtually only downstream results. Back off of these limits by reducing the throughput you're asking for (fewer requests or SQM) and reasonable, simultaneous upstream and downstream performance can be achieved.
WireGuard also exhibits imbalance, though not to the extremes seen in the OpenVPN testing.
My iperf3 results are better.
That wouldn't surprise me. There's less to keep track of with a single stream, especially with SQM in play. Similar comments apply for things like the DSLReports test, which is a download test then an upload test.
Why haven't you tested Router X?
Likely because I don't own it, it's too old, or I haven't gotten to it yet.
But, it's faster if you set...
This primarily around providing general guidance if a device is "sufficient" for an application, especially for users that do not build their own images or highly configure OpenWrt. Things are pretty much stock with these configs. Any improvements over stock config or build are a bonus.
Have a great tweak? I'd be interested in hearing about it on another thread, as would many others!
Results
Differences in SQM results of less than 5-10% may not be significant.
as the smallest SQM step size explored was ~5%. Remember also that at the limits of performance of the device, dropping the SQM bandwidth target slightly can significantly reduce the latency.
Note that 10% of 920 Mbps is nearly 100 Mbps.
Results rounded to two significant figures or less (this is more than the step size of the SQM tests).
If you skipped to here, use of flow offloading is indicated, the CPU-speed (governor) parameters have not been changed from the defaults, and there are no other "performance tweaks" known to be applied in the build or configuration. piece_of_cake.qos is used for SQM testing. Wireless is not enabled.
Key:
1720
(6) Throughput in Mbits/s
ping time in ms
When two results are shown side-by-side in the same cell, one represents the performance seen with a ping time of 10 ms or less. The other is the "by the test" limit where SQM was starting to "fall apart".
Routing/NAT
No Flow Offload
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
x86_64 1500-2500 4 Celeron J4105 Realtek RT8111A 920
(4) 940
(4)

x86_64 1000-1400 4 AMD
GX-412TC Intel i211AT 920
(4) 940
(5)

mvebu a9 1866 2 88W8964 940
(2) 940
(2)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 560
(31) 510
(35)

ipq40xx 717 4 IPQ4019 Single RGMII3 840
(19) 940
(6)

ath79 775 1 QCA9563 Single MAC 470
(9) 380
(9)

ath79 720 1 QCA9558 Dual MAC 390
(8) 320
(9)

ath79 650 1 QCA9531 100 Mbps phys 67
(1) 86
(3)

ramips 580 1 MT7628N 100 Mbps phys 94
(6) 94
(7)

With Flow Offload (Many Devices Not Yet Tested)
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
mvebu a9 1866 2 88W8964 940
(2) 940
(2)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 910
(8) 910
(9)

ipq40xx 717 4 IPQ4019 Single RGMII3 940
(1) 940
(3)

L The downstream, SQM throughput seems to be limited by something other than the SQM bandwidth target itself. Increasing the bandwidth target past this point did not significantly increase throughput, although the streams remained in balance.
WireGuard, Routing/NAT
No Flow Offload
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
x86_64 1500-2500 4 Celeron J4105 Realtek RT8111A 880
(5) 900
(7)

x86_64 1000-1400 4 AMD
GX-412TC Intel i211AT 550
(18) 460
(8)

mvebu a9 1866 2 88W8964 890
(8) 770
(13)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 280
(9) 220
(10)

ipq40xx 717 4 IPQ4019 Single RGMII3 350
(30) 260
(117)

ath79 775 1 QCA9563 Single MAC 80
(33) 75
(34)

ath79 720 1 QCA9558 Dual MAC 78
(38) 74
(40)

ath79 650 1 QCA9531 100 Mbps phys 51
(15) 67
(59)

ramips 580 1 MT7628N 100 Mbps phys 48
(34) 46
(65)

With Flow Offload (Many Devices Not Yet Tested)
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
mvebu a9 1866 2 88W8964 900
(4) 770
(16)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 310
(8) 270
(7)

ipq40xx 717 4 IPQ4019 Single RGMII3 410
(29) 300
(102)

L The downstream, SQM throughput seems to be limited by something other than the SQM bandwidth target itself. Increasing the bandwidth target past this point did not significantly increase throughput, although the streams remained in balance.
OpenVPN, Routing/NAT
OpenVPN tested at the device's limits with the bi-directional, RRUL test and without SQM results in the vast majority of bandwidth (often 90% or more) being downstream.
AES-256-CBC (Many Devices Not Yet Tested)
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
mvebu a9 1866 2 88W8964 148
(24) 106
(7)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 82
(39) 58
(13)

ipq40xx 717 4 IPQ4019 Single RGMII3 31
(84) 24
(32)

AES-256-CBC with Flow Offload (Many Devices Not Yet Tested)
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
mvebu a9 1866 2 88W8964 165
(20) 110
(7)

mvebu a53 1000 2 88F3720 OEM v19.01rc1? 103
(36) 65
(12)

ipq40xx 717 4 IPQ4019 Single RGMII3 31
(73) 26
(29)

Older Tests -- Likely BF-CBC
Target Clock Cores SoC / CPU Notes 8 Dn 8 Up
x86_64 1500-2500 4 Celeron J4105 Realtek RT8111A 240
(18) 200
(5)

x86_64 1000-1400 4 AMD
GX-412TC Intel i211AT 68
(58) 56
(16)

ipq40xx 717 4 IPQ4019 Single RGMII3 31
(83) 26
(29)

ath79 775 1 QCA9563 Single MAC 20
(200) 15
(60)

ath79 720 1 QCA9558 Dual MAC 21
(188) 16
(57)

ath79 650 1 QCA9531 100 Mbps phys 16
(220) 12
(73)

ramips 580 1 MT7628N 100 Mbps phys 14
(290) 10
(88)

Notes
On VPN
Encryption is often more expensive than is decryption.
The RRUL test has upstream and downstream flows "competing" with each other. Without SQM, the results shown are often dominated by one direction or the other. For OpenVPN, the effect is nearly complete with "only" downstream traffic showing significant bandwidth (often 90% or more). Interestingly, for WireGuard, the upstream direction seems to get more of the traffic and there is still a reasonable downstream flow.
If latency is important to you, using SQM on the tunnel interface may help significantly (at the cost of overall bandwidth).
On Bandwidth
The link bandwidth will always exceed the upper-layer, payload throughput. This is due to a variety of factors including, for example:
Collision avoidance and sync on the media
Media-layer (Ethernet) framing
IP framing
TCP framing
Control, ACK packets
Other packets on the link (such as ARP and broadcasts)
Packet loss
The rough, theoretical throughput limit for TCP over GigE (without jumbo frames) is ~940 Mbps4.
WireGuard or OpenVPN encapsulation further reduces this to ~900 Mbps1,2.
ACK packets reduce the "opposite" direction capacity by a bit over 5% 5.
It is not clear if netperf measures bandwidth including IP and TCP headers or not. Similarly, I think that it probably does not include Ethernet framing.
netperf documentation may be found at https://hewlettpackard.github.io/netperf/doc/netperf.html and https://github.com/HewlettPackard/netperf, along with source.
flent documentation may be found at https://flent.org/
Firmware Source References
The following commits are the base on which the various images were built (all builds from master:
x86_64 – commit 1c0290c5cc, CommitDate: Fri Aug 30 20:45:40 2019 +0200
IPQ4019 – commit c3a78955f3, CommitDate: Mon Aug 26 18:21:13 2019 +0200
QCA9558 – commit 921675a2d1, CommitDate: Sat Aug 24 08:55:33 2019 +0800
QCA9563 – commit b133e466b0, CommitDate: Wed Aug 14 12:36:37 2019 +0200
QCA9531 – commit b133e466b0, CommitDate: Wed Aug 14 12:36:37 2019 +0200
Note significant changes have occurred on master since the other devices' builds.
MT7682N - commit 2fedf023e4, CommitDate: Wed Nov 27 20:20:31 2019 +0100
88F3720 tested with OEM likely has a merge base of OpenWrt v19.07.0-rc1 or -rc2; OpenWrt 19.07-SNAPSHOT r10273-2b88d02. This device has yet to be ported to mainline OpenWrt. The OEM provides its fork of the openwrt-19.07 branch as source for its firmware.
88W8964 – commit b1e8a390ea, CommitDate: Thu Dec 19 15:40:49 2019 +0100
Footnotes
1 Additional 60-byte overhead for WireGuard for IPv4 (80 bytes for IPv6)
2 Additional 73-byte overhead based on a reported 1427 MTU for OpenVPN
3 The present (2019) DTS/driver for the ipq40xx is believed to only use one path, although two interfaces are revealed.
4 1500 bytes MTU less 20 bytes minimal IPv4 header less 20 bytes minimal TCP header gives 1460 maximum payload. Ethernet framing of 22 bytes (with 802.1Q VLAN tagging) plus 8 byte sync and start-of-frame delimiter plus 12 byte minimal interpacket gap gives 1542 byte-times on the wire. 1460/1542 ~ 94.7%, under ideal timing and no other clients or packets on the wire. Note that IPv6 headers are larger (40 bytes, minimum) and will reduce the factor further.
5 Minimal Ethernet packet (for a "naked ACK") is 84 byte-times on the wire. 84/1542 ~ 5.4%
Edit history:
2019-09-16
Correct that it is ICMP-ping time
Add link to Python scripts on Github
2019-09-17
Quantified ACK-packet bandwidth effect
2019-09-27
Clarified SQM bandwidth target, rather than "target" in the context of the inner workings of the queueing mechanisms on suggestion of
@moeller0
Added note that flow offloading appears to be functional now on master
2019-10-03
Added "key" for table values
2019-11-28
Added MediaTek MT7828N results
2019-12-18
Note that earlier, OpenVPN tesing was likely with BF-CBC, not AES-256-CBC
2019-12-21
Add 88F3720, 88W8964, update results for IPQ4019

1 Reply
54

[Assistant]
Stock CFLAGS or did you use -O2 and/or any other optimization on the OpenWrt devices?

1

Stock CFLAGS, yes. No changes to CPU governors or Ethernet settings from whatever "stock" sets.
Here's an example diffconfig (EFI enabled with https://github.com/openwrt/openwrt/pull/1968, "build_details" is a local package that captures details of my source tree in the image)
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_64=y
CONFIG_TARGET_x86_64_Generic=y
CONFIG_DEVEL=y
CONFIG_BUSYBOX_CUSTOM=y
CONFIG_BUILD_LOG=y
CONFIG_BUSYBOX_CONFIG_FEATURE_EDITING_SAVEHISTORY=y
CONFIG_BUSYBOX_CONFIG_FEATURE_REVERSE_SEARCH=y
CONFIG_BUSYBOX_CONFIG_FEATURE_VERBOSE_CP_MESSAGE=y
CONFIG_CCACHE=y
CONFIG_DOWNLOAD_FOLDER="/home/jeff/devel/openwrt_dl"
CONFIG_EFI_IMAGES=y
CONFIG_NGINX_HEADERS_MORE=y
CONFIG_NGINX_HTTP_ACCESS=y
CONFIG_NGINX_HTTP_AUTH_BASIC=y
CONFIG_NGINX_HTTP_AUTOINDEX=y
CONFIG_NGINX_HTTP_BROWSER=y
CONFIG_NGINX_HTTP_CACHE=y
CONFIG_NGINX_HTTP_CHARSET=y
CONFIG_NGINX_HTTP_EMPTY_GIF=y
CONFIG_NGINX_HTTP_FASTCGI=y
CONFIG_NGINX_HTTP_GEO=y
CONFIG_NGINX_HTTP_GZIP=y
CONFIG_NGINX_HTTP_LIMIT_CONN=y
CONFIG_NGINX_HTTP_LIMIT_REQ=y
CONFIG_NGINX_HTTP_MAP=y
CONFIG_NGINX_HTTP_MEMCACHED=y
CONFIG_NGINX_HTTP_PROXY=y
CONFIG_NGINX_HTTP_REFERER=y
CONFIG_NGINX_HTTP_REWRITE=y
CONFIG_NGINX_HTTP_SCGI=y
CONFIG_NGINX_HTTP_SPLIT_CLIENTS=y
CONFIG_NGINX_HTTP_SSI=y
CONFIG_NGINX_HTTP_UPSTREAM_HASH=y
CONFIG_NGINX_HTTP_UPSTREAM_IP_HASH=y
CONFIG_NGINX_HTTP_UPSTREAM_KEEPALIVE=y
CONFIG_NGINX_HTTP_UPSTREAM_LEAST_CONN=y
CONFIG_NGINX_HTTP_USERID=y
CONFIG_NGINX_HTTP_UWSGI=y
CONFIG_NGINX_NAXSI=y
CONFIG_NGINX_PCRE=y
CONFIG_OPENSSL_ENGINE=y
CONFIG_OPENSSL_OPTIMIZE_SPEED=y
CONFIG_OPENSSL_WITH_ASM=y
CONFIG_OPENSSL_WITH_CHACHA_POLY1305=y
CONFIG_OPENSSL_WITH_CMS=y
CONFIG_OPENSSL_WITH_DEPRECATED=y
CONFIG_OPENSSL_WITH_ERROR_MESSAGES=y
CONFIG_OPENSSL_WITH_PSK=y
CONFIG_OPENSSL_WITH_SRP=y
CONFIG_OPENSSL_WITH_TLS13=y
CONFIG_OPENVPN_openssl_ENABLE_DEF_AUTH=y
CONFIG_OPENVPN_openssl_ENABLE_FRAGMENT=y
CONFIG_OPENVPN_openssl_ENABLE_LZ4=y
CONFIG_OPENVPN_openssl_ENABLE_LZO=y
CONFIG_OPENVPN_openssl_ENABLE_MULTIHOME=y
CONFIG_OPENVPN_openssl_ENABLE_PF=y
CONFIG_OPENVPN_openssl_ENABLE_PORT_SHARE=y
CONFIG_OPENVPN_openssl_ENABLE_SERVER=y
CONFIG_OPENVPN_openssl_ENABLE_SMALL=y
CONFIG_PACKAGE_build-details=y
CONFIG_PACKAGE_ca-bundle=y
CONFIG_PACKAGE_diffutils=y
CONFIG_PACKAGE_ethtool=y
CONFIG_PACKAGE_findutils=y
CONFIG_PACKAGE_findutils-find=y
CONFIG_PACKAGE_findutils-locate=y
CONFIG_PACKAGE_findutils-xargs=y
CONFIG_PACKAGE_git=y
CONFIG_PACKAGE_grub2-efi=y
CONFIG_PACKAGE_htop=y
CONFIG_PACKAGE_i2c-tools=y
CONFIG_PACKAGE_ip-bridge=y
CONFIG_PACKAGE_ip-full=y
CONFIG_PACKAGE_iperf3=y
CONFIG_PACKAGE_iptables-mod-conntrack-extra=y
CONFIG_PACKAGE_iptables-mod-ipopt=y
CONFIG_PACKAGE_irqbalance=y
CONFIG_PACKAGE_jansson=y
CONFIG_PACKAGE_kmod-crypto-crc32c=y
CONFIG_PACKAGE_kmod-crypto-hash=y
CONFIG_PACKAGE_kmod-fs-ext4=y
CONFIG_PACKAGE_kmod-fs-vfat=y
CONFIG_PACKAGE_kmod-ifb=y
CONFIG_PACKAGE_kmod-ipt-conntrack-extra=y
CONFIG_PACKAGE_kmod-ipt-ipopt=y
CONFIG_PACKAGE_kmod-ipt-raw=y
CONFIG_PACKAGE_kmod-lib-crc16=y
CONFIG_PACKAGE_kmod-nls-base=y
CONFIG_PACKAGE_kmod-nls-cp437=y
CONFIG_PACKAGE_kmod-nls-iso8859-1=y
CONFIG_PACKAGE_kmod-nls-utf8=y
CONFIG_PACKAGE_kmod-sched-cake=y
CONFIG_PACKAGE_kmod-sched-core=y
CONFIG_PACKAGE_kmod-tun=y
CONFIG_PACKAGE_kmod-udptunnel4=y
CONFIG_PACKAGE_kmod-udptunnel6=y
CONFIG_PACKAGE_kmod-wireguard=y
CONFIG_PACKAGE_less=y
CONFIG_PACKAGE_libacl=y
CONFIG_PACKAGE_libattr=y
CONFIG_PACKAGE_libcap=y
CONFIG_PACKAGE_libelf=y
CONFIG_PACKAGE_libi2c=y
CONFIG_PACKAGE_libiwinfo=y
CONFIG_PACKAGE_libiwinfo-lua=y
CONFIG_PACKAGE_liblua=y
CONFIG_PACKAGE_liblucihttp=y
CONFIG_PACKAGE_liblucihttp-lua=y
CONFIG_PACKAGE_liblzo=y
CONFIG_PACKAGE_libmnl=y
CONFIG_PACKAGE_libncurses=y
CONFIG_PACKAGE_libopenssl=y
CONFIG_PACKAGE_libopenssl-conf=y
CONFIG_PACKAGE_libpcap=y
CONFIG_PACKAGE_libpcre=y
CONFIG_PACKAGE_libpopt=y
CONFIG_PACKAGE_libubus-lua=y
CONFIG_PACKAGE_libusb-1.0=y
CONFIG_PACKAGE_lua=y
CONFIG_PACKAGE_luci-app-firewall=y
CONFIG_PACKAGE_luci-app-openvpn=y
CONFIG_PACKAGE_luci-app-sqm=y
CONFIG_PACKAGE_luci-app-wireguard=y
CONFIG_PACKAGE_luci-base=y
CONFIG_PACKAGE_luci-lib-ip=y
CONFIG_PACKAGE_luci-lib-jsonc=y
CONFIG_PACKAGE_luci-lib-nixio=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-mod-network=y
CONFIG_PACKAGE_luci-mod-status=y
CONFIG_PACKAGE_luci-mod-system=y
CONFIG_PACKAGE_luci-proto-ipv6=y
CONFIG_PACKAGE_luci-proto-ppp=y
CONFIG_PACKAGE_luci-proto-wireguard=y
CONFIG_PACKAGE_luci-ssl-nginx=y
CONFIG_PACKAGE_luci-theme-bootstrap=y
CONFIG_PACKAGE_nginx-mod-luci-ssl=y
CONFIG_PACKAGE_nginx-ssl=y
CONFIG_PACKAGE_openssl-util=y
CONFIG_PACKAGE_openvpn-openssl=y
CONFIG_PACKAGE_procps-ng=y
CONFIG_PACKAGE_procps-ng-free=y
CONFIG_PACKAGE_procps-ng-kill=y
CONFIG_PACKAGE_procps-ng-pgrep=y
CONFIG_PACKAGE_procps-ng-pkill=y
CONFIG_PACKAGE_procps-ng-pmap=y
CONFIG_PACKAGE_procps-ng-ps=y
CONFIG_PACKAGE_procps-ng-pwdx=y
CONFIG_PACKAGE_procps-ng-skill=y
CONFIG_PACKAGE_procps-ng-slabtop=y
CONFIG_PACKAGE_procps-ng-snice=y
CONFIG_PACKAGE_procps-ng-tload=y
CONFIG_PACKAGE_procps-ng-top=y
CONFIG_PACKAGE_procps-ng-uptime=y
CONFIG_PACKAGE_procps-ng-vmstat=y
CONFIG_PACKAGE_procps-ng-w=y
CONFIG_PACKAGE_procps-ng-watch=y
CONFIG_PACKAGE_rpcd=y
CONFIG_PACKAGE_rpcd-mod-rrdns=y
CONFIG_PACKAGE_rsync=y
CONFIG_PACKAGE_sqm-scripts=y
CONFIG_PACKAGE_tc=y
CONFIG_PACKAGE_tcpdump-mini=y
CONFIG_PACKAGE_terminfo=y
CONFIG_PACKAGE_usbutils=y
CONFIG_PACKAGE_uwsgi-cgi=y
CONFIG_PACKAGE_uwsgi-cgi-luci-support=y
CONFIG_PACKAGE_wireguard=y
CONFIG_PACKAGE_wireguard-tools=y
CONFIG_PACKAGE_zlib=y
CONFIG_RSYNC_acl=y
CONFIG_RSYNC_xattr=y
CONFIG_RSYNC_zlib=y

Important factual information for all Newbies
Openwrt is slower than stock firmware for throughput in real life usage, in some cases by as much as 80%.

2