OpenWrt is commonly used to breathe new (or better) life into consumer routers, but you can also run it on any x86 machine. I run it on a small, passively-cooled i5 machine* virtualized in Proxmox alongside Home Assistant. I originally ran OPNSense, then VyOS, but eventually went back to OpenWRT since it does everything I want/need with a simple interface.
Great comment, and same. Running it on Proxmox also enables running the router in a high-availability fashion quite easily too.. which is pretty neat.
I was running OpenWRT on my Xiaomi AX9000 (based on master but also IPQ807 specific forks), but everything OpenWRT is software-based so 1/ the AX9000's acceleration chips are idle & performance is quite limited (unless using one of the crazy experimental NSS builds where mostly everything is broken) 2/ the integration with the onboard switch itself is far from adequate, e.g. VLANS+batman-adv are quite broken - very few configurations yield a partially working network (e.g. randomly dropping ARPs).. and don't count of LACP to work even though it can be configured. That's forgiving the fact that we also have to manually patch the BDF files on OpenWRT for the AX9000 if you want the radios to be connectable, as OpenWRT do not want to ship with the correct BDFs for some vague legal liability reasons.
Used VyOS in Proxmox for a while too, but at the end of the day, the firewall boilerplate is quite huge (and can't easily be edited on the go in the house as necessary), tailscale is not natively supported, etc. Relatively sad to let go of IaaC and committing the configuration though, but somewhat manageable with snapshots.
Running OpenWRT directly on Proxmox on your home server is tempting but the risk to mess up from a security point of view (accidentally or not) is high.
After a quick look on OpenWRT wiki there is unfortunately not much information on what to be attentive to when running in a vm.
Hey, I do this as well with a Qotom mini PC and it is utterly fantastic. Home Assistant runs in a VM and the OpenWRT part handles WireGuard for remote access.
One problem that I have with it is that I'm running qemu-system-x86_64 in an init script which creates a tap0 interface and adds it to the br-lan interface. If I ever restart the networking these interfaces are removed from the bridge. I briefly looked for some sort of hook to run on network restart but didn't find one. I'd love to be able to run brctl after a network restart to add the interfaces back into the bridge.
I've run virtualized network applications before, and have always had trouble with the container mapping addresses into a new private IP subnet. Is this able to be worked around?
It's a confusing photo; those antennae are for that machine as a client, not an access point. I use it only as a router (i.e., it routes my LAN to the internet over gigabit fiber), and I use a separate access point for wifi.
The antennae are useless for my use case, but they came with it and if I removed them I'd just have to find somewhere else to store them...
Intel WiFi chips work as acess points only in the 2.4 GHz band. You can add an "Alfa Network AWUS036ACM" USB WiFi adapter as something that works in the 5 GHz band, but please don't expect more than 400 Mbps from it.
They are not really limited to 2.4 GHz band. All recent Intel chips have a stupid mechanism built into the firmware: instead of getting the country code from the OS, as everything else does, and then follow the local spectrum regulations, the chip tries to discover it automatically. Tries, because it's half-broken and most of the times it fails and locks the radio to just a few 2.4 GHz channels with ridicolous power limitation (the LCD of all countries laws).
It's supposed to perform a scan and then set the country that is advertised by nearby APs. The obvious problem is that it won't work if there are no other wifi networks, or if one is trasmitting the wrong country. Also you have to manually run the scan, before the radio is unlocked, but virtually all AP softwares don't know how to handle this properly and get stuck in a loop.
In any case, they're terrible in AP mode even after unlocking the 5GHz band, because are locked to a single VAP and are not dual-band (I mean, not at same time).
oh, one other thing.. upgrading openwrt on x86 isn't as nice as other devices with a squashfs root. I can upgrade packages, but I don't think that I can really upgrade it without re-installing everything.
You can actually if you didn't expand your partition and keep the default layout. Use the firmware builder to build a customized image with your needed packages.
Edit: ah I didn't see that you run openwrt on baremetal...
Hi apologies for any confusion. What i meant to say is that OpenWrt can be run on the Raspberry Pi. I did this because I had a Raspberry Pi laying around and did not want to invest in additional hardware just for experimenting with OpenWrt within my internal network. You can also run OpenWrt in a virtual environment like QEMU -- this is useful if you're aiming to connect multiple VMs to OpenWrt, effectively setting up a virtual network with OpenWrt at its core. Please see links below for more info:
* https://www.reddit.com/r/homelab/comments/hzvfih/new_router_...