Category: How To

When travelling I usually just deal with the internet situation that is provided, I’ve got wireguard if I want to have ad blocking or reach to my home network. The other day I got looking at travel routers, and while TP-Link has some popular ones, the GL.iNet devices seem to have more flash and RAM for basically the same prices.

The GL.iNet AR300M16 was under $40 on amazon.ca, and it shipped (free) in a few days. Look at it, very tiny and cute – but more powerful than the Netgear WNR3500L that I’ve used in the past. The USB power supply I’m using is larger than the router.

Of course, I selected this device with OpenWRT in mind. While the stock firmware has some really nice features as a travel router – I think I can achieve the same things with plain old OpenWRT. The GL.iNet device family apparently uses an OpenWRT base and customizes it. There are a number of GL.iNet devices documented on the OpenWRT site, but nothing specific for the AR300M16. The AR300M is close, but has a different flash module setup.

The first thing I did was just connect to the device, both wireless and wired. I knew that the OpenWRT install was going to require a wired only connection so I wanted to make sure that the laptop I was using was going to be able to successfully connect to the stock firmware over wire.

I was impressed at the quality of the user interface. I may have to give the stock firmware a proper try, but first let’s flash OpenWRT to it.

This turns out to be very easy. The stock firmware ‘local’ upgrade process will accept a .bin file. The OpenWRT firmware selector gives us an easy way to find a compatible firmware for the “GL.iNet GL-AR300M16” device.

I started with the Kernel image. This is the recommended path for moving from stock as it’s a smaller image. The stock firmware was happy to accept this .bin file as an upload, but warned me that I was treading in dangerous waters.

No problem, I know what I’m doing (so I told myself). Hitting “Install” and off we went. I did made sure that before I flashed the firmware I was using a quality USB power supply that delivered more than 2A of power.

This went smoothly, but the IP address of the router changed from 192.168.8.1 to 192.168.1.1. This is a difference between the stock firmware defaults and the OpenWRT defaults.

I then used the OpenWRT firmware upgrade to flash the sysupgrade image. This went smoothly as well. Now I have a teeny tiny router with OpenWRT installed.

Next I need to figure out how I want to configure this particular device to be my travel router, allowing me to connect my devices to it – and have it use another wifi network as the upstream. Then explore adding some ad blocking and some other nice features.

It seems I’ve been doing a lot of posts about OpenWRT lately (see my Network category). I guess it’s been a bit of an area of interest for me, and I’m having fun learning about it. With the importance of internet connectivity, having a strong home network makes a difference so it’s a worthwhile investment.

In my previous post on adding a dumb AP (access point) I covered how to extend your network with a second OpenWRT router configured to provide just WiFi access, delegating all of the other functions back to the main gateway. I’d also previously talked about adding additional WiFi networks to support Guest and IoT. In this VLAN post we’re going to combine both of these things.

This is where we’re starting, two Archer C7 routers both running OpenWRT (one is version 22.02 and the other is 23.03). The main router I’ll call ‘gateway’ is the hub, acting as my DNS, DHCP and Internet connection. The Dumb AP is just extending my WiFi network – but only has the regular lan network right now. There is a direct cable connection between the two devices (but they are on different floors of the house).

This is a pretty lengthy post, and it is step-by-step so it may seem like a lot. There are really only 4 steps.

1. The actual VLAN setup is very easy – we define VLANs on the two routers using the same numbers.
2. We use ‘tagged’ traffic on the port that connects the two routers to allow multiplexing different networks over a single cable.
3. We create additional WiFi networks on the dumb AP.
4. Then we bridge those new WiFi devices to the VLANs and the traffic flows.

We’ll start by adding some VLANs to the gateway router using the Network->Switch menu on the Web UI.

A normal OpenWRT install already has two VLANs defined (1 and 2). I’ve given them descriptions (LAN, WAN). My two new VLANs are 3 and 4, and I’ve named them IoT and Guest.

I know that the Ethernet connection to my dumb AP is on the port LAN1, it may be worth verifying that you know which port by disconnecting the cable and verifying that you cannot see the dumb AP anymore on the network. Now that we know which port, let’s modify the gateway to flow VLAN traffic there.

I’ve highlighted in red the changes. I’ve indicated for both of the new VLAN networks that the CPU traffic is tagged, and I’ve tagged the LAN1 traffic. You might also notice that the VLAN 1 (LAN) traffic on the LAN1 port is untagged.  We’re taking advantage of an OpenWRT feature that allows untagged and tagged on the same port. We leave the normal LAN traffic untagged as that’s the network we’re using to configure things – but we flow IoT and Guest traffic (none currently) as tagged data to the access point (AP).

So far it seems like I haven’t broken anything because I can still talk to the AP over the connection.

Still on our main gateway we are going to configure the br-guest and br-iot bridges to the VLAN port(s). We’ll use the Web UI again, Network->Interfaces – selecting the Devices tab.

This is of course assuming we’ve set up the Guest and IoT networks as I wrote about, if you’ve used different names then this will be slightly different. Let’s use the br-guest device as an example, but we’ll need to do the same to each of the WiFi network devices.

You can see it is not currently bridged to any VLAN, we’re going to change that and specify VLAN 4 which we will be using as the Guest VLAN.

Once we’ve got this setup for both network devices (br-guest and br-iot), we are done on the main gateway and can move to the AP. The gateway will now try to flow guest and IoT traffic over the LAN1 port, but the AP on the other side doesn’t know what to do with it.

On the AP first we will rename the WiFi network(s) so we remove it from use by any of the devices in the house. I’m using a single SSID across multiple networks/APs and allowing each device to figure out which channel/AP to connect to. Thus my “home-net” SSID is used for both the 2.4GHz and 5GHz networks, and across every AP. Let’s rename SSIDs on the AP we’re working on to have “home-netx” so we don’t have any weird issues as we are configuring things. After this change is applied, we should see that there are no devices connecting via WiFi to this AP.

Similar to the main gateway – we’re going to create the same VLAN networks on the AP. Using the same numbers is important, the number is how OpenWRT knows how to match up the network traffic.

I’ll mention again, this is the Web UI on the dumb AP – Network -> Switch that we’re working with. The physical cable is connected to the LAN4 port in my case. Changes we’re making are outlined in red. We’ve added the two VLANs using the same numbers as on the gateway, tagged the CPU traffic, and used a mix of untagged and tagged on the LAN4 port.

The untagged VLAN1 (LAN) traffic on port LAN1 allows us to continue to communicate with the dumb AP. At this point we’re almost done the VLAN setup, but we need to now add the WiFi networks and create the bridge devices we are going to associate with the VLANs.

For the most part we will use a very similar approach to what we did in the guest network post I wrote. We can skip the DHCP and Firewall setups since we will be relying on the main gateway to take care of those aspects, this still continues to be a ‘dumb’ AP.

Let’s move slowly and add a single additional WiFi network, then repeat for the others. For this we’ll move to the CLI because that’s what I did previously for the guest network setup

This is almost identical to what I did in the previous post on guest network setup, but there are a few important changes. The value for network.guest.ipaddr is set to 192.168.1.2 – the ‘1’ is for the guest network, and the ‘2’ is the same as the IP of my dumb AP. What I’m trying to do here with the IP address is reflect the address of the AP, but put it on the guest network. I’ve also set the SSID to have an ‘x’ on the end to avoid confusion until I’m ready to make this real.

A bit more on IP addresses here. The main ‘lan’ network is on 192.168.0.x – the gateway openwrt has address 192.168.0.1. The dumb AP has address 192.168.0.2, and when I declare the guest WiFi bridge on the dump AP I give it 192.168.1.2. Hopefully this symmetry makes sense to you.

Now just like on the gateway we have to modify the br-guest to link to the VLAN4 network – this will flow packets back to the gateway via the tagged switch setup. On the Dumb AP let’s modify the Network -> Interfaces [Devices], selecting the br-guest device we just created.

The port eth0.4 maps to the VLAN4 that we’ve declared is the guest network.

Now we can try connecting to the guest network we’ve just configured. Connecting to “guest-netx” gives us an appropriate guest network IP.. and shows the ‘router’ as our main gateway! This seems correct (happy dance).

All that is left is to add the other WiFi networks following the same pattern. Once that is done (and tested) we can rename the networks to the normal names (ie: home-net) and put this AP back into full production.

While my guest network is used sparingly – my IoT network will benefit from having more range via the secondary APs.

In theory – I could get away with a non-direct link between the two OpenWRT devices – most unmanaged switches will deal with things correctly, but YMMV. I’ve taken the safe path and used a direct connection because it was easy with my physical wiring.  If you have managed switches, and you are passing the VLANs through them – then you need to teach them the VLAN information. This is beyond the scope of this write up.

If you’re building this out from a clean slate – I’d suggest numbering your networks and VLANs using the same numbers. Example: VLAN 3 should have network 192.168.3.x — if you look back at my setup – I’ve mixed this up where VLAN4 is on network 192.168.1.x – oh well.  I believe you can specify higher VLAN numbers – you are not limited to sequential 1,2,3,4 – I’ll leave this up to others to experiment with.

It would be entirely possible to configure the VLANs entirely via the CLI. For example, on the dumb AP the /etc/config/network file now contains some VLAN declarations

And unsurprisingly the bridge devices now list a ‘port’ that points at the VLAN, for example the br-guest declaration below

I’ll also leave sorting out how to do this via the CLI up to others to explore.

I need to credit the excellent OpenWRT documentation that helped point me in the right direction – specifically the YouTube video by OneMarcFifty.

I’m a big fan of OpenWRT – partly because it turns a ‘commodity’ router into something a lot more powerful, but also because it allows me to choose the software running on an important bit of hardware. Internet access is almost like air at this point, you want a solid solution you can trust. For me, controlling the software is part of that.

To get good WiFi coverage in my house, I needed more than one WiFi access point. OpenWRT has the idea of a ‘dumb AP’ (access point) that allows you to extend your WiFi coverage with another router. I’ve now got 3 TP-Link Archer C7‘s setup. One is the main gateway and the other two are access points. Two was plenty to get good coverage, three ensures that every corner of the house is solid.

The OpenWRT documentation for setting one up is pretty good, but it can be confusing. If you dig around you’ll actually find a few different approaches as well, but I’ll stick with the one that is working for me.

The doc boils down the basic steps into

TL;DR Here are the important configurations for a Wireless AP router (Dumb AP):
1. The dumb AP is connected LAN-to-LAN to the main router through an Ethernet cable.
2. The dumb AP bridges its wireless interface onto its LAN interface. Wireless traffic on the dumb AP goes to its (Ethernet) LAN interface, and then to the main router.
3. The dumb AP LAN port has a static address on the same subnet as the main router’s LAN interface
4. The dumb AP’s gateway is set to the address of the main router
5. The dumb AP does not provide DHCP service, DNS resolution, or a firewall

Clearly (1) is the physical connection between the two devices. It turns out that (2) is not required for current versions (newer than 21.02). This leaves just 3, 4, 5 which we can accomplish pretty easily.

I’m working with version 22.03, and this is a recap of what I did vs. a walk-through as a made a few errors along the way. First you need to start with the device you want to turn into an access point not connected to your main network. Connect directly to it with an Ethernet cable.

Log in and go to “Network”->”Interfaces” and edit the “LAN” interface.
We want to set a static IP address (the Protcol). The IPv4 address you select should be one on your current network that is not part of the DHCP range (pick a low number). The IPv4 gateway should be the IP address of your main router.

On the “Advanced Settings” tab we want to configure the DNS server to point at the IP address of our main router.

Next, on the DHCP Server tab we will select “Ignore interface” so we stop this device from trying to hand out IP addresses, the main router has this job.

Last we need to go to the DHCP Server sub-tab “IPv6 Settings” and disable all three of: RA-Service, DHCPv6-Service, and NDP-Proxy.

Once this is all done, we can “Save” and “Save & Apply” the settings we’ve made. As we’ve just changed the IP address of the device we’ll likely need to reconnect to the new IP to be able to verify that all the settings have taken hold.

Assuming all is well, we can now connect this newly configured access point to our normal LAN network.

One last thing for configuration of the access point, we haven’t yet disabled the firewall which is not required. Let’s do this in a way that will help us when we upgrade the OpenWRT firmware and modify the /etc/rc.local file to have:

This will disable and stop the services if they are running. One more reboot and we’re good to go.

Of course, now we have two devices which can offer WiFi service. The access point will forward traffic to the ‘gateway’ which is our main router.

WiFi configuration is just like normal. I would recommend using the same SSID as your main router (and same passwords, etc), but select a different channel. Your devices should seamlessly switch from one access point to the other.

For 2.4GHz WiFI – we are well advised to pick one of channels 1, 6 or 11. There is a good article that discusses why here. Since we have 2 access points we can pick 2 of those 3 channels – so it’s worth looking to see which of the two are least crowded in your area.

On OSX, if you hold down “Option” and click the wifi icon on the task bar you’ll be presented with additional options. Pick “Open Wireless Diagnostics…” then immediately use the Menu bar to  open “Window”->”Scan” – this will present you with the list of networks that your OSX machine can see. Moving around your home you can do a rudimentary network scan.

For 5GHz WiFi there are more channels, but the advice is the same. Pick non-overlapping channels. Make sure to set the country code to unlock the channels which are allowed in your country. I wasn’t able to use channel 100 until I did this, so it’s good to configure the country under the Wifi device “Advanced Settings”.

Bonus activity

As you run this 2nd wifi access point you’ll notice that when viewing it’s status page you don’t always see nice hostnames. This is because the ‘dumb AP’ is delegating much of the work back to the main router / gateway and doesn’t build out the arp table which would contain this information. There are some solutions where arp-scan and fping are used to get this information. While this works well, it doesn’t cover IPv6 addresses. The other downfall is that you have to install additional packages.

A simpler approach is to use scp to regularly copy the /tmp/dhcp.leases file from the main gateway to the dumb AP. The one downside to this is that you’ll additionally see the full list of “Active DHCP Leases” on the dumb AP – something that it is not managing at all as we disabled DHCP.

Neither solution is perfect, I’ll leave this up to the reader to decide which works best.