OpenWrt on x86-64

Backstory and why

I switched to using OpenWrt as my preferred firmware for SOHO routers 5 or 6 years ago. During that time, I used it on a Linksys WRT 1900AC. However, over the last few months, I have had to use another WRT 1900AC that is using Linksys’ provided firmware. The Linksys firmware works for necessary routing. It’s troubleshooting, and firewall management tools leave a lot to be desired, though.

Due to constraints on the current home/lab network, I can’t reassociate a few WiFi devices with either OpenWrt on the current WRT 1900AC or replace it entirely with another WRT 1900AC running OpenWrt.

So restricting the current router to just the WiFi access point role is what I am limited to doing. The next question is what should replace it in the role of network router? My three options appear to be:

  • The other WRT 1900AC running OpenWrt
  • An old computer running pfSense®
  • Or the same old computer running OpenWrt

Onto the testing

Right now, I am testing the old computer running OpenWrt option. So far, the installation was simple. I downloaded the latest version from the OpenWrt Releases page. For a 64 bit x86 device, the required target is x86/64. I went with the combined-ext4 image. After downloading the device image, I wrote it directly to the hard drive I am dedicating to the new router. I installed the hard drive in the computer and booted it up.

Contrary to the OpenWrt documentation, I could use a keyboard to login to the local console on the test rig. My biggest complaint so far is the lack of software installed by default. Most x86 hardware that you would run OpenWrt on are much more potent than the other devices they support. I expected that Samba and ReadyMedia formerly MiniDLNA would be installed though disabled by default. Most SOHO routers you can buy have the option of being a NAS, so OpenWrt not including the software for that by default in the install image for the most spacious target they support is a bit odd from my perspective.

Interesting stuff learned during the process

While I prefer Rufus for writing ISO or disk images to USB media, the OpenWRT documentation recommended using a tool called balenaEtcher. I decided to try it out. I do like that it validates that the flashing process completed. I also like that it can handle compressed images directly saving the step of uncompressing the image before writing it.

What do I not like about balenaEtcher? File size. Rufus will fit on a single 3.5″ floppy disk. balenaEtcher would need 89 3.5″ floppy disks. For my younger audience who don’t know what a 3.5″ floppy disk is, you can read about them on Wikipedia. They have a standard storage capacity of 1.44 Megabytes.

Yarn versus NPM

Over the last few days, I have had to use both Yarn and NPM to attempt to install two different programs for a couple of home networking experiments. The dependency packaging of Node projects leaves something to be desired. Problems with dependency fulfillment become especially apparent when the package manager pulls in dependencies that are several years out of date for some reason.

I eventually figured out which dependency was causing the problems and that a non-feature breaking update would solve the problem. Yay, I can get the problem solved quickly and get back to testing a new networking feature for my home lab. A yarn update node-gyp upgrade should have solved the problem.

Over 30 minutes of running around in circles trying to get yarn to update a transitive dependency. A short sequence of

  • Installing npm-check-updates
  • running npm-check-updates -u
  • and npm update

Meant I had node-gyp and several other outdated dependencies updated.

Yarn might be better than NPM for running a built Node package, but it isn’t the easiest to use when a dependency update is required.