[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: GL.iNet GL-MT6000 - AQL and WiFi Latency

Update 05/28/2024:
Created a script to allow one to easily update the aql_txq_limit:
GL.iNet GL-MT6000 - AQL and WiFi Latency
Network and Wireless Configuration
@phinn
I put together the script below to provide an easy way to tweak the aql_txq_limit. Basic usage: (First time) Set the file as executable: # chmod +x change-aql.sh Call the script with one of latency, balanced, bandwidth, or a valid integer value. This will tune the AQL Tx queue limit to the preference (or integer value) specified.
Example: Set 'balanced' Preference
# ./change-aql.sh balanced >> Device setting: /sys/kernel/debug/ieee80211/phy1/aql_txq_limit << Before…
Update 05/14/2024:
@tohojo
Provides a great explanation of these settings here:
How OpenWrt Vanquishes Bufferbloat
Site Feedback and Other Questions
A few notes on your questions in the original post: Cake first appeared in 2015, according to the commit log and copyright notices in the out-of-tree repo. It was upstreamed in 2018. The driver can be queried for support through iw list - look for TXQS, AIRTIME_FAIRNESS and AQL in the "Supported extended features" list at the end of the output for a given phy device. The AQL limits can be tuned through debugfs: cat /sys/kernel/debug/ieee80211/phy0/aql_txq_limit AC AQL limit low AQL limit hi…
Original Thread:
This thread is intended to be a GL.iNet GL-MT6000 specific continuation of the
E8450/RT3200 thread I kicked off here, some time ago.
I'm kicking off this topic specifically for discussion around AQL and other wireless latency points. This is not meant to be another topic for discussing SQM on the ethernet side of the device.
Having been inspired by this, myself, I wonder if I might entice anyone to join with me in experimenting a little. I interested to see if anyone is willing to run the following and do some testing along with me.
Recommended Testing/Bechmark Tool:
Crusader Network Tester
GitHub
GitHub - Zoxc/crusader: A network bandwidth and latency tester.
A network bandwidth and latency tester. Contribute to Zoxc/crusader development by creating an account on GitHub.
Latest releases available here:
GitHub
Releases · Zoxc/crusader
A network bandwidth and latency tester. Contribute to Zoxc/crusader development by creating an account on GitHub.
AQL Settings
For 2.4ghz radio:
22.03.x+: for ac in 0 1 2 3; do echo $ac 2500 2500 > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
For 5ghz radio:
22.03.x+: for ac in 0 1 2 3; do echo $ac 2500 2500 > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done
You can confirm the settings applied by checking the following:
For 22.03.x+: cat /sys/kernel/debug/ieee80211/phy*/aql_txq_limit
It should look something like this:
root@AP:~# cat /sys/kernel/debug/ieee80211/phy*/aql_txq_limit
AC AQL limit low AQL limit high
VO 2500  2500
VI 2500  2500
BE 2500  2500
BK 2500  2500
AC AQL limit low AQL limit high
VO 2500  2500
VI 2500  2500
BE 2500  2500
BK 2500  2500
To retain the settings upon restarts, you can consider adding something like the following to your /etc/rc.local file on your device(s):
...
# AQL Tweaks
aql_txq_limit=2500
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done
...
If you do test, some before and after buffer bloat results would be most interesting. Thanks!
I'm hopeful
@dtaht
will be interested in joining in here, as well.
Soapbox moment... it's generally believed that "fast" WiFi means "high bandwidth". Every wireless device maker proves this by advertising fancy model names with BIG numbers (e.g. AX3200 or AX11000) that people will think are impressive. Yet, how many of them publish latency reduction (AQL, BQL, Airtime Fairness, etc.) figures?
The majority of consumers don't realize that the "fast" they feel is more a product of lower latency than higher bandwidth. That's my ultimate hope of this thread, and the numerous other threads like this one. Just want to help people FEEL the difference for themselves and start demanding better of manufacturers.

10

[Assistant]
Inaugural Crusader post!
Crusader run to test my MT6000 AP from my 2021 MacBook Pro M1:
AQL (aql_txq_limit): 2500

1

Hi. This looks like a test over an 80 MHz channel. What happens if you set up a 160 MHz channel?
Last time one of my friends tried this with a MacBook Pro (M2 Max 16 inch 32G / 1T) with his Mercusys MR90X, this was the result:
man I discovered the hard way that the MacBook Pro does not support 160 MHz over 5 ghz
I was getting absolutely terrible internet (not speed-wise), the voices in the video chat were breaking every now and then
You have a different AP and a different MacBook, that's why the question on whether they can form a viable 160 MHz setup.

2 Replies

Unfortunately I'm not going to be able to test this at this point. My M1 MacBook Pro only supports 80 Mhz channels:
From https://support.apple.com/en-tj/guide/deployment/dep268652e6c/web:
Wi-Fi specification details for MacBook Pro models
Wi-Fi specifications for the following MacBook Pro models are detailed in the table below.
MacBook Pro 16-inch, M2, 2023
MacBook Pro 14-inch, M2, 2023
802.11 standard, name, frequency Maximum PHY data rate Maximum channel bandwidth Maximum MCS index Maximum spatial streams / Type
ax@6 GHz 2400 Mbps 160 MHz 11 (HE) 2/MIMO
ax@5 GHz 1200 Mbps 80 MHz 11 (HE) 2/MIMO
ac@5 GHz 866 Mbps 80 MHz 9 (VHT) 2/MIMO
a/n@5 GHz 300 Mbps 40 MHz 15 (HT) 2/MIMO
ax@2.4 GHz 195 Mbps 20 MHz 9 (HE) 2/MIMO
b/g/n@2.4 GHz 144 Mbps 20 MHz 15 (HT) 2/MIMO
Wi-Fi specifications for the following MacBook Pro models are detailed in the table below.
MacBook Pro (13-inch, M2, 2022)
MacBook Pro (14-inch, 2021)
MacBook Pro (16-inch, 2021)
MacBook Pro (13-inch, M1, 2020)
802.11 standard, name, frequency Maximum PHY data rate Maximum channel bandwidth Maximum MCS index Maximum spatial streams / Type
ax@5 GHz 1200 Mbps 80 MHz 11 (HE) 2/MIMO
ac@5 GHz 866 Mbps 80 MHz 9 (VHT) 2/MIMO
a/n@5 GHz 300 Mbps 40 MHz 15 (HT) 2/MIMO
ax@2.4 GHz 195 Mbps 20 MHz 9 (HE) 2/MIMO
b/g/n@2.4 GHz 144 Mbps 20 MHz 15 (HT) 2/MIMO
I would love if someone with an M2 or higher Mac could give this test a try with the MT6000!


[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: Mini tutorial for DSA network config

Update from 2021-05-31:
Option ifname was renamed to device
This tutorial is valid for 21.02-rc2 (or newer) and recent snapshots
Introduction
DSA stands for Distributed Switch Architecture and is Linux kernel subsystem for network switches. It's an upstream replacement for OpenWrt's swconfig framework and many new routers use DSA drivers instead of swconfig drivers.
In DSA each switch port is a separated Linux interface. It means ip / ifconfig command will show interfaces like lan1, lan2, wan, etc.
DSA switch ports can be used as standalone interfaces (common solution for WAN) or can be bridged using Linux bridge interface. In the later case switch will still be able to route traffic on the hardware level so it won't affect performance.
Each port can be part of maximum of one bridge only.
Simple ports bridging
In the simplest scenario switch ports are simply bridged using Linux bridge interface and OpenWrt configures that interface with an IP protocol.
In such case all devices connected to bridged ports can communicate each other and router itself.
Example:
config device
 option name 'br-lan'
 option type 'bridge'
 list ports 'lan1'
 list ports 'lan2'
 list ports 'lan3'
 list ports 'lan4'
config interface 'lan'
 option device 'br-lan'
 option proto 'static'
 option ipaddr '192.168.1.1'
 option netmask '255.255.255.0'
Multiple networks (using bridges)
A switch can be setup to group selected ports into separated networks by using multiple bridge interfaces. With separated firewall zones devices connected to different port groups won't be able to communicate each other.
Example:
config device
 option name 'br-home'
 option type 'bridge'
 list ports 'lan1'
 list ports 'lan2'

config device
 option name 'office'
 option type 'bridge'
 list ports 'lan3'
 list ports 'lan4'
config interface 'home'
 option device 'br-home'
 option proto 'static'
 option ipaddr '192.168.1.1'
 option netmask '255.255.255.0'

config interface 'office'
 option device 'office'
 option proto 'static'
 option ipaddr '192.168.13.1'
 option netmask '255.255.255.0'
Multiple networks (using VLANs)
Ports can also be separated (grouped) using single bridge with multiple VLANs. That requires assigning interfaces to correct software VLANs.
Example:
config device
 option name 'br-lan'
 option type 'bridge'
 list ports 'lan1'
 list ports 'lan2'
 list ports 'lan3'
 list ports 'lan4'

config bridge-vlan
 option device 'br-lan'
 option vlan '1'
 list ports 'lan1'
 list ports 'lan2'

config bridge-vlan
 option device 'br-lan'
 option vlan '2'
 list ports 'lan3'
 list ports 'lan4'
config interface 'home'
 option device 'br-lan.1'
 option proto 'static'
 option ipaddr '192.168.1.1'
 option netmask '255.255.255.0'

config interface 'office'
 option device 'br-lan.2'
 option proto 'static'
 option ipaddr '192.168.13.1'
 option netmask '255.255.255.0'
VLAN tagged traffic
With proper bridge VLAN configuration it's also possible for selected port to use VLAN tagged traffic. It also requires assigning OpenWrt interface to the correct software VLAN.
Example:
Port lan4 uses tagged packets for VLAN 1 and has PVID 2.
config device
 option name 'br-lan'
 option type 'bridge'
 list ports 'lan1'
 list ports 'lan2'
 list ports 'lan3'
 list ports 'lan4'

config bridge-vlan
 option device 'br-lan'
 option vlan '1'
 list ports 'lan1'
 list ports 'lan2'
 list ports 'lan3'
 list ports 'lan4:t'

config bridge-vlan
 option device 'br-lan'
 option vlan '2'
 list ports 'lan4:u*'
config interface 'lan'
 option device 'br-lan.1'
 option proto 'static'
 option ipaddr '192.168.1.1'
 option netmask '255.255.255.0'

70

[Assistant]
Outstanding guide, thanks,
@rmilecki
! Like I said on IRC, the only thing missing is how to specify a PVID. Add that, and it will be perfect!

5

Excelent Guide. Thanks for taking the time to share this with us non-developers. It makes everything much, much clearer.

1

Would be well worth including it in the wiki!

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: [HOWTO] Installing OpenWrt on Cyberoam CR15(w)iNG and CR25(w)iNG

Recently, I did several OpenWrt installs on Cyberoam CR15wiNG and CR25wiNG devices, so I thought I'd publish my notes here. Both of these models include wireless networking. Both have matching wired-only sister models, CR15iNG and CR25iNG respectively, so I expect the installation process for those should be nearly identical, but shorter (no need to configure wireless networking).
This HOWTO is intended for the relatively new users who have some experience with general computing and system administration but are not (yet) comfortable with flashing firmware and need some friendly handholding to get through the process.
I am deeply grateful to
@frollic
, whose informative post was the starting point for this little project.
Introduction
Cyberoam is an Indian network security company that was acquired by Sophos in 2014. The CR15wiNG and CR25wiNG models are implemented in a desktop form factor with three wireless antennas:
The image above shows the back panel of a CR25wiNG unit; note four Ethernet ports, the leftmost of which is almost entirely obscured by the middle antenna. The CR15wiNG is visually similar but has only three Ethernet ports.
Under the hood, my CR15wiNG was running an AMD G-T24L processor with 2 GB of RAM and a 4 GB Compact Flash (CF) card as the sole storage device. The CR25wiNG had an AMD G-T30L processor, also with 2 GB of RAM. The storage situation was a little different: a 2 GB CF card complemented by a 320 GB HGST hard drive. Both models came equipped with Intel 82583V Gigabit Ethernet controllers and Qualcomm Atheros AR93xx wireless network cards.
Note
Both processors are 64-bit, so we will need a 64-bit OpenWrt image for installation on either model.
Power-wise, both models came with 12V / 5A power supply units featuring 5.5-mm barrel plugs.
In terms of management interface, we are not exactly spoiled with choices. There are no video outputs, but there is a single RJ-45 console socket, so that's what we're going to use. Note that the connection speed needed to access BIOS is 9600 bits per second (bps), while OpenWrt by default operates at 115200 bps, so choose your connection speed depending on what you want to accomplish with the connection. BIOS access keys are F2 and Delete; in my experience, F2 generally worked better.
Installation Options and Plan of Work
For sheer repeatability (as well as for sheer laziness — no desire to open up the cases), I decided to install OpenWrt on CF cards on both models. Another possibility was to remove the CF card from the CR25wiNG and install OpenWrt on the hard drive. Yet another possibility was to still remove the CF card from the CR25wiNG, but replace the hard drive with a SATA SSD and install OpenWrt on that SSD. In terms of installation actions this really doesn't matter. You need some kind of boot drive; exactly what kind is a secondary consideration.
Next, I had to decide if I wanted to take the CF cards out of their respective devices and write OpenWrt onto them directly or boot the devices from a USB stick and copy OpenWrt onto the CF cards from there. I chose the latter (again, I just didn't feel like taking the devices apart and cleaning up the sticky residue of the warranty seals).
So here's the plan of work I came up with:
Write an OpenWrt image onto a USB stick
Boot the device from that USB stick
Install OpenWtr onto the device's CF card
Set up wireless networking (on x86, it may or may not work out of the box), and finally,
Make the entire CF card accessible to OpenWrt (more on that later)
Preparations
To follow along, you will need (in addition to an operational CR something or other):
A computer with console connection software (I used a Linux machine with the screen utility, but Putty, whether on Linux or Windows, will work just as well)
A console cable (I used the kind that connects the RJ-45 port on the router to a USB port on the administrator's computer)
An Internet connection
A pair of Ethernet cables. one to connect the CR to an upstream device, another to connect a client device to the CR when the time comes
Obtainig OpenWrt
Go to the OpenWrt downloads site:
https://downloads.openwrt.org/
Near the top of the page, there's a section titled Stable Release. Click on the version number (as of this writing, 22.03.2). This will take you to a list of "targets" (various systems for which OpenWrt is available). Scroll to the end of the page and click on x86. On the page that opens, click on 64; this will take you to the downloads for 64-bit PCs and derivatives.
Generally speaking, there are four installation images to choose from (there are others, but they are made for some very specific situations, and we're not in one of them). You can choose a BIOS or UEFI image with either ext4 or SquashFS file system on the root partition. Given the age of the devices, I thought BIOS would be a safer choice. As for the file system, I am slightly biased in favor of SquashFS for no particular reason. So I chose the generic-squashfs-combined.img.gz image, downloaded it, and created a bootable USB stick from it using Rufus on a Windows machine. Needless to say, there is plenty of other software that does exactly that, so you have options.
First Boot
On a CR15 device, there are three Ethernet ports labeled LAN/A, WAN/B, and DMZ/C. CR25 has them as well; its fourth port is labeled simply D.
Generally, on the first run, OpenWrt designates the first port it can find as the WAN port. In our case, this would mean that OpenWrt would designate as WAN the port that is labeled LAN, which is confusing. However, in this install, OpenWrt was able to fiigure out which port is WAN with no prodding from me. I don't know whether this was a happy accident or had something to do with the fact that I had the router cabled up for Internet access during installation.
So here's my setup before the first boot:
The CR is off
The WAN/B port of the CR is connected to an upstream device providing Internet connectivity and DHCP service
The console port is connected to a USB port on the administrator's computer
The bootable USB stick is inserted into the USB port on the CR
First, we should initiate the console connection. In my case, this was done by starting the screen utility:
sudo screen /dev/ttyUSB0 115200
Note the sudo part; screen requires root-level access to hardware, so it always wants to run as root. Note also that 115200 is the connection speed; if you need a different speed (say, 9600), use that number instead.
When connection starts, the terminal screen goes blank. At this point, turn on the CR, and you should see some output. If you see large amounts of garbage output or legible output that's clearly not OpenWrt, this means that your device is booting from a device other than the USB stick. If that happens, turn off the device, end your screen session (press Ctrl-a, then k, then y), start a new screen session at 9600 bps, turn the device back on and immediately start pressing F2. This will get you into BIOS, where you can change the order of boot devices, so that the first boot device is USB. In my case, however, this wasn't necessary; OpenWrt booted from the USB stick with no additional prodding.
If all goes well, you will eventually see this message among others:
Please press Enter to activate this console.
When you see if, do as requested. You will be shown the OpenWrt logo and taken to the command line:
BusyBox v1.35.0 (2022-10-31 22:44:41 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 22.03.2, r19803-9a599fee93
 -----------------------------------------------------
root@OpenWrt:/#
OpenWrt may continue the start-up process (and spew messages) even after you get to the command line, so give it a moment to finish what it's doing. At this point, the CR should be able to connect to the upstream device and thus the Internet. Test it out:
ping -c 3 google.com
You should see the familiar output of ping.
Now we should install OpenWrt onto the CF card. Here's the problem though: we don't know its system name. So let's find out. For that, we will need a utility called lsblk, which we don't have right now. But, since we're connected to the Internet, we can get it easily. Run this command from the command line:
opkg update && opkg install lsblk
Technically, this is two commands rolled into one: opkg update asks opkg, the OpenWrt package manager, to go online and retrieve a list of packages available for installation, while opkg install lsblk actually installs the package lsblk. If we tried the second without the first, opkg wouldn't be able to install anything; it wouldn't know where to get the package identified only by its name.
Now let's inspect our system:
lsblk
On a CR15, the CF card will be reported as sda and the USB stick as sdb. On a CR25 with the hard drive present, the CF card will be reported as sda, the hard drive, as sdb, and the USB stick. as sdc. You should be able to tell which is which by simply looking at the drive sizes.
Now we need to install OpenWrt onto the CF card. First, let's go to an out-of-the-way place where we can store some temporary files:
cd /tmp
Next, let's download OpenWrt (it can be the same image file you downloaded for writing onto the USB stick earlier or a different one; say, you changed your mind and decided to try an ext4 image rather that a squashfs image). Right, now, with 22.03.2 being the current release and assuming we still like squashfs, we would do:
wget https://downloads.openwrt.org/releases/22.03.2/targets/x86/64/openwrt-22.03.2-x86-64-generic-squashfs-combined.img.gz
Now let's unzip the downloaded file:
gunzip openwrt-*.img.gz
For quality control, run ls and make sure a file named openwrt-22.03.2-x86-64-generic-squashfs-combined.img (note the .img, rather than .img.gz, ending) is present in your /tmp directory.
Now we can write OpenWrt onto the CF card:
dd if=openwrt-22.03.2-x86-64-generic-squashfs-combined.img bs=1M of=/dev/sda
Essentially, this means "take this image file and write its contents in one-megabyte chunks onto the /dev/sda drive".
Now our CF card should be ready to serve as a boot drive. Stop the device:
halt
Wait until you see the message:
reboot: Power down
When you see this message, use the switch on the back of the CR to turn it off. Then, remove the USB stick from the CR.
Second Boot
Use the switch on the back of the CR to turn it on again. Once again, watch for the Please press Enter to activate this console message and do as requested.
Now that you're back on the command line, you may want to send another ping to the outside world to ensure you have connectivity. Speaking of connectivity, your connectivity right now is impaired. Your wired connections work, but your wireless card is not even being detected by OpenWrt. To remedy this, we will need a few extra packages. Which ones? Depends on what our Wi-Fi card is. To find out what we have, we can use a utility called lspci. But we don't have it, so let's install it; it is a part of the pciutils package. And once again, since we haven't run opkg since reboot, we will need to let opkg download the inventory before downloading anything:
opkg update && opkg install pciutils
Now we can see what components we have on our unit:
lspci -nn
Here's the relevant line in the lspci output:
07:00.0 Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01)
The fastest way to figure out what we need is to pay a quick visit to Hardware for Linux:
https://linux-hardware.org/index.php?id=pci:168c-0030
Note the ending of the URL; it is the same as the PCI identifier of our wireless card (168c:0030), except the colon has been replaced with a dash.
Hardware for Linux tells us that this card has a Linux driver, and that driver is found at the following location in the Linux source code:
drivers/net/wireless/ath/ath9k/pci.c
The part that's important for us here is ath9k. In OpenWrt, drivers for PCI devices are supplied as kernel modules. A kernel module looks like a package whose name starts with kmod-. So we can simply Google kmod-ath9k, and sure enough, this package exists and provides support for the Atheros wireless cards.
Prior experience tells me that an Atheros card will also require the hostapd package.
Now let's get our wireless networking going:
opkg install hostapd kmod-ath9k
After the packages are installed, you will see some additional activity on the console. There will be messages indicating that a wireless port (wlan0) is available, has been bridged to the LAN, etc. Simply put, good news all around.
Once this is done, let's set the root password for out device. Type passwd, press Enter, and follow the prompts. (In case you're wondering, you could have done this before or after; you can do it any time after you boot from the CF card.)
Now we need to configure the wireless networking. Connect to any of the LAN ports on the CR with an Ethernet cable, open your Web browser, and point it to https://192.168.1.1 (this is the default OpenWrt location). Enter your new password when prompted, then go to Network >> Wireless. On the Wireless screen, click the Edit button. A complicated-looking Device Configuration dialog will open. At the very least, you should do the following:
Under Advanced Settings on top of the dialog, use the Country Code selector to choose the country you're in. This will tell the router which radio frequencies it is permitted to use (those are regulated to prevent interference with broadcasting, emergency services, and other uses of radio).
Down the dialog, under General Setup make sure that (1) Mode is set to Access Point, (2) you set ESSID (wireless network name) to something you like, and (3) the Network is set to lan (this will make sure that all your client devices, wired and wireless, will be on the same local network).
Also down the dialog, under Wireless Security, set Encryption to something secure (I chose WPA2-PSK) and enter the key (network password) under Key. Obviously, if you have a good knowledge of wireless security, you can choose other encryption and authentication options; I am just providing a minimal set of directions here...
When all of this is done, click Save at the bottom of the dialog. The dialog will close, and you will be back to the Wireless Overview. Click Save & Apply on the bottom of the screen and wait for the changes to be made (there will be a pop-up dialog informing you of what's going on). Next, take a look at the button to the left of Edit. Most likely, it says Enable. If so, click it to enable wireless networking. If it says Disable, leave it be; you probably clicked on it before, so wireless is enabled now.
At this point, your device should be fully operational. Just in case, reboot the device to verify that everything that should start at boot actually starts.
Expanding the Root Partition
Your device is working, and you absolutely can use it as is. However, right now, only about 120 megabytes of your disk space is usable. This is plenty for OpenWrt, but if you want, you can still make your entire CF card accessible. This is done by expanding the root partition. You may want to check out the official OpenWrt on x86 Hardware page to see if it has a more recent guidance compared to this post:
https://openwrt.org/docs/guide-user/installation/openwrt_x86
In short, the process of expanding the root partition depends on whether you have a BIOS system or UEFI system. as well as on whether your root partition is ext4 or SquashFS. We have a BIOS system with a SquashFS root partition, so here's what we need to do.
A. Get the Supplies
We will need a small collection of utilities. Some of them we may have already, but opkg is smart enough to figure that out. so let's ask for everything we need:
opkg update && opkg install fdisk losetup resize2fs
B. Expand the Root Partition
We will resize the root partition using the fdisk utility. The listing below shows the whole fdisk session I ran interactively (I am copying it from an earlier post of mine, where the target drive was a 64 GB SSD; the process is identical to what you will see in the case of a CF card, a hard drive, or any other data storage device). The manual inputs are shown [[in double square brackets]]; the [[]] sequence indicates pressing Enter with no visible input. 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:~#
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 output in response to the p command.
To verify that the changes have taken place, you can run fdisk /dev/sda again and execute another p command to display partitions followed by a q command to quit. Alternatively, you can do fdisk -l; this will not enter the interactive mode, you'll just get the output, and then fdisk will exit.
C. Resize the File System
In my experience, you should start this stage by rebooting the system (run reboot from the command line). If you do the steps below without rebooting, OpenWrt may refuse to resize the file system (it looks like some of the changes we made in the previous step need a reboot to set in). So here are the steps:
BOOT="$(sed -n -e "\|\s/boot\s.*$|{s///p;q}" /etc/mtab)"
DISK="${BOOT%%[0-9]*}"
PART="$((${BOOT##*[^0-9]}+1))"
ROOT="${DISK}${PART}"
LOOP="$(losetup -n -l | sed -n -e "\|\s.*\s${ROOT#/dev}\s.*$|{s///p;q}")"
resize2fs -f ${LOOP}
reboot
After the device reboots, you should be able to use the entire disk.
A Future Project?
As noted above, the CR25 comes with a 320 GB hard drive. In home installations, it would be tempting to use this hard drive as a file storage location. OpenWrt allows deployment of Samba, as well as some lightweight alternatives. So it's entirely possible to configure a hybrid device pulling double duty as a network appliance and a file server. Probably not the best idea for a business, but for a home, why not?

2 Replies
12

[Assistant]
great work - how about adding it to the wiki ?
https://forum.openwrt.org/t/applying-for-openwrt-wiki-account/101671/240

Tbh, it's not any different than the other x86 devices.
Great write up, never the less, and thnx for posting the hw details for the 15 and W models,
@NC1
.

1 Reply

NC1:
Note the sudo part; screen requires root-level access to hardware
Linux desktop OS typically enumerates ttyUSB ports with owner root and group dialout. Check with ls -l /dev/ttyUSB* If you add your non-root user account to the dialout group (which for some reason Ubuntu doesn't do by default), you can then access a ttyUSB without using sudo.
On Linux, as easy way to write the OpenWrt image to a USB stick is:
sudo -s
gzip -cd filename.gz | dd of=/dev/sdX bs=4M
This does require sudo since writing directly to the wrong block device will do a lot of damage. Be absolutely sure of the drive letter X being the USB stick and not one of your internal drives.
After the write is complete (use sync to wait until all data is on the drive not in the RAM cache) unplug/replug the drive so the new filesystem mounts, and copy the distribution image gzip to the boot partition. You can use that to install on the target machine's internal drive without downloading 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: X86 Router build example for just 100 USD

Complete x86-64 router for 109 USD
Hi just wanted to share My OpenWrt experience, it's not a real guide or something. just my way to do it.
Hardware:
CPU: Intel Pentium G3460
Most arguable thing, full 1Gbit speed load this CPU for 22% with adblock and OpenVPN.
You can buy an celeron, but what's the reason? Saving 5 USD not worth it. You can buy 4 core 8 threads xeon
but for what, even pentium will enough, xeon will be just a waste of money and power.
Conclusion for CPU:
a) Modern 2012-2020 year release
b) 2-4 Cores
c) 1.1 - 3 GHz clock.
d) Less TDP you can find. (intel use T letter for small TDP CPU's)
Price: USED - 600 RUB = 8,2 USD
Motherboard: ASUS P9D/C-4L
It have 4 intel integrated intel NIC's so i don't need switch.
You need motherboard with at least 2 NIC (LAN-WAN) if you want go without additional cards.
Also i strongly recommend use server class motherboards like intel S1200 or asus P9/P10/P11 because
it's not a pc, router will work 24/7 and it should be reliable.
Price: USED - 2500 RUB = 34 USD
PSU: DELL 265W
The power draw not much, buy any 130-250W PSU you can find, cheapest with PFC (!IMPORTANT), just make sure it's not noisy
You can also buy an 80+ certificate PSU, it will cost more but will save a little bit of energy.
Note: The PFC, is the thing what changes old and diying PSU's and modern.
Price: USED - 350 RUB = 4,7 USD
RAM: 4x1GB (4GB) DDR3 1333 ECC RAM Hynix (hmt112u7tfr8c-h9 to ab-c)
For what 4GB? Why not, price gap between 1GB and 4GB is 2 USD. If you want save extra money
buy 2x1GB sticks, it will be greater than enough.
Price: USED - 400 RUB = 5,4 USD
ROM: 16GB Sandisk + 1TB Seagate HDD.
Cheapest USB stick you can buy in your local store. I do not recommend you buy complete trash on Ali.
There is no difference between SSD or USB stick, at least i didn't noticed.
HDD you need depend on - would you use your router as a file storage.
Note: HDD make noise, but you can command it to turn off spin after 20 min.
Price: NEW - 280 RUB = 3,8 USD + USED - 1500 RUB = 20,5 USD
Fan: Cooler Master Standard I50 PWM RH-I50-20PK-R1
STRONGLY recommend buy most silent cooler you can afford, it will work 24/7, some server motherboard can't PWM fan,
buy lowest speed, or buy fan resistor. Also buy only new, not used fan.
Note: New ones contain thermal grease, and fan itself always works quieter when not worn out.
Price: NEW - 485 RUB = 6,6 USD
Additional NIC: Intel CT gigabit adapter EXPI9301CTBLK
Buy only Intel adapters, it will almost guaranty flawless work, compatibility.
If you want save money, buy adapter from Ali, they work the same as original.
Price: USED - 400 RUB = 5,4 USD
PC Case: Old and rusty InWin i found on trash can.
If you want hide it, buy cheapest case you can find, ask friend for free one, if you have some extra money,
buy an some stylish case glass case and when you get guests tell them - check this router!
Price: -
Wireless: Tp-Link Archer C9
You can buy AP, you can buy internal wireless card, you can buy router and use it AS router to gain
additional Lan ports, you can even not use WiFi. All depends on your house/apartment size.
Price: USED - 1500 RUB = 20,5 USD
Overall: 109 USD
Note: I live in Russia, the prices in countries like USA or EU will be less
due to much more wide market and much more supply.
Minor:
I also using a dedicated small 17'' monitor as a terminal output, i got it for free,
using it with a VGA->RJ45 connector from Ali.
Why do someone need's to build something like that?
1. Fully listed adblock, wich will block the all AD. comes through Lan, and WiFi. Only x86 can handle XL adblocking list.
2. Samba shared HDD for my wife, she just connected iphone to router and upload her photos to it due to small 128GB phone.
Note: samba is not safe, you doing it at your risk, at least people at this forum talk like that, i never had a troubles.
3. Full 1Gbit speed, if your ISP provides 10Gbit you can install 10Gbit NIC, you can make 10Gbit switch. If your ISP use GPON
you can buy an GPON SFP and not rely on modem.
4. Small ping in CS:GO, with linux kernel 5.4 and modern hardware i always have the less ping than my friends who live same building
and use ISP routers like same Archer C9. QoS here works well, even when my wife goes full speed torrent, my ping doesn't become high.
5. Building something like that is FUN!
Some pictures:
Cooler:

CPU, RAM, Motherboard:

PSU:
[Album] imgur.com
Overall:
[Album] imgur.com
Archer c9
[Album] imgur.com
Note: If you afraid high electicity bills, don't. Modern CPU and motherboards are really power efficient.

2 Replies
11

[Assistant]
Sentenzo:
Note: If you afraid high electicity bills, don't. Modern CPU and motherboards are really power efficient.
I would argue this is relative ;- ) Have you measured?
Sentenzo:
The PFC, is the thing what changes old and diying PSU's and modern.
Also very old PSUs (mostly!?) have PFC, but it is realised with bulky coil / transformer

Yes, about less 5 usd month difference at least in Russia. Same as i would use 100W old lamp instead of LED one. Also i have my table personal .. some kind a safety electricity point.
1.3 A - all my stuff + PC with i9-9900k + RX 580. Only X86 router use 0.1 A, but i guess it just can't show less than 0.1 Measure. So i can call it more or less accurate!
Note is: 5 usd i can't even count it was a router, maybe my wife washed out my pants twice not once in a month, or winter was cold and we boiled 2800W teapot 5-7 times a day...yeah.
Again, power draw at least in Russia prices i would call it not valuable.
[Album] imgur.com

1

You are right, the measument uncertainty of the instrument is too high for such a little load.
In my experience different PSUs can make quite a difference about 5-10W for itself at low load.
Russian cold would kill me ;- )


[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: Guide to set up DMZ via LUCI

Hello everyone....many times community helps me....so it's time help others.Configuration for DMZ zone with out need of CLI at all.
A DMZ (demilitarized zone) is a method for separating untrusted traffic from a trusted network. One of the most common implementations of this would be for supporting a publicly accessible server (such as web) on a local internet connection or your gaming console (Xbox,PS4). The server sits in the DMZ and can be accessed from the Internet, but it cannot access the trusted network.
Physical devices
My router has these physical interfaces:
eth0 (WAN)
eth1 (LAN)
wlan0 (wireless card)
The eth0 device maps to the physical WAN port on the back of the router. It’s important to note that the physical interfaces may differ from router to router, depending on the chipsets.
The Switch
The switch (eth1) includes a number of ports, including the four physical ones on the back of the router,
The switch supports VLANs (virtual LANs), and by default OpenWRT puts all of those ports into VLAN 1. This means that physical connections in those four ports at the back are on the same virtual switch and are able to communicate with each other. You can imagine that if I changed the VLAN of one of those ports to VLAN 10, that the device plugged into that port would no-longer be able to communicate with other devices on the switch. This is the basis for our DMZ.
That VLAN 1 actually creates a new interface on the router:
eth1.1 (VLAN 1)
The configuration of the switch (including the mapping of ports to VLANs) is available under the switch menu, Network -> Switch
Note: The port numbers on the switch in OpenWRT do not necessarily map in the right direction to the back of the router.
Creating a new VLAN
The first thing we want to do is create VLAN 10 and then assign one of the ports to that VLAN, removing it from VLAN 1.
Browse to Network -> Switch
Click Add to make a new VLAN entry
Set this new entry’s VLAN ID to 10
If your set up in Wan is DHCP set VLAN as this picture....
If your set up in WAN is PPPoE like mine set up VLAN as this picture...
As you can see i remove LAN1 from current LAN interface (off)...
In VLAN 10 (DMZ) i set LAN1 untagged and attach it LAN eth1 (tagged) as separate network.
Note: Setting VLAN to untagged tells the switch to add the appropriate VLAN tag to each ethernet frame as the traffic exits that port. The setting tagged means that the switch should expect that traffic leaving the port has already been tagged, perhaps by the operating system running on the device which is attached to the port.
LAN 1 (port 1 on the back of the router) is now in VLAN 10, while the remaining three ports are in VLAN 1 and so it is now isolated from the others. The CPU (eth1) is also in VLAN 10, else we would not be able to pass any traffic to LAN 1.
That new VLAN 10 creates a new interface on the router:
eth1.10 (VLAN 10)
Interfaces
In OpenWRT you create virtual network interfaces which map to physical devices on the router. These are available under the Network -> Interfaces menu.
For example, my router has:
LAN (for my internal local area network)
WAN (for the external Internet connection)
One or more physical devices are attached to these zones, for example in my case:
LAN (bridges VLAN 1 eth1.1 and wlan0 together)
WAN (eth0.2)
The LAN bridge creates a new interface on the router:
br-lan (bridged LAN)
Creating a new interface
Once we have created our new VLAN, we want to create a new interface for the DMZ. In the same way that the VLAN 1 device, eth1, is attached to the LAN interface, we will attach VLAN 10 device, eth1.10, to our new DMZ interface.
Browse to Network -> Interfaces
Click Add New Interface to make a new DMZ zone
Set the name of the new interface to DMZ
Leave the protocol of the new interface to static
Ensure bridge over multiple interfaces remains unchecked
For the interface, select only VLAN Interface: “eth1.10”
Click Submit
You should be presented with a new configuration screen for this interface.
Set IPv4 address to something in a new range different to LAN, e.g. if your LAN is 192.168.1.1 then set DMZ to 192.168.0.1
Set IPv4 netmask to 255.255.255.0 if you want different type of network see the following picture as an example.
Leave the rest of the settings blank, you do not need to set routes, or IPv6 if you don’t want to.
Click on the Advanced Settings tab
Ensure Bring up on boot is ticked
If you don’t want IPv6, untick Use builtin IPv6-management
Click on the Physical Settings tab, should already be set to eth1.10
Click on the Firewall Settings tab
Under Create / Assign firewall-zone select unspecified -or- create and type dmz
Click Save and Apply
(I have already done...but look in columm "create"...here write "dmz".)
If you want to run DHCP on your DMZ, then under DHCP Server click Setup DHCP Server button, leave default settings
We now have a new interface or zone called for the DMZ that’s set to use out DMZ VLAN. It has a new firewall policy assigned to it, dmz, which we now need to configure.
Firewall
Now we need to configure the firewall to do a few things:
Allow the DMZ to talk to the WAN zone, so that devices can access the Internet.
Allow the LAN zone to talk to the DMZ, but not the other way around.
Let’s do zone settings first.
Browse to Network -> Firewall
Under the Zones section on General Settings page, edit the dmz zone.
Leave the name set to dmz.
Set input to accept, so that we accept all incoming packets by default.
Leave output as accept, although you could set this to reject by default but you’ll require specific outgoing rules as required.
Leave Masquerading and MSS clamping disabled.
Under Covered networks ensure that only dmz is selected.
.
Under the section Inter-Zone Forwarding, ensure Allow forward to destination zones is set only to WAN.
Ensure Allow forward from source zones is set only to LAN.
Click Advanced Settings tab
If you don’t want IPv6, you can set Restrict to address family to IPv4 only.
****Tick Enable logging on this zone,if you want to see what’s happening.
Now let’s do port forwards.
Click on the Port Forwards tab
Under New port forward section, give a name, such as DMZ
Set Protocol to TCP+UDP
Set External zone to WAN
Set Exteranl port to 1-65535
Set Internal zone to DMZ
Set Internal IP address to your DMZ server, e.g. 192.168.0.100
Set Internal port to 1-65535
Click Add when you’re OK.
Thanks
@lleachii
for help.
Finally, let’s finish with traffic rules.
Click on the Traffic Rules tab
Under Open ports on router, set a name like dhcp-dns
Under Protocol, select UDP
Under Port set 53
Click Add
Find your new rule in the list and click edit
Set Destination address to your router’s DMZ IP address
Repeat for DHCP port 67 UDP if you want to use router’s DHCP server, but don’t set the destination address as DHCP is broadcast.
####Checking the logs#####
If you enable log before you can monitor the firewall rules by browsing to Status -> Kernel Log .
That's all.

2 Replies
10

[Assistant]
Knomax:
Now let’s do port forwards.
How is this a "DMZ" in the "consumer/SOHO router" sense, when you're still required to open ports?
How would (let's say) a PS4 or Xbox work in this situation?
More port forwards?
Which ones?
Most gaming sites say when you cant figure it out, put the IP of the device in a DMZ...your instructions wouldn't fix their issue.
Have you worked on that?
I thought it would be suggested to make a rule sending all TCP/UDP to dmz at the bottom of your Port Forward Firewall table. I'm interested to see how/if that indeed works.
Knomax:
That new VLAN 10 creates a new interface on the router:
eth1.10 (VLAN 10)
Creating a second VLAN is quite common on OpenWrt - getting access to the devices VLAN capability is one common reason people choose to switch. Also, I think VLAN 10 is used by some ISPs to carry either the Internet or voice, so those readers would have to be mindful of that.
This is actually a good instruction sheet on how to create a second VLAN on an OpenWrt device!

1

lleachii:
I thought it would be suggested to make a rule sending all TCP/UDP to dmz at the bottom of your Port Forward Firewall table. I'm interested to see how/if that indeed works.
The same does Gargoyle...it is not a "true" DMZ...i think it is as much as possible to DMZ.
To make consoles with NAT TYPE OPEN you must portforwarding the ports.Thats i did in mine.
If you have another solution to DMZ or make this simpler...tell me.
I am just learning...i am not a "guru" in networking.
In many cases it is something like "trial and error".
If it is tottaly wrong i will delete the post if has misinformation.
Something like that?
lleachii:
That new VLAN 10 creates a new interface on the router:
eth1.10 (VLAN 10)
Creating a second VLAN is quite common on OpenWrt - getting access to the devices VLAN capability is one common reason people choose to switch. Also, I think VLAN 10 is used by some ISPs to carry either the Internet or voice, so those readers would have to be mindful of that.
I don't now about that...they can choose something else ..this is just an example.

Knomax:
If you have another solution to DMZ or make this simpler...tell me.
To be honest, I don't know. I was curious if you tested it.
But the rule I was thinking of is: IPv4 TCP/UDP 1-65535 from any host in wan to 192.168.0.x at port 1-65535 in dmz.
Specifying the IP of the host makes it a "DMZ" in the consumer/SOHO router sense.
Knomax:
..this is just an example.
I think this is an excellent example!

3 Replies


[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: Dumb AP - Associated Stations Resolver

Hi everyone,
I have created a script for myself that would populate both /etc/hosts and /etc/ethers reliably so the Associated Stations listings would always contain at least an IP and a hostname if possible.
This is what it looks like:
Requirements
To use it, it requires the package
arp-scan
to be installed. It will use pretty basic commands, which should be available on even the tiniest of devices, otherwise. The arp-scan-database is not required for this script.
How it works
It uses arp-scan to get a list of stations on your entire network, both LAN and WLAN, to fill up /etc/ethers. It then uses the contents of that file to question your (local) DNS server for hostname information using nslookup.
NOTE: If you don't have a local DNS server on your network, this script will fail to find any FQDN's on the hosts in your network by default. Not having DHCP addresses registered with the local DNS will also make it impossible to resolve anything on an IP, expect the hosts file to remain unchanged if that happens...
Install using the CLI
Copy the following into a file, save it to /root/. I would suggest a name like 'stationinfo.sh', I will be using it in this example. Type 'vi stationinfo.sh' right after logging in. All commands I give should be followed by an enter, obviously.
#!/bin/sh

if [ ! -e "/tmp/etc/ethers" ]; then
 if [ -L "/etc/ethers" ]; then
  touch /tmp/etc/ethers
 else
  mv /etc/ethers /tmp/etc/ethers
 fi
 ln -s /tmp/etc/ethers /etc/ethers
fi

if [ ! -e "/tmp/etc/hosts" ]; then
 if [ -L "/etc/hosts" ]; then
  touch /tmp/etc/hosts
 else
  mv /etc/hosts /tmp/etc/hosts
 fi
 ln -s /tmp/etc/hosts /etc/hosts
fi

# Any custom hosts need to be added here
cat > /etc/hosts <<- EOM
# NOTE: THIS HOSTS FILE WILL BE OVERWRITTEN BY $(readlink -f $0)
127.0.0.1 localhost

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

# Automatically added adresses will be added below:
EOM

LANST=$(ifstatus lan)
LANADDR=`echo "$LANST" |  jsonfilter -e '@["ipv4-address"][0].address'`
INTERFACE=`echo "$LANST" |  jsonfilter -e '@.device'`
LANNET=`ip r | grep "link\s\+src $LANIP" | awk -F ' ' '{print $1}'`
DNSSERVER=`echo "$LANST" |  jsonfilter -e '@["dns-server"][0]'`

arp-scan -q -x -I $INTERFACE $LANNET | awk -F' ' '{print $2 " " $1}' > /etc/ethers

for IPADDR in `cat /etc/ethers | awk -F' ' '{print $2}'`; do

 FQDN=`nslookup $IPADDR $DNSSERVER | grep -m 1 arpa | awk -F' ' '{print $4}'`
 if [ $FQDN != "find" ]; then
  echo "$IPADDR $FQDN" >> /etc/hosts
 fi

done
Make it executable by typing 'chmod +x stationinfo.sh'.
Now we need to make it run, every once in a while. Type 'crontab -e' in the CLI. Add the following in the editor:
*/5 * * * * /root/stationinfo.sh
This will make it run every 5 minutes.
You can change it to */15 for every 15 minutes or */30 for every 30 minutes. You can also change */5 to a simple 0, this will make it run every hour, on the hour.
It will need to run once during startup so it can create the necessary files and symlinks so it will not be wearing an unrecoverable hole in your ROM storage. Add the following in the editor after typing 'vi /etc/rc.local':
/root/stationinfo.sh
Make sure you type this above the 'exit 0' line.
The vi editor, daunting if you are not accustomed to it, is surprisingly easy to use, once you know how to. When you open a file it will open it in a 'view' mode. It will accept some commands but in general you will not be able to type or paste anything in the console. Hit the letter 'i' to put it in 'insert mode' to be able to type or paste. Hit Esc to escape to command mode again and in the command mode type ':wq!' to save and quit.
EDIT: UPDATED SCRIPT 6th of March 2023. Making use of ifstatus. Enjoy folks!

1 Reply
13

[Assistant]
I'm using cron:
arp-scan -qxlN -I br-lan | awk '{print $1}' | xargs fping -q -c1
Is there difference between your script and this code?

2 Replies
2

Depends on if and how you store this anywhere.
My script fills up /etc/ethers and /etc/hosts and with that it just works.

1

I just tried your one liner script, I see it requires another package (fping) to be installed while mine does not.
It may not be a problem for you, but I have a device with really limited space so I guess that may be the biggest difference and advantage?

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: LEDE v17.01.4 service release

The LEDE Community is proud to announce the fourth service release of stable LEDE 17.01 series.
LEDE 17.01.4 “Reboot” incorporates a fair number of fixes back ported from the development branch during the last two weeks.
Some selected highlights of the service release are:
Linux kernel updated to version 4.4.92 (from 4.4.89 in v17.01.3)
Security fixes to brcmfmac, hostapd, mac80211, toolchain/gdb and the Linux kernel
Assorted platform fixes for ar71xx, bcm53xx, ramips and x86
While this release includes fixes for the bugs in the WPA Protocol disclosed earlier this week, these fixes do not fix the problem on the client-side. You still need to update all your client devices. As some client devices might never receive an update, an optional AP-side workaround was introduced in hostapd to complicate these attacks, slowing them down. Please note that this does not fully protect you from them, especially when running older versions of wpa_supplicant vulnerable to CVE-2017-13086, which the workaround does not address. As this workaround can cause interoperability issues and reduced robustness of key negotiation, this workaround is disabled by default.
Due to the version bump of toolchain/gdb to 8.0.1, at least GCC 4.8 is now required to build LEDE.
For a detailed list of changes since 17.01.3 refer to https://lede-project.org/releases/17.01/changelog-17.01.4
For latest information about the 17.01 series, refer to the wiki at:
https://lede-project.org/releases/17.01/
To download the v17.01.4 images, navigate to:
https://downloads.lede-project.org/releases/17.01.4/
As always, a big thank you goes to all our active package maintainers,
testers, documenters and supporters.
Have fun!
The LEDE Community

1 Reply
17

[Assistant]
You can easily find the direct link to the download for your device by searching https://lede-project.org/toh/views/toh_fwdownload
Use the white fields on top of the columns to filter for your model.

3

is there a way to subscribe only to release topics and not everything in the forum ?
thanks

1 Reply

stintel:
As some client devices might never receive an update, an optional AP-side workaround was introduced in hostapd to complicate these attacks, slowing them down. Please note that this does not fully protect you from them, especially when running older versions of wpa_supplicant vulnerable to CVE-2017-13086, which the workaround does not address.
Maybe it should be noted, too, that the PeerKey vulnerability (CVE-2017-13086) has little practical impact, because most devices do not support this feature [1], as those who discovered those vulnerabilities note in their research paper [2]:
However, we did not find other devices that support PeerKey. As a result, the impact of our attack against the PeerKey handshake is rather low.
Are there any other specific attack vectors that this AP-side workaround does not address?
[1] http://lists.shmoo.com/pipermail/hostap/2015-June/032952.html
[2] https://papers.mathyvanhoef.com/ccs2017.pdf
EDIT: My comments about the PeerKey vulnerability don't apply here! CVE-2017-13086 is actually about TDLS. Sorry for the mixup.

2 Replies


[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 stable release

Hi,
The OpenWrt community is proud to announce the first stable release of
the OpenWrt 19.07 stable version series. It incorporates 3954 commits
since the previous release 18.06.0 and 85 commits since the previous
release candidate 19.07.0-rc2.
An upgrade from OpenWrt 18.06 to OpenWrt 19.07 is supported in many
cases with the help of the sysupgrade utility which will also attempt to
preserve the configuration. A configuration backup is advised
nonetheless when upgrading to OpenWrt 19.07.
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 introduces a new ath79 target and
brings support for WPA3.
Target transition from ar71xx to ath79
This release provides initial support for the new ath79 target, the
future device tree based successor of the popular ar71xx target. For
19.07, both targets are still built, but it is recommended to switch to
the ath79 target whenever possible: future releases of OpenWrt will drop
support for the ar71xx target.
Please read the known issues below before upgrading.
WPA3 support
The 19.07 release brings initial support for WPA3. However, WPA3 is not
enabled by default and requires installing specific packages: to run
WPA3 as an access point, hostapd-openssl is needed. For use as a Wi-Fi
station, you need either wpa-supplicant-openssl (station support only)
or wpad-openssl (AP + station). Due to their large size, these packages
are not installed by default, and it is impossible to install them on
devices with less than 8MB flash.
It should also be noted that many existing client devices will never
support WPA3, and that there are client devices that support WPA2 but
cannot connect to an AP configured with WPA2+WPA3 mixed mode. Please
only file bugs if you are sure the problem is not client related.
To configure your device as a WPA3 access point, see:
https://openwrt.org/docs/guide-user/network/wifi/basic#wpa_modes
Client-side rendering of the LuCI web interface
The new version of LuCI, the integrated web interface for OpenWrt,
implements client-side rendering of views. This improves performance by
offloading some work that was done on the device (Lua code) to the
client browser (Javascript code)
The LuCI ecosystem is large, and not all LuCI apps have been adapted to
this change, which may result in crashes involving cbi.lua. In that
case, install the luci-compat package.
With this step, Lua usage in LuCI is reduced and LuCI effectively comes
closer to the goals of the experimental LuCI2 without having to rewrite
everything from scratch.
Main changes in OpenWrt 19.07.0
The main changes in 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.5.0
binutils 2.31.1
Updated Linux kernel
4.14.162 for all targets
Flow offloading bugfixes
Network userland:
hostapd 2.9, dnsmasq 2.80, dropbear 2019.78
Fixes in network and wireless configuration handling
Bugfixes in DHCPv6 client and server
WPA3 configuration support
Install wpad-openssl for WPA3 support
System userland:
busybox 1.30.1
Sysupgrade support for backup and upgrade capability checks
Contains urngd, non-physical true random number generator daemon
based on timing jitter
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 target
New ath79 target that will replace the popular ar71xx target
Updates and new device support across all targets
LuCI web interface:
Client side rendering of views for improved performance
Security fixes
A full list of all changes and security fixes is available in the
detailed changelog, 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 in the
forum 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
Possible Wi-Fi issues with ath10k-based boards. If you encounter such
an issue, please file a bug report against openwrt-19.07. Please make
sure the issue is not caused by WPA3. If you are using WPA3 and run into
problems, revert to the encryption settings you used before upgrading to
19.07.
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 images, navigate to:
https://downloads.openwrt.org/releases/19.07.0/
As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.
Have fun!
The OpenWrt Community

4 Replies
41

[Assistant]
hauke:
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
What would a "full manual reinstall" entail? Using tftp with the factory.bin file?

2 Replies

austinbutler:
What would a "full manual reinstall" entail?
sysupgrade -F -n then reconfigure the device from the default settings.
Note that sysupgrade -F does not check if the file about to be flashed is the matching build for your device-- if you flash the wrong firmware it will brick.

1 Reply
2

Thank you guys! I just upgraded my Linksys WRT3200ACM from 18.06.4 to this one and got all of the add-ons back up and running in no time. I appreciate all of the time you're putting into this!

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 on Raspberry Pi 4B without USB3 Ethernet dongle

I’ve now been running OpenWRT on the raspberry Pi 4B for three weeks with a little setback during the first week. Initially, I was using a USB3 to Gigabit Ethernet adapter based on the Realtek rtl8153 chipset, using the standard 8152 kmod present in the OpenWRT kernel. My family was complaining about problems with video, so eventually I decided to do something about it. I always hated USB3 Network adapters. I use a MacBook Pro, and I noticed that the official Apple Thunderbolt-to-GigabitEthernet adapter daisy-chained with the TB3-to -TB2 adapter beats any USB-based Gigabit Ethernet adapter. USB introduces flakiness into the Gigabit Ethernet connection. Sometimes USB-based Gigabit Ethernet adapters function at the line speed of 940 Gbps but a few minutes later the throughput could be reduced by 1/3 or even by half. I’ve tried multiple devices with rtl8152, rtl8153, and rtl8156 chipsets, and they all have this problem. On the other hand, the TB-based Gigabit Ethernet adapter is a direct PCI bus to the chipset without any USB3 bus involved. Unfortunately, Apple never bothered to update their adapter from TB2 to TB3; hence, two daisy-chained adapters are required on newer Macs, as described above)
So, knowing all of that going into the OpenWRT on the Raspberry Pi4B experiment, I actually expected that a USB3 gigabit Ethernet network adapter could be problematic, and my family let me know it was actually the case.
My solution was to eliminate the USB-based Gigabit Ethernet adapter altogether. Of course, the most obvious downside to that solution is that the 2Gbps maximum theoretical bidirectional throughput of two GigabitEthernet ports used as LAN/WAN interfaces would be halved to 1 Gbps of maximum theoretical bidirectional throughput. However, curiously enough for a home environment the real-life throughput would not be halved but reduced by the amount of the bandwidth used in the upstream (from the home LAN to the Internet) direction. For asymmetric Internet connections the math is even better. For example, if your Internet bandwidth is 1Gbps down/ 40 Mbps up, then you are likely to enjoy up to 900 Mbps download speed while using just one physical interface on the Raspberry Pi 4B. Just make sure you configure SQM correctly with 900 Mbps download bandwidth and 40 Gbps upload bandwidth for a total of 940 Mbps (which is the maximum that the Raspberry Pi can push in one direction on a physical interface).
So, by eliminating the USB to Gigabit Ethernet adapter you are not losing a lot of download bandwidth but you are improving the quality of the routing system dramatically by jettisoning the flaky USB-based Ethernet controller.
So, how do you configure this? It’s really easy. All you need to do is create VLANs under the on-board Gigabit Ethernet controller (usually eth0). As an example, eth0.10 (VLAN10) is used as the WAN interface and eth0.20 (VLAN 20) is used as the LAN interface. I would also create another interface in OpenWRT, call it RECOVERY, associate it with eth0 and assign a static IP to it. This interface would be used for troubleshooting/recovery purposes allowing a direct connection with a computer without having to configure VLANs in a computer OS. That’s all! You can even make this change in /etc/config/network and then reload the network daemon: /etc/init.d/network reload.
So now that we have configured OpenWRT with two tagged VLANs and matching VLAN SVIs (LAN and WAN), we need a VLAN-aware switch to assist the Raspberry Pi in using the same physical interface for both LAN and WAN SVIs. It’s absolutely not a problem, though, because TP-link has very inexpensive 5-port and 8-port Gigabit Ethernet Easy Smart switches (they are simplified managed switches that have VLAN and some QoS capabilities). There are non-POE and POE+ versions of these switches. The non-POE 5-port Gigabit Ethernet Easy Smart switch costs $25 on Amazon. You could get a POE+ version of this switch for $60. Add a POE splitter for another $17, and you can power your Raspberry Pi from the POE+ switch and free up one outlet on your UPS. You can also buy another POE splitter for your modem to power your modem from the POE+ switch and free up another outlet on your UPS. Since I'm posting links to specific devices here, I would highly recommend the Argon Neo case for the Raspberry Pi 4B used as a router/firewall. Do not buy the version with a fan. The case passively cools the Raspberry Pi used as a router/firewall with no issues whatsoever.
Note: The other Argon case (Argon One) has a circuitry that prevents the Raspberry Pi from automatically powering up after the power is lost and then restored, so even though the Argon One is a very nice case and should be considered for the Raspberry Pi used as a desktop for sure, it is not suitable for the router/firewall use case
So, this is what you need to do on the switch:
Port 1: assign VLAN 10
Port 2: configure as 802.1q trunk
Ports 3-5 (or 3-8): assign VLAN 20
Connect your modem into switch port 1. Connect your Raspberry Pi 4B’s onboard Gigabit Ethernet controller to switch port 2. Plug your other wired devices (including your Wi-Fi AP) into ports 3-5 (or ports 3-8). If you want to further segment your network into additional VLANs, create more SVIs (interfaces) in Open WRT and assign them to eth0.X, eth0.Y, etc., where X, Y, etc. are VLAN numbers. Then, assign matching VLAN numbers to certain ports in the range 3-5 (or 3-8). If your Wi-Fi AP (or other device) that you want to connect to the switch is VLAN-capable, then configure the port on the switch to which this device is connected as 802.1q trunk but MAKE SURE that you disallow VLAN10 out of that switch port. This step will ensure that the traffic from the Internet arriving in switch port 1 on VLAN 10 can only get to switch port 2 where it will be received by the OpenWRT’s WAN interface (eth0.10) so that this traffic could not leak into your LAN bypassing the OpenWRT firewall.
If you already have a managed VLAN-aware switch, then you don’t even have to buy a TP-Link switch. As long as you have two spare ports on your managed switch, configure one of them with VLAN 10 to connect the modem, and configure the other one as 802.1q trunk for connecting the Raspberry Pi 4B. Then, configure all remaining ports for VLAN 20 (or any other VLAN ID other than VLAN10 that you configured in OpenWRT to further segment your LAN). Just make sure to disallow VLAN 10 from any existing or new 802.1q trunk port on the existing switch to preclude the Internet traffic from leaking into your LAN bypassing the OpenWRT firewall.
I hope this solution will come in handy to those who decided to use their Raspberry Pi 4B as the OpenWRT firewall.
Now that the Raspberry Pi Foundation has announced Compute Module 4 and the official IO board with a PCIe x1 port, it will be possible to use a PCIe based secondary Ethernet interface (single 1 Gbps, dual 1 Gbps, quad 1 Gbps, single 2.5 Gbps, or dual 2.4 Gbps) for the bidirectional throughput of up to 5 Gbps. But as of now, there are no cases available for CM4 mounted on the IO board, and having the naked electronic boards used as a router is not an appealing solution. So, for those with symmetric Internet connections of up to 500 Mbps or for those with asymmetric connections of up to 1 Gbps downstream, the solution I’ve proposed here should work really well. At least it’s working well for me. With the SQM configured, this is the best home firewall solution bar none. Even pfSense can’t compare because of how effective SQM is as a QOS algorithm. And I’m saying this as a network engineer with a 20+ years in the industry who has been designing QOS solutions for very large enterprises for many years.

Solved by sirizha in post #14
I’ve now been running the setup described in the first post of this thread for almost 1.5 years. This is the absolutely best internet connection I’ve ever had, and I’ve used many different devices, including Cisco enterprise gear (enterprise routers and ASAs) as well as pfSense. There is a relative…
10

[Assistant]
Nice write up.
A big caveat on the TP-Link SG108E switch is that the management server listens on all the VLANs. This is a bad design but it can be worked around if security isn't critical in your application. The important workaround is to turn off the DHCP client in the switch and set it with a static IP in your LAN range. If the DHCP client is active, there will be a race condition where it may take your single public IP from the cable modem-- which will break the network.
The Zyxel GS1200 series is at a similar price point to the TP Link and has a much better user interface. Unfortunately they don't offer one with PoE. The GS1900 series is a lot more professional. Also there is work on porting OpenWrt to certain GS1900 models.

mk24:
A big caveat on the TP-Link SG108E switch is that the management server listens on all the VLANs. This is a bad design but it can be worked around if security isn't critical in your application. The important workaround is to turn off the DHCP client in the switch and set it with a static IP in your LAN range. If the DHCP client is active, there will be a race condition where it may take your single public IP from the cable modem-- which will break the network.
Is this a problem with SG-105E switches?
I hear that if one wants to get an SG-105E, it should be hardware version 3 because some of the improvements with VLANs implemented in the latest firmware only apply to hardware version 3.
Also, a managed switch should never stay on DHCP-assigned IP address. The management IP should always be manually assigned. If the user knows enough to be able to manage a switch, the user should be able to assign a static IP to the switch. I can see that the DHCP client feature is necessary for a managed switch without a console port so that the initial IP address could be assigned by DHCP for accessing the switch initially, but as soon as the switch is accessed, the user should change the IP to a static one and turn the DHCP feature off.
In my case, I am using a Cisco enterprise switch, so my advice to get a TP-Link Easy Smart switch is based purely on the very reasonable price point. Also, this is obviously for home use (and perhaps very small business use), so there’s no need to buy expensive switches. As long as these TP-Link switches serve the purpose, they should be considered. The whole OpenWRT routing solution based on the Raspberry Pi 4B can be had for as little as $90, including the Raspberry Pi board, the case, the power supply, the switch, the SD card, and all required Ethernet cables. Or, if one goes with a POE+ switch, the total price could be a little over $145.
At these price points, I would go as far as to recommend getting two Raspberry Pi 4B boards, two power supplies (or a power supply and a POE splitter), two microSD cards, a couple extra Ethernet cables and two SG105E switches just to have cold spares to preclude any prolonged Internet outage in case one of these parts goes bad. Even at double the price (if buying spares), this is still an amazing price point for a home router/firewall solution. To provide a comparison, Ubiquiti is about to release their flagship “enterprise” UniFi UXG-Pro router/firewall for $500, which has less compute power than the Raspberry Pi 4B. And with the terrible customer service that Ubiquiti is known for, one should buy two of their devices to have a cold spare on hand.

2

Yes, USB adapters are not great but a lot of people praises that solution here....
RockPro64 + Intel PCIe NIC works great even though all my devices doesn't run OpenWrt right now


[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: Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02

Update in November 2021: The issue is finally fixed on upstream and OpenWrt master & 21.02 branches!
The forthcoming OpenWrt 21.02.2 release includes the fix by
@nbd
.
Huge thanks to
@adworacz
&
@WildByDesign
for spending weeks testing and pinpointing the issue to the 5.8 backports.
Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02
Network and Wireless Configuration
I sent a fix upstream and pushed it to my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary Please run a quick test to make sure it fixes the issue
Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02
Network and Wireless Configuration
Just got a confirmation that the fix works. I've pushed it to OpenWrt master and 21.02
Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02
Network and Wireless Configuration
It was caused by a regression in upstream kernel module (mac80211), which regressions only affected some wifi drivers. nbd specified mwlwifi and ath9k in the commit message... The patch fixes this upstream commit:
Get the OpenWrt 21.02.2 images which include the fix:
WRT3200ACM
WRT32X
Get the OpenWrt master snapshot images which include the fix:
WRT3200ACM
WRT32X
Information About the Issue
I use Linksys WRT32X as my main drive. Wireless is unstable on OpenWrt 21.02.1. Wi-Fi client does not disconnect but it won't receive/transmit any data for a minute or so. This happens regularly.
I had no issues with OpenWrt 19.07.7.

2 Replies
8

[Assistant]
Just had to make an account to say THANK YOU like a million times over. I needed this exactly I came from a DavidC build on my wrt32x and one day I decided to upgrade since its such an old build so I went to 21.02 and yea had the wireless stability issues so I went to replace the bin file for mlwifi and lost everything and it was showing generic, I HAD 2 partitions but thru all the flashing I went thru (divested and others) I ended up losing my davidc one and couldnt revert, either way this is exactly what I needed and will update you after a few days but I can tell you thru the last 20 minutes or so that ive been running it its been stable more then the other builds (would stay up for like 5 minutes or when the last person on the wifi disconnected but no new user could connect)

1

That is great to hear! I was afraid that this was an issue just for my own hardware.
I will make a pull request to get this fixed once we have enough people to confirm the issue.
@Owengerig
@dana44
I see you liked Phill’s comment. If you have the same effect on your device please reply here.

unfortunatily it seems that the older radio firmware did not work, woke up this morning with the 5ghz radio not transmitting and showing --/99db and the 2,4ghz radio showing but not transmitting anything like it was hung, looking at system log its just flooded with dhcp requests so I rebooted hoping to catch the log entry for this issue today


[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 18.06.0 release

Hi,
The OpenWrt community is proud to announce the first release of the OpenWrt 18.06 stable version series. It incorporates over 4000 commits since branching the previous LEDE 17.01 release and has been under development for well over a year.
With this release, the re-merged OpenWrt project attempts to define a baseline for future development based on the technological modernization and refined release processes done by the former LEDE project.
Some selected highlights of this release since the previous LEDE 17.01 and OpenWrt Chaos Calmer 15.05 versions are:
Linux kernel updated to version either 4.9.111 or 4.14.52, depending on the architecture
Updated toolchain:
musl libc 1.1.19
uClibc-ng 1.0.30
glibc 2.26+
gcc 7.3.0
binutils 2.29.1
Updated Linux kernel:
Kernel 4.9.111 for ar7, ar71xx, arc770, at91, brcm2708, brcm63xx, ixp4xx, lantiq, layerscape, mpc85xx, orion, rb532 and uml
Kernel 4.14.52 for apm821xx, archs38, armvirt, ath25, bcm53xx, brcm47xx, cns3xxx, gemini, imx6, ipq40xx, ipq806x, kirkwood, malta, mediatek, mvebu, mxs, octeon, octeontx, omap, oxnas, pistachio, ramips, sunxi and x86
Backported network flow offloading support for targets using the
4.14 Linux kernel
Network userland:
IPv6 related fixes in DHCPv6 client and servers
Support for user DHCPv6 client options in sent packets
DHCP forced renew support (RFC6704) in odhcpd
Firewall support for conntrack helper setup and better ipset integration
Introduced support for configuring GRE, GRE-TAP, VETH, VTI, VXLAN
CAKE v20180716 includes tc filter classification making ingress prioritisation easier
Cake & sqm-scripts updated representing state of the art mitigations for bufferbloat
Wireguard VPN v20180625 with MIPS optimisations and flow-offload compatibility
System userland:
Improvements in system upgrade procedure
Bugfixes in the process manager, system message bus, embedded webserver and the configuration management library
Platform and Driver Support
Dropped adm5120, adm8668, au1000, mcs814x, omap24xx, ppc40x, ppc44x, xburst and zynq targets
Added Spectre and Meltdown mitigations as well as microcode loading support to x86
Rebased oxnas target on top of upstream Kernel 4.14 support
Updates and new device support across all targets
Web interface:
New auto-rollback functionality to revert configuration changes when access to the router is lost
Better support for displaying virtual interfaces and low level configuration errors
Security improvements
For a detailed list of changes since 18.06.0-rc2, see https://openwrt.org/releases/18.06/changelog-18.06.0-final
For a complete list of changes since branching the previous old stable
LEDE 17.01 release refer to https://openwrt.org/releases/18.06/changelog-18.06.0
Known issues:
Support for a hardware-bug workaround needed for devices having an AT8032 ethernet phy accidentally got dropped. Hence devices with that ethernet chip may experience connectivity issues. At least ubnt-loco-m-xw and most likely other single-port ubnt devices are affected.
[fix merged, queued for 18.06.1]
Using ip4ip6 tunnel interface as a fallback interface accepting ip4-in-ip6 tunneled packets from any remote address doesn't work.
[fix merged, queued for 18.06.1]
Support for PCIe on ox820 is broken, results in missing USB3 support on Shuttle KD20
[driver needs more work]
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 LEDE 17.01.5 or using the Image Builder to pack a smaller custom image.
Some devices, such as the Netgear R6100, may lack 5GHz wireless AC support.
Investigation is ongoing and a fix is expected for 18.06.1. Affected users shall downgrade to LEDE 17.01.5 for the time being and wait for the first service release.
Devices using the mt76 wireless driver may experience stability issues on 2.4GHz
The legacy at91 and legacy ath25 (formerly “atheros”) targets failed to build due to image size constraints and are not part of the release.
A GUI bug prevents selecting and scrolling text in the system and kernel log pages. To solve, either upgrade “luci-theme-bootstrap” using opkg or switch to another theme.
[fix merged, queued for 18.06.1]
Any outstanding issues reported at https://bugs.openwrt.org/
For latest information about the 18.06 series, refer to the wiki at:
https://openwrt.org/releases/18.06/
To download the v18.06.0 images, navigate to:
https://downloads.openwrt.org/releases/18.06.0/
With the release of OpenWrt 18.06, the old OpenWrt 15.05 series is marked end of life and will not get any support any more, not even for severe security problems. LEDE 17.01 will still get some security
support for a limited time. We encourage everyone to upgrade to OpenWrt 18.06 to get the best support.
As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.
Have fun!
The OpenWrt Community

37

[Assistant]
I'm using OpenWrt/LEDE 17.01.5 on 1 of my 1900ac(s) (vlan. openvpn, openssh, dnscrypt and my custom scrips)
+1 setup
Can I use "sysupgrade -c linksys-wrt1900ac-squashfs-sysupgrade.bin" from 18.06.0?

I have the same hardware and used luci to upgrade from 17.01.3, everything seems fine, you still have to re-install all those packages though.

2

Excellent news, my sincere thanks to the team.
I loaded 18.06.00 on my TP-LINK TL-WR741ND v4 just an hour ago.
It works, 84KB remaining free after my additional 10k of startup and sched configurations are added.

2 Replies
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: Firewall4 / NFtables Tips and Tricks

Hopefully this topic can help those getting their feet wet with NFtables, and maybe even help some of the seasoned NFtables veterans out there. Basically, this is for sharing and caring! If you have a neat NFtables tip or trick that you think might benefit others, share a snippet here for the good of the community.
In the spirit of sharing, I'll drop a little snippet here that others might find beneficial to include on their WAN ingress:
...
chain inbound_wan {
        # Drop all fragments.
        ip frag-off & 0x1fff != 0 counter drop

        # Drop XMAS packets.
        tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop

        # Drop NULL packets.
        tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop

        # Drop uncommon MSS values.
        tcp flags syn tcp option maxseg size 1-535 counter drop

        # Drop RFC2827 - IETF BCP38 / Bogons / Martian Packets
        ip saddr { 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/3 } counter drop
}
...
Your turn!

Solved by _FailSafe in post #158
Hey community! I think by now this thread has run its course. Most of the replies these days should actually be raised as new, focused topics for better visibility and on-topic resolutions. Please open additional forum topics as needed for true issues with FW4 going forward. Thanks to all who dropp…
1 Reply
7

[Assistant]
_FailSafe:
        # Drop uncommon MSS values.
        tcp flags syn tcp option maxseg size 1-535 counter drop
Mmmh, keep in mind when doing that, that MSS clamping is the easiest way to confirm sqm overhead settings by running speedtests at low packet sizes. So remember to disable the nft section above during the test.

2

Here's another one to demonstrate a use of the nftables verdict map:
# Allow traffic only from established and related packets.
ct state vmap { established : accept, related : accept, invalid : drop }
This would be something you might include in your input and forward chains, for example.

1

Some good security tips here: https://blog.samuel.domains/blog/security/nftables-hardening-rules-and-good-practices


[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 18.06.4 Service Release

The OpenWrt Community is proud to announce the fourth service release of the stable OpenWrt 18.06 series.
OpenWrt 18.06.4 incorporates a number of bug fixes in the network and system userland, as well as updates to the kernel and base packages.
Note that the OpenWrt 18.06.3 release was skipped in favor to 18.06.4 due to a last minute 4.14 kernel update fixing TCP connectivity problems which were introduced with the first iteration of the Linux SACK vulnerability patches.
Important: If you upgraded any LuCI packages using opkg, ensure that the latest version of liblucihttp (dated 2019-07-05 or later) is installed prior to applying the upgrade image via the gui in order to prevent possible flash data corruption. Alternatively, flash the upgrade images using the sysupgrade command on the command line.
Some selected highlights of the service release are:
Linux kernel updated to versions 4.9.184/4.14.131 (from 4.9.152/4.14.95 in v18.06.2)
SACK security fixes for the Linux kernel
WPA3 security fixes in hostapd
Further security fixes for Curl and the kernel
MT76 wireless driver updates
Various network and system service fixes
For a detailed list of changes since 18.06.2 refer to
https://openwrt.org/releases/18.06/changelog-18.06.4
For latest information about the 18.06 series, refer to
the wiki at:
https://openwrt.org/releases/18.06/
To download the v18.06.4 images, navigate to:
https://downloads.openwrt.org/releases/18.06.4/
Have fun!
The OpenWrt Community

2 Replies
24

[Assistant]
Thanks ,will this one work for Raspberry pi B+ BCM 2837B0 ?

bawantha:
will this one work for Raspberry pi B+ BCM 2837B0?
Your question is slightly ambiguous, as there is no "Raspberry pi B+ BCM 2837B0", there is either a "Raspberry Pi 1 Model B+", based on the ARMv6 BCM2835 SOC, or a "Raspberry Pi 3 Model B+", based on -indeed- the ARMv8 BCM2837B0 SOC. In case of the later, the answer is no - the openwrt-18.06 branch isn't supposed to get new features, that includes no support for new devices (just bug fixes), master or the openwrt-19.07 branch (with 19.07.0 still pending) are for that.

2

Thanks a lot for your very good work
work well on wrt32x and wrt3200

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: Associated stations - making hostnames visible across multiple APs

Whilst researching this topic myself I found a number of threads with different solutions to the problem of making hostnames visibile across multiple access points. Unfortunately those threads are locked, so I'm creating this one to share my own (different) solution to the problem.
Most threads focus on getting an entry into the ARP table, using tools such as fping, arp-scan, etc.
My approach is somewhat different - I'm running a cron job to copy /tmp/dhcp.leases from the "primary" router (ie, device running DHCP/dnsmasq) out to the "secondary" access points.
This was the result of looking at how LuCI "assembles" its status overview.
Warning: This approach would not be suitable if your secondary APs are acting as DHCP servers!
Approach:
Create SSH keys on the primary device:
dropbearkey -t rsa -f ~/.ssh/id_dropbear
Add the generated public key to the accepted keys on the secondary access point(s) (System > Administration > SSH-Keys)
(note if you need to get the public key again, you can dump it with dropbearkey -y -f ~/.ssh/id_dropbear on the primary device)
Add cron jobs on the primary device to copy /tmp/dhcp.leases to secondary devices
*/5 * * * * scp /tmp/dhcp.leases root@<secondary device>:/tmp/dhcp.leases
etc etc
I hope someone else finds this useful. As an added benefit I can now see dhcp leases regardless of whether I log into the primary device, or any of the secondary APs.
Other threads for reference:
Associated stations list in AP, how to show host names?
Network and Wireless Configuration
Wireless Associated Stations - Hostname not shown
Network and Wireless Configuration
I'm using the following setup: Router o2 Box 6431 (Wi-Fi/VDSL-Modem/DHCP-/DNS-Server) 2 TP-Link TL-WR841N v8 (Only Wi-Fi AP) Both running 19.07.1. The 2 TP-Links are connected via cable with the main unit. When a device is connected via Wi-Fi to the main unit the hostname and IP-address are displayed in the Host section: android-df55e4111e898ea3.lan (192.168.1.157, fe80::522e:5cff:fed3:a9c3) When the same device is connected to either of the APs only the IPv6 address is displayed as hostnam…
Second device not getting DNS entries from first device to show in Associated Stations
Installing and Using OpenWrt
Check this one:
Before and after screenshots:

4 Replies
16

[Assistant]
@pkmann
Thanks so much for this guide! It is really helpful especially for someone like me who's very new to Linux and OpenWRT.
Just few notes for beginners like me:
1- The dropbearkey command gave me an error complaining about the ~/.ssh/ directly. So I have created it with: mkdir ~/.ssh/
2- Though this is super clear in the guide above and logical, but I spent some time scratching my head because the SCP copy command is not working. Turns out that I was running it on the secondary not the primary router. The syntax of the SCP command is SCP From_location To_Location
3- The cronjob did not update the file for me at first. So I tested by running the command scp /tmp/dhcp.leases root@192.168.100.130:/tmp/dhcp.leases (basically the command that the cronjob runs every 5 minutes) and THEN it asked me if I want to add the secondary router to list of trusted devices because it is the first time I SSH to it from my primary router and I entered Y and after that the cronjob started working. I'm not sure if there is an issue in my setup as I thought the key that was generated should take care of this, but at the end it worked this way. So if you have issues, run the SCP command and see if the file gets copies in the Secondary router. I used WinSCP to access it and see if the command is working.
4- This is how to add the cronjob:
a- Use Putty to SSH to the PRIMARY router
b- run the command crontab -e
c- press i to go into insert mode
d- paste the line. In my case it is: */5 * * * * scp /tmp/dhcp.leases root@192.168.100.50:/tmp/dhcp.leases
e- press escape to go into command mode
f- enter :wq to save and quit
g- run this command to apply changes: /etc/init.d/cron restart
h- run this command to verify your have added the cronjob correctly. It should show what you have pasted: crontab -l
5- The etc etc at the end of the cronjob above is probably a typo.

3 Replies
6

THX for the clear post
I followed the guide and it works fine (file is copied, and manual copy works either)
crontab file has an EOL at the end (empty line)
But one concern with my system log reporting such message looking like cron error message
Tue Nov 22 00:42:00 2022 cron.err crond[6299]:  line scp /tmp/dhcp.leases root@AP_IP:/tmp/dhcp.leases
While I dont see error in the execution what's doing wrong? true error or standard cron report?
THX for guidance
PS viewing the existing .ssh directory, just log as root (Putty or other) then "ls -a" will show the hidden files => therefore no need to create

2 Replies

What does the output of crontab -l on your device look like?
It should be something like this:
root@xxxxxx:~# crontab -l
*/1 * * * * scp /tmp/dhcp.leases root@yyyyyyy:/tmp/dhcp.leases


[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: CAKE QoS Script (OpenWrt)

This is the script that I made months ago (to self-learning) and until today I have time to share it.
Quick Overview
The script launches the CAKE qdisc (like SQM would do), and you do not need SQM at all.
The script uses the veth method on the ingress side to make the DSCP marking work and fix this problem:
With dual-dsthost enabled, a single host with many tcp sessions (like when torrenting) is prevented from hogging all the bandwidth, but if you are actually using that host, the torrent will still hog that host's bandwidth and to fix that problem you need QoS using DSCP marking, so that the torrent traffic and other such hogs goes into the "bulk class", then that host will see a big improvement in all other traffic types.
It has rules to prioritize non-bulk unmarked traffic like gaming and VoIP, that means you don't need to add game ports, but if you want you can also add game ports and static IP of game consoles to prioritize that traffic (although it is not necessary).
It has rules to give high priority to known Video conferencing, VoIP and VoWiFi ports.
Easily change the default OpenWrt settings like default qdisc, TCP congestion control and ECN.
irqbalance and Packet Steering options to equally distribute the load of packet processing over all available cores and probably increase performance.
It has Init Script so that from the LuCI web interface (System -> Startup) you can Enable, Disable, Start, Restart and Stop the script.
It has Hotplug to automatically reload the script.
Pre-requisites
To use this script, you need to install these packages:
tc-tiny
kmod-sched-cake
kmod-veth
kmod-tcp-bbr
irqbalance
htop (Optional)
Copy and paste this into your SSH client:
opkg update && opkg install tc-tiny kmod-sched-cake kmod-veth kmod-tcp-bbr irqbalance
Install
Copy and paste this into your SSH client:
rm /root/cake.sh; rm /etc/init.d/cake; rm /etc/hotplug.d/iface/99-cake; rm /etc/nftables.d/*-rules.nft; wget -O /root/cake.sh "https://raw.githubusercontent.com/Last-times/CAKE-QoS-Script-OpenWrt/main/cake.sh"; chmod 755 /root/cake.sh
The cake.sh script is located in the /root/ folder on the router and you have to edit this:
Change the CAKE settings according to your connection type and also change the other settings (like rules, ports, IP address, irqbalance, etc.).
You can delete the ports and IP address from the script, because are just examples.
Once you've finished editing the script, use this command to run the script:
./cake.sh
Or download the script to edit it with the notepad and then place the edited script into the /root/ folder on the router, then change the permissions of the script with this command chmod 755 /root/cake.sh and run the script with the command above ./cake.sh
GitHub: Download the script
GitHub
GitHub - Last-times/CAKE-QoS-Script-OpenWrt: CAKE QoS Script (OpenWrt)
CAKE QoS Script (OpenWrt). Contribute to Last-times/CAKE-QoS-Script-OpenWrt development by creating an account on GitHub.
CLI
Command to run the script:
./cake.sh
Others important commands:
# To check if the DSCP marking is working
tc -s qdisc

# To check your CAKE settings
tc qdisc | grep cake

# To check the veth devices
ip link show

# To check the nftables rules
nft list ruleset

# To check if changed the default OpenWrt settings
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_ecn

# To check if irqbalance or packet steering are enabled or disabled
uci show irqbalance.irqbalance.enabled
uci show network.globals.packet_steering
Tip
Don't use Software flow offloading, it will break the rules and CAKE.
Uninstall/Remove
Copy and paste this into your SSH client:
/etc/init.d/cake stop; rm /root/cake.sh; rm /etc/init.d/cake; rm /etc/hotplug.d/iface/99-cake; rm /etc/nftables.d/*-rules.nft; sed -i "/default_qdisc/d; /tcp_congestion_control/d; /tcp_ecn/d" /etc/sysctl.conf; uci set dhcp.odhcpd.loglevel="4"; uci set irqbalance.irqbalance.enabled="0"; uci del network.globals.packet_steering; uci commit && reload_config
DSCP Information
Differentiated Services Field Codepoints (DSCP)
RFC 8325 - Mapping Diffserv to IEEE 802.11
RFC 8325 - WiFi QoS Mappings
RFC 7561 - Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN

8

[Assistant]
They both do the same, probably you didn't set the interface properly.
I'm gonna take a look into the script to take some references with your dscp markings, thanks ^^

2

ok my interface is wan
I would like the equivalent of cake and piece of cake but I don't know how there is only diffserv4 so qosify would use layer cake?

ok but how configurate for playstation
i will do let to base ?

1