Is there a definitive guide for OpenWrt on x86?

I have a Netgear R8000 and converted from tomato to OpenWrt in early 2019. I'm not completely happy with wireless reliability on the R8000 (broadcom based). It seems that the lead time for developers to port OpenWrt to more modern consumer routers is considerable, which is understandable so I'm not complainnig. At this point it seems that for me moving to a dedicated x86 (or similar) based platform for the router and then using a dedicated AP may provide a longer term, future proof solution.

My current setup on the R8000 is fairly simple. One VLAN for the guest wireless network and another VLAN for our IoT devices. I use Samba with an attached USB drive as a very basic NAS for backing up our Windows, Mac, and Linux clients via rsync on each platform. Finally I use AdBlock.

I use all 4 Ethernet ports on the R8000 so I would prefer to have at least 8 ports on an x86 based solution. I'd like a solution that is future proof for at least 10 years. Is there a good discussion on hardware builds and which simple APs are best?

I don't think you will find x86/64 based hardware with 8 ports. Most of the options I've seen are either 4 or 6 port. I run OpenWrt on a Protectli FW6b and have used the following guide as a starting point: https://protectli.com/kb/openwrt-on-the-vault/. I found it to be easy-peasy and am very happy with it. My setup includes wireguard, vpn-policy-routing, SQM and Adblock. The hardware doesn't break a sweat on my 200/100 connection. I was previously running Untangle (UT) on the same machine, but got upset with them because of the way they introduced wireguard a few months ago. Even though I still have a valid license, I have now replaced UT with OpenWrt and am satisfied with the results.

1 Like

Hi.
There are miniPC with 8 ports, but that's not a common thing I agree.
http://qotom.net/product/85.html

As @cesarvog said, 4 and 6 ports are more common.

Maybe your better solution would be a rather simple miniPC (2 or 4 ports) and a managable switch for the VLAN business.

And "future proof for at leat 10 years" is rather ambitious considering the speed at which computer science evolve. Who can say what we will use in 10 years ?

2 Likes

An option worth considering is to turn off wifi and plug in a "wifi 6 access point". Some examples are the WAX214 ($80) or the U6-Lite-US ($100). For 8-ports you're going to want an 8-port gigabit switch.

Another thought if you want a router with that many ports look at the RT-AX88U, but that won't run OpenWrt because broadcom, only Asuswrt-Merlin (solid firmware, does SQM, but it's proprietary).

1 Like

Thanks @cesarvog the Protectli FW6b looks like what I'm looking for. I can make do with 6 ports.

@badulesia the R8000 was released in 2014, 7 years ago and will probably be serviceable in 3 more years. I don't think 10 years is ambitious when talking about a mini-pc.

I am using this x86/64:

Modell Barracuda Networks, Inc Barracuda NG Firewall F18
Architektur Intel(R) Atom(TM) CPU C2358 @ 1.74GHz

I have built this in the case from the NG280.

I Only use it as an big Accesspoint :wink: ...
No vLAN no use of the Switch from the NG280. (Is connected via PCIe)
...
6 Configurable LAN Ports

=> This thing has enough power to bring up a Proxmox virtualization Host - and RUN in OpenWRT as an VM in this ...

I use Openwrt as a VM as my mainrouter in proxmox - works without any problems... also i have running some other VMs and container...

I know it doesn't answer your question, but there's some glaring misinformation seeping from your statement. So allow me to set the record straight.

  1. Your router is fully ported. OpenWrt community is not to blame for the shitstorm Broadcom wireless is. Broadcom is. They chose not to contribute to the open source ecosystem. Don't blame OpenWrt for a short-sighted management decision from a corporate behemoth.
  2. Tomato uses whatever binary blobs they can get their hands on. Do they have NDAs like DD-Wrt did at some point? No idea. Maybe. Do they have better Broadcom drivers? Probably. Do they come with strings attached? Quite likely. Is their scope as a project more narrow? Probably, also. Heavily skewed towards Broadcom based devices as well (as is their right, it's their project).
  3. OpenWrt uses mainline kernels, preferably a recent LTS one. Most publicly available binary blobs are locked to some older kernel.
  4. OpenWrt doesn't do binary blobs unless the vendor makes them available and allows free redistribution (e.g. firmware blobs for most wireless drivers).
  5. OpenWrt is running just fine on 802.11ax (!) hardware from vendors that are open to collaboration with the open source community, like MediaTek. Some of those devices came to market rather recently. Look at the popularity in this community of devices like the Ubiquiti UniFI Lite 6, or the Belkin RT3200 / Linksys EA8450. So no, there's no real lead time if a platform is friendly to OSS developers.

Bottom line: if you want decent hardware and OpenWrt support, vote with your wallet and do not buy Broadcom anymore. We've all been there. For me it happened with 802.11g and 802.11n. Last time they ever got my money.

4 Likes

Dude, your snark in my direction is inappropriate. And exactly where is the glaring miinformation seeping from my statement?

I am fully aware of all of the issues related to Broadcom, hence why I noted that my router is Broadcom based as the reason for my wireless dissatisfaction. I have been aware of the blobs and kernel issues with Broadcom proprietary drivers for some time now.

Since I stated that I converted from Tomato to OpenWrt and stayed on OpenWrt, you are safe to assume that I think OpenWrt is a superior product for my purposes.

Finally, since I stated I am looking for a x86 solution to run OpenWrt, and since miniPCs aren't cheap, it would seem that I am voting with my wallet and not buying any more Broadcom products.

P.S. I apologize if any devs thought my statement about R8000 wireless reliability was a dig at your efforts as that was not my intent.

There's no snark. I'm pointing out that your statement is wrong. It's weird to see you being fully aware of the Broadcom situation (which is great, the more people the better), and yet still formulating a phrase about OpenWrt being slow to adopt "more modern" consumer routers. While you may not intend it as such, it is patently false information. There's AX routers already being supported. The community is putting in countless hours to try go get up QCA AX stuff running on OpenWrt, no thanks to QCA themselves. Your lead time statement suggests it's an OpenWrt problem, while it is a Broadcom one, a QCA one ... I'm sure you didn't intend it as such, but that's how it reads.

Let's just end this here, you've made your point.

Thanks @cesarvog, I bought the Protectli vault and have successfully installed 21.02.0 and by following the guide you linked was able to assign eth0 as the WAN port and eth1 as a LAN port.on 192.168.1.1 and DHCP is working for everything attached to eth1.

The Protectli has four more gigabit Ethernet ports which I want to use. How do I configure those in /etc/config/network. I searched the doc for mini-pcs with more than 2 Ethernet ports but came up empty.

They should automatically enumerate as eth2, eth3 etc. Unless they use a different type chip than the first two, then you may need to install the driver for that chip.

It depends on what you are willing to do with the additional ports. But, as @mk24 mentioned above, the additional interfaces will indeed be enumerated automatically as eth2, eth3...

So, if you are willing to have additional lan ports connected to the same default lan, you would modify /etc/config/network to add the additional interfaces to the list ports in the device section named br-lan.

On the other hand, if you are willing to add additional WAN interfaces, you would need to modify the same file and create another config interface section. The possibilities are endless.

I'd like 2 of them to be part of 192.168.1.0/24 and the other two to be on 192.168.10.0/24 with dhcp.

I'm no expert, but will try to help you below. As far as I understood you correctly, below instructions should do it.

First part is super easy.
Refer to screen grab below.


Just add a check mark to the additional interface and Save. NOTE: in your case, you reversed the default ports, so careful with correct port selection to your specific scenario. My screen grab does not contemplate your changes.

So, if I get you correctly, you are aiming at two different lan segments, right?

If this is the case, then after you do the above and test the second interface is indeed working:

a) open /etc/config/networks and copy and paste the sections named 'lan' and 'br-lan', naming the replicated sections 'lan2' and 'br-lan2'. Then modifiy the list ports in the newly created sections to contemplate the other two ethx ports. Don't forget to change the IP address (to 192.168.10.1) and the device (to point to br-lan2) under the new lan2 section .

b) Once this is done, manually edit the file /etc/config/dhcp to copy and paste the section named config dhcp 'lan' creating a new section named config dhcp 'lan2'.

OOPS, almost forgot:

c) Finally, you will need to manually edit the file /etc/config/firewall to copy and paste section config zone named lan to create a new zone named lan2. Once this is done add src lan2 to the forwarding section.

You are correct, the other 4 ports are eth2 - eth5 under devices. I've tried to add eth2 & eth3 as shown above but when I connect to either eth2 or eth3 there is no link light or activity light. Is there somewhere else I need to activate these ports?

Here's the relevant portion of my /etc/config/network file

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	list ports 'eth2'
	list ports 'eth3'

config interface 'lan'
	option device 'eth1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth0'
	option proto 'dhcp'

config interface 'wan6'
	option device 'eth0'
	option proto 'dhcpv6'

Change the device to br-lan instead of eth1. Access to the bridged eth ports is now via the bridge device. Since br-lan includes eth1, eth1 is still part of the lan network.

When you build another bridge for the guest network it would be the same way- a bridge device named br-guest for the layer 2 features, and a config interface 'guest' section with layer 3 settings. You can name the bridges almost anything you want but it is conventional (as was automatic in earlier versions) to call them br-network.

Your changes seem correct.
Sorry, I forgot to tell you that you have to either restart the network, or reboot for changes to work.
To do it manually, the command is: /etc/init.d/network restart

I remembered to restart the network but I missed the change that @mk24 listed above. Thanks to both of you. Now on to the second lan segment.

I also missed that.