WiFi Signal Strength Graphs

WiFi generally works well, but sometimes it does not and I’d like to know why: Is the signal weak? Is the noise floor increasing? To measure that, get the data and collect and make nice graphs out of it!

Gather data

Mikrotik SXT Lite5

You need a method to get raw data out of your wireless device (Mikrotik SXT Lite5). In my case:

  • Create an account on the SXT to log in (via ssh key, see here)
  • A script to gather the data (I use telegraf with the InfluxDB line protocol). The REST API of RouterOS 6.x is unfortunately not yet usable.
set -euo pipefail

# gather_one(router,interface)
function gather_one {
  ssh -i ~/.ssh/id_sxt17 telegraf@$1 "/interface wireless monitor $2 once" | tr -d '\r' >/tmp/f1
  radio_name=$(awk '/^ *radio-name:/{print $2}' /tmp/f1)
  if [[ -z "$radio_name" ]] ; then

  tx=$(awk '/^ *tx-ccq:/{print $2/100}' /tmp/f1)
  rx=$(awk '/^ *rx-ccq:/{print $2/100}' /tmp/f1)
  tx_overall=$(awk '/^ *overall-tx-ccq:/{print $2/100}' /tmp/f1)
  nf=$(awk '/^ *noise-floor:/{print $2/1}' /tmp/f1)
  sn=$(awk '/^ *signal-to-noise:/{print $2/1}' /tmp/f1)

  if [[ ! -z "$rx" ]] ; then echo "signal,host=$1,radio=$radio_name rx=$rx" ; fi
  if [[ ! -z "$tx" ]] ; then
    echo "signal,host=$1,radio=$radio_name tx=$tx"
    echo "signal,host=$1,radio=$radio_name tx_overall=$tx_overall"

  if [[ ! -z "$sn" ]] ; then echo "signal,host=$1,radio=$radio_name sn=$sn" ; fi
  if [[ ! -z "$nf" ]] ; then echo "signal,host=$1,radio=$radio_name nf=$nf" ; fi

gather_one sxt17.lan wlan1-gateway
gather_one router.lan wlan1
gather_one router.lan wlan2
  • telegraf.conf needs to run the above script and feed the data into InfluxDB:
  commands = ["/home/harald/bin/wlan-influxdb.sh"]
  timeout = "10s"
  data_format = "influx"

Display Data

Create a new panel in Grafana:

Top left panel definition

And here the resulting graphs:

Signal Strength, Noise Floor and Signal Quality

Note that the various hardware variations don’t always show the same raw data about the wireless interfaces. E.g. my router does not show the signal strength, only the noise floor.


Mikrotik RouterOS and TLS

Browsers nowadays complain (rightly) about HTTP being used instead of HTTPS. My Mikrotik routers still use HTTP. Time to fix this!

❯ step ca certificate --provisioner=myCA@home --san= \
--san=sxt17.lan --not-after=8760h \
sxt17.lan sxt17.cer sxt17.key \
--provisioner-password-file ~/.step/pass/provisioner_pass.txt

❯ scp sxt17.key sxt17.cer admin@sxt17.lan:
❯ ssh admin@sxt17.lan

/certificate import file-name=sxt17.cer name=sxt17.lan passphrase=""
/certificate import file-name=sxt17.key passphrase=""
/file remove sxt17.cer
/file remove sxt17.key
/ip service set www-ssl certificate=sxt17.lan disabled=no

Note that the certificate is valid for a year instead of the default of 24h. Renewing is simple:

❯ step ca renew --force ./sxt17.cer ./sxt17.key

❯ scp sxt17.key sxt17.cer admin@sxt17.lan:
❯ ssh admin@sxt17.lan

/certificate import file-name=sxt17.cer name=sxt17.lan passphrase=""
/certificate import file-name=sxt17.key passphrase=""
/file remove sxt17.cer
/file remove sxt17.key

If the REST API of Router OS would work, I could use those instead of using ssh, but they don’t work for me. Seems version 7 of RouterOS will work with the REST API but I am not adventurous enough to verify that.

Wireguard VPN

Tested between my home machine and my server-on-the-Internet, and…it just worked once I stopped using my usual Debian 10 server and “upgraded” to Ubuntu 20.04. Really good description is here.

Significantly easier to configure compared to SoftEther which is what I used before. SoftEther can do much more though, but if all you want is a VPN tunnel, Wireguard it is.

Synology’s DSM and Minio’s S3

It’s no straightforward to use Minio’s S3 server as back-end for DSM’s Cloud Sync. Here how to make it work:

Enable minio with TLS

# Create a certificate for Minio
step ca certificate cubie.lan ~/.minio/certs/public.crt ~/.minio/certs/private.key --provisioner-password-file=$HOME/.step/pass/provisioner_pass.txt

export MINIO_ACCESS_KEY=access_key
export MINIO_SECRET_KEY=secret_key_very_secret
export MINIO_DOMAIN=cubie.lan
minio server /s3

You can now access this storage via https://cubie.lan:9000. Note the MINIO_DOMAIN which enables access to buckets via BUCKET.cubie.lan instead of cubie.lan/BUCKET.

Cloud Sync and Minio’s S3

In DSM open Cloud Sync, create a new connection, select S3 Storage:

Now the trick: DSM does not use http://cubie.lan:9000/BUCKET/ to access your bucket, but instead it uses https://BUCKET.cubie.lan:9000/, so you need a DNS entry for each bucket you use in DSM (CNAME will do).

Click Next in above DSM screen and leave the Remote Path empty (Root folder). Changing this will break the replication.

That’s it: 3 points really:

  • Must use https
  • Uses DNS names to access buckets
  • Don’t use sub-directories inside a bucket

RouterOS and SSH

I got 6 Mikrotik RouterOS devices in active use now. 4 more which are not used. Time to make backups of their configs…

Setting up ssh keys

scp id_rsa.pub admin@ROUTER:
ssh admin@ROUTER
# Then enter those commands
/user ssh-keys import file=id_rsa.pub user=admin
/file remove id_rsa.pub

Making a config dump

ssh admin@ROUTER "/export compact terse file=configdump.rsc"
scp admin@ROUTER configdump.rsc ROUTER-config.rsc

Impact of Changing 5GHz WiFi Channels

My routers do DFS really well. So well, that they detect radar once in a while (about once per week) where I am pretty sure there is nothing to detect. I found a map of weather radar stations in my area (100km around me) and their frequencies. I should not be able to detect weather radar. I am not anywhere close to their frequencies.

Anyway, I thought changing to channels which do not require DFS might be helpful. But look at this:

Ping latency of 2 WiFi connected PCs, all 5GHz. From 20:00 to 10:00 I used different channels.

So on 4th at about 20:00 I changed from channel 52 which needs DFS, to channel 44 which does not need DFS. I expected nothing to happen minus no false weather radar detection. But what I found was a severe increase of latency. Changing to channel 60 on 5th at about 10:00 made a huge difference.

While I’m at risk of DFS hitting me again,I’d say it’s worth it.

Channels 44, 52 and 60 showed no activity from neighbors. Only channel 36-40 are used as well as some more channels above 100 (see here for lists of available channels and frequencies).

Lesson learned:

  • Not all channels are equal.
  • To find the best channels, run a proper real-world test.
  • Be aware of weather radar. Or DFS. Or both.