A second test/try OpenWrt system

Installing and Using OpenWrt
1

After a few years using only the router from my Internet provider, I took my TP-Link WDR4900 out of the box and installed 21.02.3 on it.

My OpenWRT skills are now bit rusty. Normally when I configure and operate important computer systems I have separate test-system and production-system. The router is kind of critical (although, with smartphones always online it is not so bad with a failing router). I think I will experiment a bit with my router in the coming months: WireGuard, non-root-users, DDNS-scripts to name a few things. OpenWRT (thankfully) does not come with new releases weekly, so when it is time to update it is easy to forget how things were. My point here is that it would be nice to have an OpenWRT-test-system where I can experiment and break things without losing my internet connection or compromising my security. Is anyone doing that, and what do you use?

  • a second WDR4900 would have its advantages, but that is kind of unrealistic
  • I may have a WDR4300 or WDR3600 in a box somewhere, could be an option
  • an LXD container would be very easy, but that does not seem to be very officially supported with OpenWRT, and i guess the idea with flashing updates and squashfs are all lost
  • a virtual x86-machine is possible
  • a Raspberry Pi is possible

I want it to behave, especially when it comes to images, updates and configuration, just like my WDR4900. So I am a bit sceptical about both x86 and RPi. Would it be ok? Any suggestions?

Well, that was my question. I spent some time on the old forum, before it was was archived. I especially put some effort into the Table of Hardware. I am happy to see it seems to be in good condition! Coming back to OpenWRT after a few years I will just share some mixed thoughts...

ToH is good. Problem is (as always) that it has 100+ good devices in it, but when I look in my local computer store, they have 20 routers, and almost none of them seem supported. There is often also naming/version confusion. It is not your fault. I am just saying that even though I have years of experience with OpenWRT it does not take 10 minutes to find a good router to purchase when you are not actively involved. Although I have not searched to forum much yet.

The good old WRT1900AC, and the cheaper WRT1200AC are obviously gone, superseded by the quite bulky and expensive WRT3200ACM, that seems to have questionable wifi performance. That was a bit sad.

I was a bit surprised Luvit is not a standard package. Nobody wants it? Is it hard to get it working? Is it available but I missed it?

I am happy you have kept improving things since I put my OpenWRT router in a box, and I am happy to have put it to use again!

/zo0ok

2

I think you need to figure out what you want run (and do) in the end, if you want some kind of logging (Netdata etc), adblock etc you're really pushing it on most supported routers as they come with 512Mb of RAM and VLAN support might also be an issue etc. Unless you're severely constrained to physical size I'd recommend that you look at a separate system to handle routing etc and one for handling wifi. You can get relatively cheap x86 boxes that you can add another NIC too without breaking the bank and still get fairly recent hardware. If you search on the forums you'll find links to both Dell and Fujitsu alternatives for example.

I've personally moved to using a RockPro64 + Intel dual port NIC (PCIe) and FreeBSD as a router/gateway and separate routers/APs running OpenWrt (simply acting as APs) simply because it makes maintence a lot easier (read spending less time maintaining it) and you have a lot more software options / at your disposal. You might as well go with x86 but I like being slightly adventurous at times, OS/distro choice is up to you.

Raspberry Pi's are not really well suited for networking, lacking hardware crypto etc but if you want to that route you have a rather large thread about it.

3

Well, I think my "problem" is easier (and my WDR4900 is plenty enough for now).

I think about setting up a non-root-account for SSH-forwarding purposes. I guess that will affect the /etc/passwd and /etc/shadow file. I probably need a home directory as well. Can/should I use /tmp? How will this all work after a reboot? After flashing new version? Depending on how this works, I might want to try WireGuard, but I do not want to experiment with WireGuard configuration scripts (or live configuration) for that matter, on my live production-router.

RPi may not be suitable for networking. But it will be suitable enough from testing things above. But flashing a running RPi is very different from flashing my router, then perhaps I want a more router-like test/try-device.

Anyway, I tried to run x86_64-openwrt on Virtualization Station on my QNAP. No success so far... it boots in failsafe mood, but not otherwise.

4

You can put a test router's WAN on your existing LAN and double-NAT through it, keeping your existing main router. The 3600 / 4300 is very close to the 4900 even if you have the v1 4900 with PowerPC CPU, configurations generally don't depend on the CPU type.

Getting a virtual router working can be tricky, especially setting up the networking of the hypervisor.

5

I guess, the closer primary and secondary routers are the easier and the more comprehensive testing will be, up to the point that you can implement and test desired updates on the current secondary and swap this with the primary if you are happy. This would allow to keep the known working ex-primary as cold spare for some time until the new-primary is declared stable (enough) at which point the ex-primary becomes new secondary test-device.

For normal configuration compatibility the routers would not need to be identical models, but if you want bug-for-bug compatibility testing this becomes relevant; I probably would try to keep the same CPU architecture (so MIPS, ARM, or x86)...

6

I'm not sure what you want to test at this point, you may see breakage on MIPS that doesn't occur on ARM and vice versa. As long you don't have the exact same hardware there's very little point in testing things, if you're just looking for testing settings I'd recommend running a VM rather than physical hardware. That being said, MIPS is dead / dying so expect more and more breakage futher down the road

As far as virtualization goes I would expect that HyperV and Virtualbox works just fine if you're on Windows.

2 Likes
7

As others have said, if you want to do comprehensive testing with an exact configuration, having (nearly) identical systems is the best. However, if you're simply learning and testing general configurations, you can really use any OpenWrt supported device for that purpose. Want to learn how to deploy WireGuard? Want to learn the general concepts behind VLANs and firewall rules? Easy on almost any hardware. If you're looking for bugs or the ability to directly apply the config files from one device to another, you do need to have the same hardware on your dev and production systems.

2 Likes
8

Pretty much everything has been said already, but to extend on a few aspects.

If you want failsafe testing on a test device before deploying on your production router, you can only do so on an exact same model. Differences between embedded devices are just too big to deduce that if the update is running fine on tl-wdr3600/ mips, it would also work on tl-wdr4900/ powerpc this doesn't work at all. An image that works on the tl-wdr3600 is very, very likely to also fine on the tl-wdr4300 (which is nearly identical hardware, just 2x2 instead of 3x3 wireless), expecting that it will also work on the closely related WNDR3800 (NAND flash, different vendor, so different bootloader constraints) is (while likely in practice) already quite a stretch; and e.g. the tl-wdr3500 (different switch than the tl-wdr3600/4300) has shown that even despite very similar hardware issues can creep in at any time that don't show up on the more common hardware (tl-wdr3600/ tl-wdr4300).

A major part of your configuration is the network setup, here you will see three major (very, very-) different approaches:

  • legacy swconfig
    while the traditional way for most OpenWrt devices, this approach has been rejected by mainline kernel developers and accordingly efforts are underway to get rid of it (newer targets may use dsa from the start, older ones are scheduled to be ported over)
  • dsa
    this is the new/ mainline way to configure managed switches, for userspace, each port is represented as an individual interface, allowing hardware offloaded switching via 'normal' linux userspace configuration (iproute2, tc, brctl, etc.).
    mvebu, mt762x have already switched, PRs for ipq806x, ipq40xx and ath79 exist and are fully functional - only the sheer amount of supported devices makes it hard to actually pull the trigger (without (fear of-) breaking devices).
  • independent network interfaces
    this is commonly found on x86_64, ARM SBCs (RPi4, rockchip, sunxi, etc.), bridging and VLANs are configured 'naturally' in the linux kernel.

If you know (very well-) what you're doing, you can (manually) transpose the configurations between these device classes, but configurations have very different syntax and semantics between these different network management approaches. Given how massive the differences are, you really want to have production/ test devices using the same switch setup (everything else would not be representative and cause you massive headache going back and forth).

As an aside, even different devices both using swconfig can act rather differently - there is still the possibility of one model using two CPU-ports or only one, or using a dedicated interface for WAN - so even there configurations might not be as uniform between 'similar' devices as you might imagine.

If you just want to test "software services" (e.g. dhcp, adblock, VPN setups, etc.), you can replicate that on pretty much any supported device (including virtual machines), but anything closer to the hardware and especially the networking side of it, you do want like-for-like testing on (at least close to-) identical hardware between production and testing. The question if it will boot up and 'work' at all can only conclusively answered on identical (same model) hardware.

While the tl-wdr4900 is capable hardware, it's also very exotic and plagued by very low bootloader imposed size limits for the kernel, this hardware is fragile and has a very unclear path into the future - at this point there are no tl-wdr4900 images for 22.03~, and it's not very likely to be fixable for 22.03.0 and beyond.

OpenWrt can work pretty well on x86_64 hardware (see Tips for getting cheap used x86-based firewall with full Gbit NAT (a PC Engines APU) if you are in the US for a selection of interesting affordable low-power/mid-to-high-performance/multiple-ethernet-ports/mostly-no-wlan devices), likewise the RPi4, NanoPi r2s/ r2c/ r4s/ r5s maybe be rather interesting for higher speed connections.

4 Likes
9

Thank you for informing me the WDR4900 is falling out of support.
I would obviously be happy to provide information from my actual device, if that could be helpful, but I suppose that is another topic.

I will consider getting two new identical devices.

When it comes to network configuration itself I have a pretty standard setup: Public Dynamic IP, NAT, and a few open ports or port forwards to LAN.

It is more that OpenWrt is different from other Linux distributions when it comes to upgrading, configuration and package management. That is what I want to "test and try" on another device, instead of breaking my live router.

I had some problems with x86 on Virtualization Station.

When it comes to RPi: I understand initial installation is different (because I just write the image to an SD card). Is sysupgrade behaving the same way on RPi as a typical router, if I use the squashfs installation from the beginning?

10

This is why I would suggest that you get a separate device as gateway to reduce time spent on tinkering, testing and maintenance and use it for APs only :slight_smile:
It's "fun" for a few hours after that it just becomes a chore unfortunately :-/

Just run an instance on your desktop/workstation computer, it'll work fine with very modest requirements on ram and cpu.

1 Like