MikroTik Solutions

The Dockerfile unpacks the single static binary of Ookla’s speedtest-cli tool and sets it to give a simple human-readable test against an automatically-determined Speedtest server by default. Its small size (2.7 MiB installed) makes it ideal for testing network performance on resource constrained MikroTik RouterOS boxes running its optional container feature. As such, it’s built for both 32-bit and 64-bit ARM CPUs, but also for Intel platforms, because why not?

The current build requires RouterOS 7.10 or higher due to improvements they’ve made in OCI container compatibility.

See the Makefile for further details on building, configuring, and running this container.

Simple Method

Start by installing the container package per MikroTik’s docs, but in place of their overcomplicated network setup, put the veth on the bridge, then say:

> /container
> add remote-image=tangentsoft/speedtest-cli:latest \
  interface=veth1 \
  logging=yes
> start 0

Note that because this is a “client” type program, you probably should not set the RouterOS start-on-boot flag for this. Enabling logging is a must, else you can’t get the program’s output. Each time you want a fresh test result, you have to say something like this:

$ ssh myrouter /container/start 0

…and then wait the 10 seconds it takes to get the result in the log.

Keep in mind that RouterOS doesn’t enable the “container” logging option by default. You may have to say something like this:

$ ssh myrouter
> /system/logging/set topics=container action=memory

…and then use WinBox to watch the resulting in-memory logs for the test’s results.

Remote Tarball Method

If you need to install the container via an image tarball, the simplest way to fetch it is:

$ docker pull --platform linux/arm/v7 tangentsoft/speedtest-cli:latest
$ docker image save tangentsoft/speedtest-cli:latest > speedtest-cli.tar
$ scp speedtest-cli.tar myrouter:

That assumes you’ve got a 32-bit ARM based router such as the RB4011 and it’s got SSH with keys set already. For 64-bit routers, change the --platform argument to linux/arm64.

Source Method

You can instead build the container from this source repo:

$ fossil clone https://tangentsoft.com/mikrotik
$ cd mikrotik/speedtest-cli
$ make PLATFORMS=linux/arm64 && scp speedtest-cli.tar myrouter:

Explicitly setting the PLATFORMS list to a single option like that causes it to build for that one CPU type, not all four as it will by default. That not only makes the build go much faster,¹ it is necessary to make the tarball unpack on RouterOS, which doesn’t currently understand how to disentangle multi-platform image tarballs.

You can use any platform name here supported by your container builder. We prefer Docker for this since although cross-compilation can be done with Podman, it doesn’t work out of the box, and it’s fiddly besides.²

---

1. ^{^} And not merely 4× faster as you might assume, since non-native builds under Docker go through a QEMU emulation layer, meaning only the native build runs at native speed. A test done here took about 14 seconds to build on an Apple M1 for ARM64, but nearly a minute to build for 32-bit ARM and nearly two minutes to build for all four platforms in parallel. If your target is a 32-bit ARM device like the CRS328, it may actually be faster to build on a Raspberry Pi running 32-bit Linux!
2. ^{^} The biggie is that on macOS and Windows, you have to inject the QEMU emulators into the background podman-machine to allow this, turning it from the metaphorical “circus animal” into a “pet.” This generated VM does not make a good pet; it occasionally needs to be destroyed and recreated after upgrading Podman, requiring us to redo the customization work atop the new podman-machine.