Slate AX GL-AXT1800 - Initial Feedback of Router and Power Supply

echo 255 > /sys/class/thermal/cooling_device0/cur_state

“255” can be changed from 36 to 255, which control the speed of fans. the max speed is 6000r/min.

1 Like

Yes, unfortunately most of it is offtopic and I think I have to apologize for derailing this thread, it was not my intention.

You can check this thread:

I was not satisfied with its performance while technically you can install it (may be I am a bit spoiled by pfsense running on mini PC (8GB RAM/ 128GB SSD), it has a similar plugin called pfBlockerNG).

This is very interesting, thank you for the info!
PS: (6000 RPM looks a bit too fast, but never say never :slight_smile: )

Not sure what adguard does that adblock doesn’t, but adblock works fine on my Mango and Beryl and, um, blocks the ads.

I am also not sure, I have not used adblock. I have no doubts it would block the stuff, the question is how many entries can the block list include and how much it will tax the CPU (which in turn should affect the overall performance of the router).

I’m using the Stephen Black list, so about 66,000 sites. I’m using less than half the RAM and not noticing any ill effects. On my home router (also dual core and 256mb) I’m blocking about 200,000 sites without an issue, so I think it would be the same. Anyway, I think wireguard and wireless would be reasons to move up, but not necessarily ad blocking.

You can see the names of DNS blocklists and the numbers of the rules in each of them I use in AXT1800 on a screenshot shown in one of my previous posts.

Yes, over 200,000. Many of those are going to be duplicatea

I use the OSID list:

It gives 402294 rules, without duplicates. I prefer one large list than many small ones, because as @elorimer said, you will have a lot of overlap unless they are designed to work together with other lists.

Thanks for the link, I see this is the list from Adblock Plus. Honestly speaking, I am mostly interested in blocking Windows stuff, AdGuard uses nextdns server as the upstream DNS server which does all DNS filtering heavy lifting.

Most likely, but it should not affect the performance (while the RAM consumption - yes).

I will try adblock on Beryl a bit later, right now I am flashing it with ROOTer (MT1300 is fully supported and that is the great news) which is much more suited for work with LTE modems (which I am pretty interested in).

It will affect both ram and performance. It still has to scan the filters, so if you have 10k filters duplicated over 4 lists, that is 40k filters it will process, instead of 10k if it was a consolidated list. In that example 4 times slower.

I don’t like 3rd party services, its another service i need to trust with my data. Nextdns has to process all your requests, they basically see everything you do on the net.

I seriously doubt. As soon as you found the entry in the first list there is no need to continue searching for this particular name since you already know that it has to blocked.
In addition to that If I would be a programmer who has to design a DNS filter I would join all lists into the one in the RAM (got rid of duplicates at this step), build a hash table and use some sort of quick binary search over the whole list.

True. It also true that ANY DNS server which receives your requests naturally sees them.
Yes, security comes with some cost. For example, you can point to nexdns your cell phone (if it allows private DNS, Samsung S10 allows) and all dns requests will be examined by nexdns.
If one looks at how much telemetry is sent/received by Android he could be really surprised, since in my view, OSs for mobile devices is the least audited/ user controlled kind of OSs.

I’ve found the perfect charger for the Slate…

A lot smaller and for my needs (no USB hdds and stuff) it’s perfect.

It’s from Microsoft from an older lumia phone.

Microsoft Mobile

3.0A more than sufficient imho

Same thing from Nokia, half the cost.

Do you have the type nr from the charger?

How about this one ?

A programmer knows not to trust another programmer :rofl: This is why open source exists in the first place :smiley: You don’t know how it was implemented unless you look at the source code. So i rather just reduce the number of steps that i have control over :smiley:

If i know i need so and so lists, and there is a combined list, then i will use the combined list.

In addition to some of the reviews above, I thought I’d post my impressions.

I got my AXT-1800 in the mail on Thursday and have been playing around with it off and on as time allows. A few initial thoughts:

  1. Anybody who is familiar with GL.iNet’s recent design philosophy will immediately recognize the AXT-1800. The build quality seems solid, though not really premium. That said, I am disappointed that GL.iNet continues to move the wrong direction in terms of size / weight. The AXT-1800 is larger in every dimension than the MT-1300, which itself was substantially larger than the MV-1000W or AR750S before it. As a point of reference, it weighs over 3x what the AR750S did. Frankly, calling it a “travel router” is starting to be a stretch.

  2. That said, the performance is undeniably impressive. I’ve been doing some real world tests on downloads to a private VPN, and I’ve seen Wireguard speeds of close to 500mbps. Far more surprising, I’ve seen OpenVPN speeds above 200mbps, which exceeds the “lab” test numbers GL.iNet published. As someone who prefers OpenVPN to Wireguard, this is a pretty big game changer. In any event, the speeds are getting fast enough that for basically any practical real-world travel purpose both VPN technologies are faster than what you’ll get over a wireless link at a hotel.

  3. There’s a reason for the size and performance above, and that is that the AXT-1800 is quite power hungry. I’ve seen it pull over 6W, and it sits between 3-4W at idle. That’s a lot of heat in a small device, and eagle eyed owners will notice that the AXT-1800 contains a fan (which I think is a first for a GL.iNet travel router), though mine has not turned on yet. It does get warm to the touch though, and obviously a major reason for the size increase is additional cooling.

  4. The new 4.0 firmware is nice, but does have some quirks and features. The new VPN dashboard is a great improvement, but there doesn’t seem to be a way to use different username/password combinations with different OpenVPN servers within a single group. This isn’t a huge issue, but is kind of annoying. There also seems to be a regression while using encrypted microSD volumes on Samba. Fixable if you jump into real OpenWRT, but it would be nice if it were fixed in the main firmware.

Now some rough edges:

  1. 2.4G networking appears very slow. I was only able to get 20mbps or so while using the AXT-1800 as a client, but switching over to 5G jumps things to close to 300mbps (connected as client to Unifi WiFi 6 LR access point about 15 feet away). This isn’t really ideal in my general opinion, but it’s livable.

  2. I’ve experienced a few random reboots here and there which I assume will be worked out in future firmware revisions. One was when using cryptsetup to format a microSD card - a couple of kernel panics I’m assuming. More concerning, the first time I tried to connect to a wireless network the router rebooted. It hasn’t happened again, but does seem worth mentioning.

  3. GL.iNet seems to have made some … let’s go with unorthodox choices with regard to firmware. For example, OpenSSL is compiled with the OPENSSL_PREFER_CHACHA_OVER_GCM flag, even though openssl speed shows that aes-128-gcm is >2.5x faster than chacha20-poly1305 on the device. I understand why you might think that would be a good idea given the emphasis on Wireguard, but it seems like you’d prefer the faster cipher. Also, the AXT-1800 is running an armv7l version of OpenWRT, even though all available data suggests it uses a processor with Cortex A53 (armv8) cores. GL.iNet used an aarch64 build for the MV1000, so it’s odd that they’ve chosen the 32-bit route for the AXT-1800

  4. Currently none of GL.iNet’s custom patches have been pushed back up into the main OpenWRT repository, which means those of us who like to do that sort of thing can’t make our own builds at the moment. They are generally pretty good about adding support eventually, but it would be nice to see it sooner rather than later (and hopefully on aarch64!)

All in all the AXT-1800 is larger and heavier than I’d like, but the performance makes it easier to forgive the size and weight compared to the MT-1300. If anyone at GL.iNet is reading, it seems like the ideal would be a router closer to the size of the AR750S with 1/2 the VPN performance of the AXT-1800, which would still be more than adequate for almost any (hotel) situation today. In any event, I’ll be taking it on a trip in a few weeks and will try to remember to report back on how it does.