I am looking for a router, and OpenWRT came up. I was looking at their table of hardware and the ASUS RT-AC3100 seemed like a good option, as its cheap used, (~$40 USD) and supported by the latest OpenWRT version.
Thing is, its EOL, per Asus. Does this mean that it won’t be supported on OpenWRT for much longer?
Is there a way to see or estimate when a router will no longer work on OpenWRT?
I believe it’s gotten better but historically *BSD had poor SQM support (bufferbloat mitigation), which is particularly useful on slower, asymmetric connections and where low, consistent latency is paramount.
It was also a bit of a laggard on Wireguard support, although that’s long since been fixed. So mainly you might prefer OpenWRT if you want the Linux kernel which tends to get features more quickly. Also because it’s so low on resource usage (including disk space), you can put it in a VM and very rapidly recover in the case of issues.
You could of course also use a full Linux based router OS, but I don’t believe there are many with a web interface, which most users would prefer.
Yeah, not having cake sqm is the one thing that will probably kill Opnsense as a choice for some people. That’s not to say you cannot get excellent results with fq_codel, because you absolutely can (I actively use both OpenWRT and OPNSense on different network applications personally). It is definitely more work to get good results though. OPNSense’s wireguard support has been excellent for a number of years now, and it’s exclusively what I use for tunneling in a VPC I rent.
If you’re particularly constricted on host hardware and need a lightweight router to manage multiple other VMs on said host, I could definitely see the benefits of running a minimal OpenWRT over OPNSense in that case.
I have other issues with opnsense lately but it has some sort of bufferbloat mitigation that seemed good enough. On the 1000mbps from isp I get 0ms latency increase at the expense of like 100mbps, or 0ms average with some spikes with a 50mbps loss. Can it be done without any download reduction?
It does depend on the connection type, but the general rule is not completely, barring some connection types like DSL. Given it sounds like you have Fiber, DOCSIS, or similar; you likely fall under the general rule. That said, you can absolutely tune and test above the typical 10-15% safety margin many guides start with without actually incurring any noticeable bufferbloat. The 10-15% is usually a good value for ISPs that fluctuate heavily in available babdwidth to the customer, but for more consistent connections (or for those that overrate high enough that the bandwidth fluctuations sit out of range for what the customer is actually paying for), you can absolutely get much closer to your rated connection speed, if not meeting or even passing it.
The general process is to tune one value at the time (starting with the bandwidth allocations for your pipes), apply the changes, noting the previous value, and performing a bufferbloat test with Waveform’s or others’ testing tools. Optionally, (this will drastically slow down the process, but can be worth it) one should actually hammer the network with actual load for a good few hours while testing some real-world applications that are sensitive to bufferbloat. Doing this between tweaked values will help expose how stable or unstable your ISP’s connection truly is over time.