OpenWRT 21.02 to 22.03 upgrade

Here are my notes on upgrading OpenWRT, they are based on my previous post on upgrading.

In this case I’m upgrading specifically TP-Link Archer C7 v2 – the process will be similar for other OpenWRT devices but it’s always worth reviewing the device page. I’ve also got some v5 versions, and this means a slightly different firmware, but the same exact process.

For a major version upgrade it is worth reading the release notes First start by reading the release notes – nothing seems to be specific to my device that requires any special considerations, so I can just proceed.

An upgrade from OpenWrt 21.02 or 22.03 to OpenWrt 22.03.5 is supported in many cases with the help of the sysupgrade utility which will also attempt to preserve the configuration.

I personally prefer the cli based process, so we’ll be following that documentation.

Step 1. While I do nightly automated backups, I should also just do a web UI based backup – this is mostly for peace of mind

Step 2. Download the correct sysupgrade binary -the easy way to do this is by using the firmware selector tool. I recommend that you take the time to verify the sha256sum of your download, this is rarely an issue but I have experienced bad downloads and it’s hard to debug after the fact.

It is recommend to check you have enough RAM free – thankfully the archer has a lot of RAM (which is used for the /tmp filesystem too) so I have lots of space.

Step 3. Get ready to flash – if you review the post install steps, you’ll see that while the sysupgrade will preserve all of our configuration files – it won’t preserve any of the packages.

This script will print out all of the packages you’ve installed.

Save the list away so you can easily restore things post install. There is a flaw with this script as I’ll point out later, but in many cases it’ll work fine for you.

On my dumb access points I get this list of packages

Mostly I have the prometheus exporter (for metrics) and rsync (for backups) installed. My main gateway has a few more packages (vnstat and sqm) but it’s similar.

Step 4. Time to flash. Place the firmware you downloaded onto the openwrt router in /tmp and run sysupgrade.

This is a bit scary — because you lose your ssh connection as part of the upgrade.  It took about a minute and a half of radio silence before the device came back.  However, I was then greeted with the new web UI – and over ssh I get the 22.03.5 version splash.

Step 5. Check for any package updates – usually I leave things well enough alone, but we just did a full upgrade so it’s worth making sure we are fully current. Note, this may mess with the script in step 3 since the install dates will change for other components.

If you get any packages listed, we can easily upgrade using opkg upgrade <pkg name>

Step 6.  Install packages captured in step 3. Do this by creating a simple script to opkg install <pkg name> for each package.

Post install, take a careful look at the output of the installs, and look for any *-opkg files in /etc/config or /etc. These are config files which conflicted with local changes.

Sometimes you will want to keep your changes – others you’ll want to replace your local copy with the new -opkg file version. Take your time working through this as it will avoid tricky problems to debug later.

When I upgraded my main router, vnstat seems to have been busted in some way. The data file was no longer readable (and it’s backup) – I suspect that some code change caused the format to be incompatible. I had to remove and recreated a new one. Oh well.

Things mostly went smoothly, it took about 30mins per openwrt device and I was going slowly and taking notes. There was one tiny glitch in the upgrade. The /root/.ssh directory was wiped out – I use this to maintain a key based ssh/scp from each of my dumb AP to the main router.

Bonus. I found a new utility: Attended Sysupgrade. This is pretty slick as it makes it very easy to roll minor versions (so 22.03.02 -> 22.03.05 for example) but it will not do a major upgrade (21.03 -> 22.03). I’ve installed this on all of my openwrt devices and will use it to stay current. It takes care of all of the upgrade steps above.. but it does suffer the same ‘glitch’ in that /root/.ssh is wiped out. The other downside is that the custom firmware that is built, breaks the script in step 3 – since the flash install date is the same for all of the components. I’ll need to go refactor that script for my next upgrade.

Brother Colour Laser Printer (HL-L3270CDW)

The HP 1518ni finally became too unreliable and it was time for a replacement, I was surprised to discover we bought it back in 2009 – 14 years is a pretty good run for any bit of technology. I’d done both toner refills, and aftermarket cartridges in that HP printer with fairly good success. If I was willing to toss another $100 towards new toner it probably would have gone on for more time, but far too often it would choke with the size of print jobs being sent from the various systems (32MB of RAM just doesn’t cut it anymore).

I spent a while searching through various options. We’ve recently gotten a subscription to Consumer Reports and I used that as a source to help decide between many options. Some of the multi-function printer & scanner combinations were pretty attractive. Initially I had 3 choices I was looking at in detail.

  1. Brother MFC-L3770CDW Printer – $599.99 – OEM and 3rd party toner options.
  2. Canon Color imageCLASS MF743Cdw Printer – $649.00 – OEM and 3rd party toner options.
  3. Epson EcoTank ET-2850 Printer – $399.99 – InkJet, but without the small cartridge problem.

The cost of the multi-function laser helped reduce my enthusiasm for them. The physical size of the units would have also been a challenge for the space I had currently for the printer. The InkJet option was something I seriously looked at, but after seeing an in-law’s regular InkJet printout, I immediately noticed the crispness difference relative to laser on text printing. Any of these three would be good choices, well reviewed and very capable machines.

A few more options I explored.

  1. HP Color Laserjet Pro M255dw – $484.99 – Single function, OEM toner only.
  2. Brother HL-L3270CDW Printer– $399.99 – Single function, OEM and 3rd party toner.
  3. Canon imageCLASS MF642Cdw Colour Laser Printer– $399.99 – Multi-function, OEM and 3rd party toner.

You’ll see that my choices have pivoted to laser printers only, and at a lower overall price point. The HP was eliminated based on price, but also it seems that HP has become very hostile to 3rd party toner. Now it’s not clear if Brother has also adopted a similar posture, there seems to be some evidence they have in newer firmware updates. I didn’t dig too deeply with the Canon, but suspect similar hi-jinks is happening. While I understand that from a product service and support point of view only allowing OEM consumables simplifies things, I wish they’d allow you to override it as an opt-out of support choice vs. forcing you down a path.

It became a bake off between the Brother and the Canon, while they were the same price point they offered different features. I really wanted to like the Canon, despite the Brother having better quality prints as per the reviews. Both appeared to have pretty solid OSX support, where the HP did not. In the end, the physical size of the Canon eliminated it as an option, it simply wouldn’t fit in the cabinet where I keep the printer.

The Brother neatly fits in the same space as the old HP. It had no problem with a wired connection and the web interface came up without any fuss.  From a client perspective, the Macs running OSX and Chromebooks also were able to connect to the printer just fine. So far printing has ‘just worked’ which is the ideal. I was able even to print directly from my Pixel 4a which worked surprisingly well. Having 256MB of RAM and current OS support is a huge uplift in usability.

Looking at firmware updates, I can see that the current latest version is 1.60. My printer status page says that I’m currently on: Main Firmware Version 1.33, Sub1 Firmware Version 1.14. Unless there is a super important reason to upgrade, I’ll not. The security risk is minimal relative to the pain of being blocked from using 3rd party toner. I may still buy OEM toner for the first while, but having the option to use cheaper toner is attractive.

OpenWRT – VLANs for Guest and IoT networks

It seems I’ve been doing a lot of posts about OpenWRT lately (see my Network category). I guess it’s been a bit of an area of interest for me, and I’m having fun learning about it. With the importance of internet connectivity, having a strong home network makes a difference so it’s a worthwhile investment.

In my previous post on adding a dumb AP (access point) I covered how to extend your network with a second OpenWRT router configured to provide just WiFi access, delegating all of the other functions back to the main gateway. I’d also previously talked about adding additional WiFi networks to support Guest and IoT. In this VLAN post we’re going to combine both of these things.

This is where we’re starting, two Archer C7 routers both running OpenWRT (one is version 22.02 and the other is 23.03). The main router I’ll call ‘gateway’ is the hub, acting as my DNS, DHCP and Internet connection. The Dumb AP is just extending my WiFi network – but only has the regular lan network right now. There is a direct cable connection between the two devices (but they are on different floors of the house).

This is a pretty lengthy post, and it is step-by-step so it may seem like a lot. There are really only 4 steps.

  1. The actual VLAN setup is very easy – we define VLANs on the two routers using the same numbers.
  2. We use ‘tagged’ traffic on the port that connects the two routers to allow multiplexing different networks over a single cable.
  3. We create additional WiFi networks on the dumb AP.
  4. Then we bridge those new WiFi devices to the VLANs and the traffic flows.

We’ll start by adding some VLANs to the gateway router using the Network->Switch menu on the Web UI.

A normal OpenWRT install already has two VLANs defined (1 and 2). I’ve given them descriptions (LAN, WAN). My two new VLANs are 3 and 4, and I’ve named them IoT and Guest.

I know that the Ethernet connection to my dumb AP is on the port LAN1, it may be worth verifying that you know which port by disconnecting the cable and verifying that you cannot see the dumb AP anymore on the network. Now that we know which port, let’s modify the gateway to flow VLAN traffic there.

I’ve highlighted in red the changes. I’ve indicated for both of the new VLAN networks that the CPU traffic is tagged, and I’ve tagged the LAN1 traffic. You might also notice that the VLAN 1 (LAN) traffic on the LAN1 port is untagged.  We’re taking advantage of an OpenWRT feature that allows untagged and tagged on the same port. We leave the normal LAN traffic untagged as that’s the network we’re using to configure things – but we flow IoT and Guest traffic (none currently) as tagged data to the access point (AP).

So far it seems like I haven’t broken anything because I can still talk to the AP over the connection.

Still on our main gateway we are going to configure the br-guest and br-iot bridges to the VLAN port(s). We’ll use the Web UI again, Network->Interfaces – selecting the Devices tab.

This is of course assuming we’ve set up the Guest and IoT networks as I wrote about, if you’ve used different names then this will be slightly different. Let’s use the br-guest device as an example, but we’ll need to do the same to each of the WiFi network devices.

You can see it is not currently bridged to any VLAN, we’re going to change that and specify VLAN 4 which we will be using as the Guest VLAN.

Once we’ve got this setup for both network devices (br-guest and br-iot), we are done on the main gateway and can move to the AP. The gateway will now try to flow guest and IoT traffic over the LAN1 port, but the AP on the other side doesn’t know what to do with it.

On the AP first we will rename the WiFi network(s) so we remove it from use by any of the devices in the house. I’m using a single SSID across multiple networks/APs and allowing each device to figure out which channel/AP to connect to. Thus my “home-net” SSID is used for both the 2.4GHz and 5GHz networks, and across every AP. Let’s rename SSIDs on the AP we’re working on to have “home-netx” so we don’t have any weird issues as we are configuring things. After this change is applied, we should see that there are no devices connecting via WiFi to this AP.

Similar to the main gateway – we’re going to create the same VLAN networks on the AP. Using the same numbers is important, the number is how OpenWRT knows how to match up the network traffic.

I’ll mention again, this is the Web UI on the dumb AP – Network -> Switch that we’re working with. The physical cable is connected to the LAN4 port in my case. Changes we’re making are outlined in red. We’ve added the two VLANs using the same numbers as on the gateway, tagged the CPU traffic, and used a mix of untagged and tagged on the LAN4 port.

The untagged VLAN1 (LAN) traffic on port LAN1 allows us to continue to communicate with the dumb AP. At this point we’re almost done the VLAN setup, but we need to now add the WiFi networks and create the bridge devices we are going to associate with the VLANs.

For the most part we will use a very similar approach to what we did in the guest network post I wrote. We can skip the DHCP and Firewall setups since we will be relying on the main gateway to take care of those aspects, this still continues to be a ‘dumb’ AP.

Let’s move slowly and add a single additional WiFi network, then repeat for the others. For this we’ll move to the CLI because that’s what I did previously for the guest network setup

This is almost identical to what I did in the previous post on guest network setup, but there are a few important changes. The value for network.guest.ipaddr is set to 192.168.1.2 – the ‘1’ is for the guest network, and the ‘2’ is the same as the IP of my dumb AP. What I’m trying to do here with the IP address is reflect the address of the AP, but put it on the guest network. I’ve also set the SSID to have an ‘x’ on the end to avoid confusion until I’m ready to make this real.

A bit more on IP addresses here. The main ‘lan’ network is on 192.168.0.x – the gateway openwrt has address 192.168.0.1. The dumb AP has address 192.168.0.2, and when I declare the guest WiFi bridge on the dump AP I give it 192.168.1.2. Hopefully this symmetry makes sense to you.

Now just like on the gateway we have to modify the br-guest to link to the VLAN4 network – this will flow packets back to the gateway via the tagged switch setup. On the Dumb AP let’s modify the Network -> Interfaces [Devices], selecting the br-guest device we just created.

The port eth0.4 maps to the VLAN4 that we’ve declared is the guest network.

Now we can try connecting to the guest network we’ve just configured. Connecting to “guest-netx” gives us an appropriate guest network IP.. and shows the ‘router’ as our main gateway! This seems correct (happy dance).

All that is left is to add the other WiFi networks following the same pattern. Once that is done (and tested) we can rename the networks to the normal names (ie: home-net) and put this AP back into full production.

While my guest network is used sparingly – my IoT network will benefit from having more range via the secondary APs.

In theory – I could get away with a non-direct link between the two OpenWRT devices – most unmanaged switches will deal with things correctly, but YMMV. I’ve taken the safe path and used a direct connection because it was easy with my physical wiring.  If you have managed switches, and you are passing the VLANs through them – then you need to teach them the VLAN information. This is beyond the scope of this write up.

If you’re building this out from a clean slate – I’d suggest numbering your networks and VLANs using the same numbers. Example: VLAN 3 should have network 192.168.3.x — if you look back at my setup – I’ve mixed this up where VLAN4 is on network 192.168.1.x – oh well.  I believe you can specify higher VLAN numbers – you are not limited to sequential 1,2,3,4 – I’ll leave this up to others to experiment with.

It would be entirely possible to configure the VLANs entirely via the CLI. For example, on the dumb AP the /etc/config/network file now contains some VLAN declarations

And unsurprisingly the bridge devices now list a ‘port’ that points at the VLAN, for example the br-guest declaration below

I’ll also leave sorting out how to do this via the CLI up to others to explore.

I need to credit the excellent OpenWRT documentation that helped point me in the right direction – specifically the YouTube video by OneMarcFifty.