A1300 has official OpenWrt support in snapshot

I’m not sure how I missed this, but the Slate Plus has official OpenWrt support as of about a month ago:

You can download snapshot builds, or make your own. So far it appears to be chugging along quite nicely on the 5.15 kernel:

Many thanks to the GL.iNet team for getting this into upstream OpenWrt as quickly as they did! Here’s hoping the Brume 2 and Beryl AX follow right behind!

1 Like

Could you describe after several dozen hours how the main line of OpenWRT is doing on this device?
Encouraging me to try it out because of a very new system and kernel.
Just wondering why the kernel and system is ARMv7 and not AARCH64.

The ipq4018 is a armv7 chip.

My mistake. This processor is based on the ARM A7. Probably my memory decided that this new SoC is rather aarch64.

I know the datasheet is from 2015.

The ipq6000 series in the Flint and Slate AX are aarch64, but there are currently no stable builds that work with aarch64 on those devices. Everyone I’ve seen is running those on the 4.4 qsdk kernel. The 5.4 qsdk is about 30 percent slower in my testing, with unknown stability. I did get the 5.4 to build in aarch64, but it didn’t boot on first try and I didn’t bother trying to go farther. I sort of feel like that hardware is a dead end given the MT3000 coming out.

Some initial speed tests and … ? I’m not sure where the bottleneck is, but there’s some sort of performance wonky.

I’ve got gigabit fiber, and speed test from the device is pretty decent:

Idle Latency:    19.69 ms   (jitter: 0.37ms, low: 19.17ms, high: 19.99ms)
    Download:   795.31 Mbps (data used: 889.9 MB)
                 21.07 ms   (jitter: 1.63ms, low: 18.99ms, high: 32.69ms)
      Upload:   722.11 Mbps (data used: 1.3 GB)
                 22.14 ms   (jitter: 2.69ms, low: 16.86ms, high: 43.26ms)
 Packet Loss:     0.0%

Speed test from a wired client, though… boy howdy:

Testing download speed................................................................................
Download: 351.29 Mbit/s
Testing upload speed......................................................................................................
Upload: 271.42 Mbit/s

I tried several times, and that wasn’t the best I got, but it wasn’t the worst either.

It looks like the a1300 is under some pretty severe load just trying to move packets across the interfaces.

If you’re just using it for a travel router, performance seems fairly decent:

OpenVPN, TCP, CHACHA20-POLY1305, run from A1300, displayed on web because the CLI display janked:

Speed test to same server from wired client was slower but still pretty respectable:

I suspect that some of the problem may be that I’m running iptables-nft (damn you Tailscale!) which may be responsible for some of the performance issues. I don’t know how much if any overhead that introduces over running nftables directly, but that would be the first place I’d look for some gains, if I cared. But largely I don’t.

WireGuard performance was weird too, getting 15mbps down and 200mbps up which seems… wrong? The upload speeds are in line with what you’d expect, so not sure where the D/L problem is. No time to debug at the present. I don’t recall having these problems running stock-ish on 21.02 with either the Slate AX or Brume 2 - I need to fire up an OG Brume and see what I get on performance there building a custom 21.02 and 22.03 build, since GL’s stock builds had some bad openssl options and suffered about a 40% performance penalty compared to a well optimized build.

So anyway… a mixed bag, maybe. I’m sure there are some things I could tweak a bit to get better performance, but this isn’t my main device, so my motivation is somewhat limited.


Have you tested with hardware acceleration? I don’t know if she gives anything on this device in the OpenWRT mainline, that’s why I’m asking.

Crypto acceleration? Yeah, engine support is built in, but GCM isn’t accelerated in hw. Turns out to still be faster than CBC. I tried enabling offload for NAT but that didn’t seem to make a difference.

Ok - so part of my issue in pt 1 is that I was using a really crappy speedtester. So doing things better:

From A1300:

Idle Latency:    24.41 ms   (jitter: 0.74ms, low: 23.73ms, high: 25.04ms)
    Download:   772.29 Mbps (data used: 923.5 MB)
                 25.96 ms   (jitter: 7.00ms, low: 23.67ms, high: 292.17ms)
      Upload:   714.27 Mbps (data used: 951.4 MB)
                 24.28 ms   (jitter: 2.55ms, low: 22.01ms, high: 43.35ms)

From wired client:

Idle Latency:    25.78 ms   (jitter: 2.18ms, low: 24.29ms, high: 30.46ms)
    Download:   727.12 Mbps (data used: 725.4 MB)
                 25.37 ms   (jitter: 4.37ms, low: 23.23ms, high: 254.52ms)
      Upload:   555.91 Mbps (data used: 996.8 MB)
                 24.49 ms   (jitter: 1.68ms, low: 23.39ms, high: 49.96ms)

I also started from a clean slate on WireGuard and got more reasonable results:

(from A1300)

From wired client:

That said I did have to reboot the thing this morning to get an IP address. I’ll leave it up and see how it does through the day.

1 Like

Brief update - I’ve been messing with various builds off and on today. Looks like DCO isn’t ready yet for ovpn (I built 2.6 beta 1 and… well, it didn’t go well). That said, I’m pretty consistently able to get 40/35 or so from a wired client on the LAN using OpenVPN TCP ChaCha20-Poly1305, which is ~2xish the published figures - though IIRC I was able to get well into the 30’s on a clean build from the infra-builder and a 5.4 kernel.


The numbers looks nice!

1 Like

Could you do a performance comparison between OpenWRT and GLiNet firmware?
I just want the test environment to be the same.

1 Like

I’ll try if I get around to it. I assume they’re close enough that it won’t be the determining factor in what you choose. The differences I’m getting are almost certainly down to differences in e.g. OpenVPN configuration (using chacha which is faster on the a1300, unlike the ipq6000 and MT7981 routers) rather than the kernel version.

1 Like

Could you send me the result of the lxc-checkconfig command?
Below is my result

If I understand correctly because the result is missing one parameter that will enable LXC on A1300 using the official GL.iNet software.
I’m curious if you can run LXC containers on the official OpenWRT firmware.

I need LXC containers to run Ubuntu on A1300. Unfortunately, the ARMv7 processor does not support virtualization via KVM.
I need Ubuntu to run many packages that are not available for OpenWRT. e.g. compiling libraries for pip.

lxc-checkconfig fails with some kernel messages.

Have you installed the rest of the required dependencies for lxc to work?

Link to instructions below:

I’ll check again, but it was an inability to find the kernel config rather than a dependency error, IIRC.

I could go back and compile it all in, but…

This is how it looks on my Luci based on the official A1300 firmware.

Ok. I’ll look more here in a bit.

1 Like