Author: Roo

OpenWRT on GL.iNet GL-MT6000 (aka: Flint 2)

I was reading through the OpenWRT forum several months back to see if the TPLink AX23 was still the right upgrade choice for me. I’ve been very happy with the classic TPlink Archer C7 – having 3 of these as my core network (two as dumb AP). I came across this thread on devices for ‘newcomers’ and discovered the GL.iNet GL-MT6000, it looks like a monster bit of hardware at a pretty low price point. My travel router is a GL.iNet device and it’s been great hardware for OpenWRT. Then bonus time at work hit, and I ran out of excuses to buy the GL-MT6000.

While you can buy directly from GL.iNet, just after I pushed the buy now button there I discovered that I was going to be on the hook for import duties and the shipping was via FedEx. I’ve not had good experiences with this path and the administration fees are high. The support process from GL.iNet was amazing – a few emails and my order was cancelled without any fuss.

I ended up buying via Amazon.ca (camelcamelcamel link) because shipping costs were predictable. I see that it’s not currently in stock, but my total including shipping was $248.49 – still a deal for this much hardware.

Speaking of hardware

  • Two 2.5Gb ports
  • 1GB RAM
  • 8GB Flash
  • Quad core 2GHz CPU
  • Wifi6

This may not be enough hardware to handle 1Gb symmetric fibre, but I’m still back on a much slower cable 100/30 plan. It also gets me thinking about upgrading my network switches to 2.5Gb.. but that’s a different post.

The device itself has some heft to it – there is apparently a sizeable heat-sink inside. The power cord is short – about 3′, and there is no power switch, not a problem for me, but I can see why some people felt this was a limitation.

Of course, the very first thing I’m going to do is flash this with OpenWRT. This is as simple as grabbing the sysupgrade.bin file from https://openwrt.org/toh/gl.inet/gl-mt6000 and connecting to the device over a wired connection.

The factory firmware hosts an administration web UI on http://192.168.8.1/ allowing you to do basic setup. I’m prompted to pick a language and set a password.

From this screen we can select Upgrade on the left navigation bar, then local upgrade and upload the sysupgrade.bin file we downloaded

The built in firmware handles the upgrade very nicely, it even detects a kernel change and automatically selects to not keep setting (which is what the OpenWRT wiki advises)

Even during the upgrade the web UI is pretty slick

Once it hits 100% it will automatically reboot. Since the OpenWRT default IP is different, we need to visit a different admin web page http://192.168.1.1

I have to say that the exterior of the device has a matte black finish, and the angular styling appeals deeply to my 80’s stealth bomber admiring inner teen. It reminds me of the USRobotics Courier 56k modems back in the day.

At this point we’ve got OpenWRT installed, and it’s just a matter of working through the configuration steps. I did run into a few problems that were my own tripping over my own feet issues. Linux apparently ‘remembers’ the name of the connection, and the type of connection security. If you change the encryption but not the name it seems you can run into problems. I also messed up one of the passwords with a type-o. Eventually I got it all settled down and things worked great.

Using a OSX recovery key on a Macbook M1

Passwords are annoying, but also a critical part of your security posture. Strong passwords are important, and many organizations have policies which require you to regularly change those passwords. This will eventually lead to you changing your password – and then forgetting it – locking you out of your machine.

The Apple Macbook Pro M1 has some great hardware security, this is good to keep the bad guys out, but it’ll also keep you out if you’ve forgotten your password.

Use pass phrases. Long passwords are better passwords. Use a password manager – like 1Password or Bitwarden. When you change a key password – make sure to put aside time to practice entering that password. I find if I can spend a few hours the afternoon after I change a password – I can lock it into my muscle memory. I tend to keep it written down for those first few hours, but then make sure to securely delete/dispose of that record of the password once it’s baked into my brain/fingers.

For the first time in many years, I blew it. Thankfully my work provides a way with the serial number of the device to get a recovery key if I reach out to our IT support folks. If you don’t have this safety net – make sure you take the time to create a recovery key and then store it somewhere very safe and secure.

The key will look something like this:

RECOVERY KEY: GE62-3HW1-Y7ER-QZCT-2JJ1-6SNK

Of course, in the heat of the moment you’ll be trying to surf the web on your phone to figure out how to do these steps – and there are lots of options. Let me lay out the very simple steps you need to do to recover using this key on an M1.
  1. Boot into recovery. From a powered off state, press and hold the power button until you boot into recovery mode.
  2. Connect to a network.
  3. Open a terminal from the Utilities menu.
  4. Run the resetpassword command – follow the prompts which is where you will use that recovery key.
That’s it. Easy, but make sure you have the recovery key available to you – future you will be thankful.

PSA: DNS servers have no priority order

It is a common misconception that DNS servers that your system uses are managed in a priority order. I had this misunderstanding for years, and I’ve seen many others with the same.

The problem comes from the router or OS setup where you can list a “Primary” and “Secondary” DNS server. This certainly gives you the impression that you have one that is ‘mostly used’ and a ‘backup one’ that is used if the first one is broken, or too slow. This is false, but confusingly also sometimes true.

Consider this stack exchange question/answer. Or this serverfault question.  If you go searching there are many more questions on this topic.

Neither DNS resolver lists nor NS record sets are intrinsically ordered, so there is no “primary”. Clients are free to query whichever one they want in whichever order they want. For resolvers specifically, clients might default to using the servers in the same order as they were given to the client, but, as you’ve discovered, they also might not.

Let me also assure you from my personal experience, there is no guarantee of order. Some systems will always try the “Primary” first, then fall back to the “Secondary”. Others will round-robin queries. Some will detect a single failure and re-order the two servers for all future queries. Some devices (Amazon Fire Tablets) will magically use a hard coded DNS server if the configured ones are not working.

Things get even more confusing to understand because there is the behaviour of the individual clients (like your laptop or phone), and then the layers of DNS servers between you and the authoritative server. DNS is a core part of how the internet works, and there is lots of information on the different parts of DNS out there.

The naming “Primary” and “Secondary” come from the server side of DNS. When you are hosting a system and configure the domain name to IP mapping, you set up your DNS records in the “Primary” system. The “Secondary” system is usually an automated replica of that “Primary”. This really has nothing to do with what the client devices are going to do with those addresses.

Another pit-fall people run into when they think there is an ordering, is when they setup a pi-hole for ad-blocking. They will use their new pi-hole installation as the “Primary” and then use a popular public DNS server (like 8.8.8.8) as the “Secondary”.  This configuration sort of works – at least some of the time, your client machine will hit your pi-hole and ad-blocking will work. Then, unpredictably it will not block an ad – because the client has used the “Secondary”.

Advice: Assume all DNS servers are the same and will return the same answer. There is no ordering.

I personally run two pi-hole installations. My “Primary” handles about 80% of the traffic, and the “Secondary” about 20%. This isn’t because 20% of the time my “Primary” is unavailable or too slow, but simply that about 20% of the client requests are deciding to use the “Secondary” for whatever reason (and that a large amount of my traffic comes from my Ubuntu server machine). Looking deeper at the two pi-hole dashboards, the mix of clients looks about the same, but the “Secondary” has fewer clients – it does seem fairly random.

If your ISP hands out IPv6 addresses, you may find that things get even more interesting as you’ll also have clients assigned an IPv6 DNS address, this adds yet another interface to the client device and another potential DNS server (or two) that may be used for name lookups.

Remember, it’s always DNS.