Instead of a backup and restore of the VM, it seems the right time to migrate Zabbix and Grafana from an aging RHEL 8 instance to a new VM running a fresh copy of Debian 13. At the same time upgrading the applications to their latest versions…

Zabbix

New Server: Preparation

Begin by installing a LAMP stack on the new server:

apt install mariadb-server apache2 php php-mysql php-bcmath php-mbstring php-xml php-ldap php-json php-gd php-zip curl gnupg lsb-release

Then setup the basic configuration of MariaDB:

mysql -u root

ALTER USER 'root'@'localhost' IDENTIFIED BY 'password';
DELETE FROM mysql.user WHERE User='';
DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');
DROP DATABASE IF EXISTS test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\\_%';
FLUSH PRIVILEGES;

To give it somewhere to migrate to, install a fresh, blank copy of Zabbix on the new server. The latest version can be used and is available on the Zabbix website, as the application will detect and auto upgrade your exisiting data (So long as a direct upgrade path between versions is supported).

As an example with version 7.4, first add the Zabbix repositories:

wget https://repo.zabbix.com/zabbix/7.4/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.4+debian13_all.deb
dpkg -i zabbix-release_latest_7.4+debian13_all.deb
apt update

And install Zabbix:

apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

If following the install intructions from the Zabbix website, stop before starting the service. Instead, we’ll first pull and import the database from the old server…

Old Server: Export database

On the old/source server, temporarily stop Zabbix server:

systemctl stop zabbix-server

Now dump the database to a file. As this old server only ran Zabbix, we’ll dump the whole MySQL instance to preserve users and settings which will make migration easier.

If yours is more complex, dump just the Zabbix database and recreate the users manually on the new server.

Export the whole MySQL instance:

mysqldump -u root -p --all-databases > mysql.sql

When it completes, restart Zabbix on the old server, just incase you’d need another go at it later.

systemctl start zabbix-server

New Server: Import

Back on the new server, pull the exported database locally:

scp root@{old-server-ip}:/root/mysql.sql .

Also grab the configuration files of the old server, it’ll come in handy later:

scp -r root@{old-server-ip}:/etc/zabbix/* .

Import the copied database:

mysql -u root -p < mysql.sql

If importing an “–all-databases” export, the newly added users need to be commited before they can be used.

Note that after executing the below, the root credentials will be overwritten by those of the old server:

mysql -u root -p
FLUSH PRIVILEGES;

Next is the configuration file. I would recommend comparing the old and new /etc/zabbix/zabbix_server.conf files, and updating the new .conf to match the old rather than just copying the file.

nano /etc/zabbix/zabbix_server.conf

Now, its time to start Zabbix:

systemctl enable --now zabbix-server

Checking for any errors can be made by monitoring the log file:

tail -n 100 /var/log/zabbix/zabbix_server.log

Soon after starting the service you’ll notice a database upgrade completing in the file, this is Zabbix automatically upgrading your old data to the newly installed version, neat.

Visit the Zabbix web interface on the new server:

http://{new-server-ip}/zabbix/

You’ll be greeted with the setup wizard, follow the steps on screen to complete.

Don’t worry, Zabbix is running and logging now data to your existing Zabbix hosts, this wizard simply creates the /etc/zabbix/web/zabbix.conf.php file.

Once the wizard is completed, you’ll return to a familiar yet updated interface via the new server.

Zabbix Proxy

If the migration involves a major version change and you’re using proxies, the dashboard will quickly flag a problem with the proxy version being incompatible.

On the proxy, you’ll need to update the application by setting the associated version in the repositories and installing the updated version.

Using a Rocky 8 install as an example, add the updated repo:

rpm -Uvh https://repo.zabbix.com/zabbix/7.4/release/rocky/8/noarch/zabbix-release-latest-7.4.el8.noarch.rpm
dnf clean all

Then install the updated version:

Install
dnf install zabbix-proxy-mysql

Restart the service, and it will be up to date:

systemctl restart zabbix-proxy

Grafana

Migrating and updating Grafana is much the same process as Zabbix, if a little easier.

Install Grafana, on Debian 13 it is available from the main repository:

apt install grafana

Pull the required files direct from the old server to the new:

scp root@{old-server-ip}:/etc/grafana/grafana.ini .
scp root@{old-server-ip}:/var/lib/grafana/grafana.db .

Overwrite the installed files with the ones pulled from the old server, and set the correct permissions:

cp grafana.ini /etc/grafana/grafana.ini
chown root:grafana /etc/grafana/grafana.ini
cp grafana.db /var/lib/grafana/grafana.db
chown grafana:grafana /var/lib/grafana/grafana.db

Before starting, install any plugins used on the old server, for example:

grafana-cli plugins install alexanderzobnin-zabbix-app
grafana-cli plugins install grafana-clock-panel

Now Grafana can be started:

systemctl enable --now grafana-server

And visit the web interface:

http://{new-server-ip}:3000/

Where you can pick up at where you left on the old server.

This would kind of make sense, phones use the RTP protocol for audio is designed for real-time communication and so, naturally sync with each other in a local network.

As a proof of concept, I wanted to create a service that allowed me to “dial-in” to a radio stream on demand…

Initial thoughts was to just to pipe a continuous radio stream to an extension. However, in addition to the waste of bandwidth, any network disruptions would essentially kill the stream without recovery. Therefore, a play on-demand service would help keep the stream fresh whilst saving bandwidth at idle.

My preferred radio for testing is Kerrang radio, I get the URL’s for radio feed via this site and downloading the playlist .pls file, then opening the file in a text editor to extract the actual stream URL.

Baresip Setup

Similar to the earlier project in piping audio from a Raspberry Pi to SIP, a minimal install of Baresip will be used to handle the SIP element and added as a system service in a mostly similar way.

To give the script some context on when to play on demand, we need a log of baresip’s output.

In the service configuration file, under [service] change the following line:

ExecStart=/usr/bin/baresip

to:

ExecStart=/bin/bash -c "/usr/bin/baresip > /path/to/sipaudio.log 2>&1"

This will now run the application and send all output to a sipaudio.log file for processing by the script.

Script

The script will read the log file for any newly established calls and add them to a counter to establish how many calls are active, while the call count is greater than zero, trigger the radio stream.

Similarly, call terminations are also registered and affect the active_calls variable.

The goal is to ensure the stream is only triggered when the first active call is dectected, and only stop the stream when the last remaining call is cleared down.

For example, if Phone A calls in, the stream is triggered and starts playing. Then, phone B also calls in and hears the established stream. If Phone A was to hangup, we’ll need to continue the stream for phone B (i.e not latching to the phone that triggered the stream), but if phone B also hangs up, the stream is stopped as there’s nothing there to listen.

Create the script file and add the following:

#!/bin/bash

# Path to Baresip log file
LOG_FILE="/path/to/sipaudio.log"
STREAM_URL="http://edge-bauerall-01-gos2.sharp-stream.com/kerrang.mp3?aw_0_1st.skey=1736072895"

# Track active calls
active_calls=0
mpv_pid=""

start_stream() {
    if [[ -z $mpv_pid ]]; then
        echo "Starting stream..."
        mpv "$STREAM_URL" &
        mpv_pid=$!
    else
        echo "Stream is already running."
    fi
}

stop_stream() {
    if [[ -n $mpv_pid ]]; then
        echo "Stopping stream..."
        kill $mpv_pid
        wait $mpv_pid 2>/dev/null
        mpv_pid=""
    else
        echo "Stream is not running."
    fi
}

monitor_calls() {
    echo "Monitoring Baresip log for call events..."
    tail -Fn0 "$LOG_FILE" | while read -r line; do
        if [[ "$line" == *"Call established"* ]]; then
            ((active_calls++))
            echo "Call incoming. Active calls: $active_calls"
            if [[ $active_calls -eq 1 ]]; then
                start_stream
            fi
        elif [[ "$line" == *"session closed"* ]]; then
            ((active_calls--))
            echo "Call ended. Active calls: $active_calls"
            if [[ $active_calls -le 0 ]]; then
                active_calls=0
                stop_stream
            fi
        fi
    done
}

# Start monitoring calls
monitor_calls

Make the file executatble with:

chmod +x /path/to/filename.sh

Service

This can be ran via the terminal/SSH, but for ease of use and reboot survival, lets create a service for the script.

Create and edit a service file:

sudo nano /etc/systemd/system/sip.radio.service

Add the following to the new service file:

[Unit]
Description=Kerrang Radio Stream
After=sound.target network.target

[Service]
ExecStart=/path/to/filename.sh
Restart=always
RestartSec=10
User=pi
WorkingDirectory=/home/pi
StandardOutput=journal
StandardError=journal
Environment=HOME=/home/pi
Environment=XDG_RUNTIME_DIR=/run/user/1000

[Install]
WantedBy=multi-user.target

When saved, reload services:

sudo systemctl daemon-reload

Start the service and enable it to start at boot:

sudo systemctl enable --now sipradio

Now a test call can be made to the baresip extension, and hopefully the radio will be though in a second or two.

Summary

Since originally starting this in March, the script and SIP endpoint has been idle for a few months, but seeing if it still works while writing this, the stream fired right up on first asking.

I would like to significantly reduce my “smart” speaker density, as they are almost exclusivley music players at this point due to the frustration in using them for anything else (even playing music is a challenge at times), but are always listening in.

To put this theory into production will require both opus capable phone hardware and decent wired/bluetooth speakers with connectivity inbetween.

I wonder if a Pi Zero W2 could come to a cheap option rescue?

It wasn’t until my most recent visit for an upcoming project that things looked, well, a little different. It was mostly the same, but subtle differences meant it was no longer compatible with how I’d been familiar with setting it up.

Therefore this quick post is to capture the old method of setting it up for posterity.

The below steps are to replicate all MySQL databases on another server.

Prepare MySQL .conf files

To allow MySQL to replicate, the servers must be arranged in a hirarchy and logging enabled so each system can keep track and update any changes made.

The .conf files can be found in the following locations:

/etc/my.cnf.d/server.cnf

Or on newer distros:

/etc/mysql/mariadb.conf.d/50-server.cnf

Source/Master Server

On the source server (server you want to copy from), add the following lines below and within the [mysqld] section:

bind-address            = {local ip address},{remote ip address}
server-id               = 1
log_bin                 = /var/log/mariadb/mysql-bin.log

binlog-format = mixed
sync_binlog=1

Replica/Slave Server

On the replica server (server that databases are copied to), add the following lines below and within the [mysqld] section:

server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
relay-log               = /var/log/mysql/mysql-relay-bin.log
binlog-format           = mixed
read-only               = 1

On both servers, MySQL requires a restart to pick up the config changes:

systemctl restart mariadb

Create a replication user

A replication needs to be authenticated, rather than using the root user its preferred to create a user that is only able to perform the replication.

On the source server, login to MySQL:

mysql -u root -p

Create the user, and give it replication duties with the following commands:

CREATE USER '{replica_user}'@'{replica_ip}' IDENTIFIED BY '{password}';
GRANT REPLICATION SLAVE ON *.* TO '{replica_user}'@'{replica_ip}';
FLUSH PRIVILEGES;

Copy current databases

Before the replication can begin, we’ll need a copy of the existing data captured within a known point of time. This allows the replica to know where to pick up from where the imported databases left off.

Source Server

If not already, log into mysql :

mysql -u root -p

Lock the databases from being able to be written to:

FLUSH TABLES WITH READ LOCK;

Display the current state of the logfiles while the databases are frozen in time:

SHOW MASTER STATUS;

This will produce something similar to this:

MariaDB [(none)]> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000016 |      342 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

Make a note of the File and Position values, we’ll need this as a reference point for the replica. I’d recommend saving it as a file for future reference.

Now, open up new SSH session to the source server. Its important that the current MySQL session is kept open and in its locked state.

Take a mysqldump of the entire database:

mysqldump -u root -p --all-databases > mysql_replication.sql

When this completes, return to the original session to return the databases to normal:

UNLOCK TABLES;

Transfer SQL file to Replica

Move the generated mysqldump file to the replica server, I usually transfer the master status txt file too for future reference:

scp mysql_replication.sql mysql_master.txt root@{replica_ip}:/root/

Setup Replication

Import the newly transferred file to the replica’s MySQL:

mysql -u root -p < mysql_replication.sql

Then log in to MySQL:

mysql -u root -p

Time to setup the replication, using the replica user setup previously, and the logfile positions captured during the mysqldump. The SHOW MASTER STATUS; output from above is referenced in this command example:

 CHANGE MASTER TO MASTER_HOST='{source_ip}', MASTER_USER='{replica_user}', MASTER_PASSWORD='{password}', MASTER_LOG_FILE='mysql-bin.000016', MASTER_LOG_POS=342;

Reference points now in place, start the replication process:

START SLAVE;

You can check it is running with:

SHOW SLAVE STATUS\G;

In the output you’re looking for Slave_IO_Running and Slave_SQL_Running to both be Yes:

With both reporting Yes, the replication is running. All changes made to the source server is automatically pushed to the replica.

Notes

Ports

The two databases communicate over its MySQL port, default is 3306. Ensure that both servers are able to communicate on this port.

Authentication

Immediately after setting up replication, you’ll be able to log in to the replica server as normal. However, if the service/server was to be restarted you may not be able to login as normal.

As this guide replicates everything on the source MySQL, it will also replicate the users and permissions.

Following a replication start, the “old” credentials are still usable But following a service restart, the credentials of the source are the new normal on the replica, and should be used for any future login.

This will also apply to any instances of phpMyAdmin.

I’d like the KVM guests to access the network in bridge mode of the host for direct access to the network. However I faced the following issue:

• KVM host can ping gateway and internet.
• KVM host can ping the guest.
• Guest can ping the host.
• Guest cannot ping gateway or anything outside of the host.
• Guest is showing in router ARP table, with its IP address and own MAC

This one got me for more time than I wish to admit, and seems to have caught others out along the way, this is how I finally solved it…

This test setup has the following parameters:

• Network: 10.0.4.0/24
• Internet Gateway: 10.0.4.1
• KVM Host: 10.0.4.100
• GuestL 10.0.4.101

Install KVM and Cockpit

Install KVM and Cockpit (For easy access and testing of a guest):

apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst cockpit cockpit-machines

For Debain 12, Cockpit blocks login from root, remove it from the disallowed-users file:

nano /etc/cockpit/disallowed-users

Restart Cockpit to take changes:

systemctl restart cockpit

Cockpit’s web interface can be accessed via port 9090 of the host IP.

https://10.0.4.100:9090/

Host Network

Now bridge-utils is installed, the bridge can be configured on the host:

nano /etc/network/interfaces

Remove / comment out the physical interface config and add the new bridge br0:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet manual
        #address 10.0.4.100/24
        #gateway 10.0.4.1
        # dns-* options are implemented by the resolvconf package, if installed
        #dns-nameservers 10.0.4.1
        #dns-search debian-kvm.james-batchelor.local

auto br0
iface br0 inet static
        address 10.0.4.100
        netmask 255.255.255.0
        network 10.0.4.0
        broadcast 10.0.4.255
        gateway 10.0.4.1
        bridge_ports ens192
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
        dns-nameservers 1.1.1.1
        hwaddress ether 00:0c:29:3a:bc:72
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward

NOTE: Add the hwaddress line and use the mac address of the physical interface, otherwise you’ll loose connection to the host when networking is restarted.
NOTE: For my solution, IP forwarding needs to be enabled.

Restart networking service, cross your fingers:

systemctl restart networking

Guest setup

Create folders for the guests:

mkdir /vm
mkdir /vm/iso
mkdir /vm/datastore

This issue got me for a while, so for testing I refined the process down to using a System Rescue cd for quick VM spin ups. Download the ISO:

wget https://fastly-cdn.system-rescue.org/releases/11.01/systemrescue-11.01-amd64.iso -P /vm/iso/

Now create the VM from the CLI:

virt-install --name vm-test --ram=8192 --vcpu=4 --cpu host-passthrough --disk path=/vm/datastore/vm-test,size=8 --cdrom /vm/iso/systemrescue-11.01-amd64.iso --os-variant linux2022 --network bridge=br0,model=virtio --graphics vnc

Now you can move to Cockpit to view and configure the guest from its console.

Guest Networking

Lets take a second to think about whats happening when a guest pings the network; It has to leave through the host in order to get to the gateway, as the ARP table has has the correct details for the guest (including guest’s actual MAC), the ping reply will be send to the guest but needs to go through the host first.

Therefore a static route is needed to steer traffic for the guest through the host. On the router, create a static route:

Via Cockpit, access the console of the System Rescue OS, enter the network config via:

nmtui

Navigate to edit a connection, and select the Wired Ethernet Connection, set IPv4 configuration to Manual and add the details:

• IP address: IP address you set as the destination of the static route.
• Gateway: IP address of host.

Select OK at the bottom of the screen to confirm config, go back to the main menu.

TIP: Navigate to Activate Connections and toggle the interface off and back on, as otherwise there is a lag before the config is applied to the network.

Test with pings from the guest and to it from other machines, they should now respond.

Now attention turns to its predecessor, the Draytek 2762. For many the 2762 may still be in use as a dependable unit and offers more or less the same feature set of the newer units. But, does it have enough grunt to support the higher speed profiles that full fibre internet offers, and will its hardware acceleration help boost its potential?

For the test I’m using a 2762ac running the latest 3.9.7_BT firmware. As before, the throughput is measured with iPerf3 on a Windows machine with two NICs, MTU on WAN2 is set at a constant 1492.

Out of Box

Starting with a factory configuration, WAN2 was enabled and set to use a dynamic IP.

Quoted throughput is 400Mbps, however in this test I could only achieve 361Mbps:

Hardware Acceleration

While hardware acceleration is available for this generation of router, Draytek seemed to shy away from announcing or advertising. This seems odd as the single line in the spec sheet states that throughput of 900Mbps could be achieved with it on, albeit with some caveats such as a loss of traffic graphs and the monitor page.

Still running an out of box config, HW ACC was enabled to auto. Subsequent tests yielded around 923Mbps:

Granted, this test using iPerf3 is very simple creating a single session on an otherwise idle router, real world applications may have an impact on its performance.

Next, I thought to apply a basic setup on the router to see if this has an impact, consisting of remote access with 3 ACL entries and SNMP v2 enabled.

Following a reboot, on the next test speeds were back down to a pre-accelerated ballpark of 340Mbps:

Thinking that HW ACC was set to auto was the issue, I manually assigned the LAN side client to be in the scope of acceleration, yet speeds remained in the low 300Mbps.

For a sanity check, acceleration was set back to auto and the basic config setup reversed, returning it to a config where 900Mbps was achieved. Yet speeds did not improve.

At a complete loss, it was factory booted and again setup with the bare minimum of WAN2 and auto acceleration enabled. Speeds returned to 900Mbps. Yet, again the addition of ACL and SNMP brought speeds back down to non-accelerated levels.

Below is before and after the basic config:

Note: Summary speeds are at a lower 840Mbps as a click of the “OK” or “Submit” button on the web GUI causes the router to drop packets until config is saved.

Summary

If you’re looking to get more out of a Draytek 2762, I’d only expect it to reliably achieve a throughput of 330Mbps over WAN2.

While hardware acceleration is an option and can at times offer 950Mbps under sterile conditions, its implementation puts you in a precarious position where the next config change could more than halve the throughput. With only a factory reboot being the only resolution.

Draytek’ s current portfolio offers 950Mps NAT throughput on Ethernet WAN ports, let’s see if that is theoretical or expected.

The test will use a 2763ac running firmware 4.4.3_BT

Hardware Acceleration

The key point on Draytek’s spec sheet for WAN2 throughput is the 950Mbps can be achieved with hardware acceleration enabled.

Hardware acceleration has been an option on Draytek for many years, however historically enabling this came with caveats ranging from the loss of data flow statistics to a reduction in firewall effectiveness.

Out of the box with FW 4.4.3 hardware acceleration is enabled, either Draytek is confident it has matured enough to be able to fit around most users’ requirements, or it needs to be enabled in order to keep the product as a viable product.

Test – HW Acceleration On

Using just enough configuration to get it “online”, WAN2 was enabled for dynamic IP mode.

Test performed on a single machine using iperf3, one NIC port plugged into WAN2 via a switch, other port into LAN1.

Average throughput on 60 second test: 929Mbps

Test – HW Acceleration Off

For those still dubious about HW acceleration on these devices, it was disabled and test re-run.

Average throughput on 60 second test: 541Mbps

QOS

For final test I thought to load it with a standard setup with HW on, not complex but included SNMP, TR-069, ACL lists on management interfaces, I also chucked in 4 VLANs and a few firewall rules.

Two observations here:

In my usual setup I add software-based QOS, this took average test speeds down to 423Mbps.

Second note and may be a quirk, when adding the VLANs and sending router for reboot, the router entered a reboot loop, resolved only by physically cycling power, meaning I lost the error codes for any potential diagnostics.

Switching to HW QOS, test speeds remained excellent at 946Mbps average.

Summary

If you have no concerns around hardware acceleration, the 2763/2765 does what it says on the tin with a typical config. Your mileage will vary especially dependant on the number of NAT sessions it has to deal with in the real world but these tests are certainly promising.

Difference between 2763 and 2765

These units are essentially the same, but as the 2763 is exclusive to the UK you’ll likely find greater stock availability for these over the 2765.

The only difference relates to a chipset for the VDSL on WAN1, the chipset in the 2763 conforms to UK standard VDSL2 but falls out of spec for some European countries where VDSL2 35b code is used. This stemmed from the chip shortage of a few years ago and the alternative chipset was used to boost availability.

Source: https://www.draytek.co.uk/our-solutions/videos/draytek-webinars/vigor-2763-series-new-product-information

Finding more uses for these Pi’s necessitates moving to Raspbian with MotionEye as the OS version is very bare bones by. Moving from the OS also means losing the Fast Network Camera and streams on the network jump from 2 Mbps to 25 Mbps.

Over multiple camera’s this really adds up, so I need a way replicate the low bandwidth, high quality streams with the versatility of Raspbian. The solution found is to install MediaMTX (formally rtsp-simple-server) …

This guide is based on a Raspberry Pi 3 board and using a Pi Camera Module v2.1. The micro SD card has a new install of Raspbian Bookworm 32bit.

Install

Logging in via SSH, run an update to have the latest repo’s available…

sudo apt-get update

Using MediaMTX with the Raspberry Pi camera module requires a couple of libraries, install or upgrade them

sudo apt-get install libfreetype6 libcamera0

MediaMTX can now be downloaded. Which version you use depends on Raspbian version and Pi used. For 32bit versions of Raspbian use the “armv7” variant, and “arm4” for 64bit. To check which one is running…

uname -m

32bit versions will respond with armv71 and 64bit with arm64.

Visit https://github.com/bluenviron/mediamtx/releases for latest versions and download links.

Copy the link and enter in the terminal with wget prefix, below example I’m using a 32bit version…

wget https://github.com/bluenviron/mediamtx/releases/download/v1.2.1/mediamtx_v1.2.1_linux_armv7.tar.gz

Extract the files…

tar xzvf mediamtx_v1.2.1_linux_armv7.tar.gz

Of the files extracted, mediamtx is the binary and mediamtx.yml contains its configuration.

Config and Test

Firstly edit the yml file so it uses the Pi camera

nano mediamtx.yml

Scroll to the bottom of the file, replace the following lines of code at the end of the file…

paths:
  # example:
  # my_camera:
  #   source: rtsp://my_camera
  # Settings under path "all_others" are applied to all paths that
  # do not match another entry.
  all_others:

With the following…

paths:
  cam:
    source: rpiCamera
    rpiCameraWidth: 1280
    rpiCameraHeight: 720
    rpiCameraVFlip: true
    rpiCameraHFlip: true
    rpiCameraBitrate: 1500000

Notes:

• YML files require the indentation.
• cam: – this will be included in the path when accessing the stream.
• rpiCamera… – These are extra settings that can be specified, for example the VFlip and HFlip are due the camera being mounted upside down, a full list of options are included further up in the file.

I also took this opportunity to disable all other protocols, just leaving RTSP on. When finished editing, Ctrl O and Ctrl X to same and exit.

To test this config, run the binary…

./mediamtx

While running, this can be tested using VLC on another computer on the local network, open a network stream and enter the following, replacing {ip address} with the IP of the PI….

All well and the camera output appears.

Use Ctrl C to stop the program, as we can now add it as a service.

Add as Service

To allow it to start automatically and for easier control of it the program can be created as service. To start let’s move the files to a safer directory…

sudo mkdir /opt/mediamtx
sudo cp mediamtx /opt/mediamtx/
sudo cp mediamtx.yml /opt/mediamtx/

Create a new service file for editing…

sudo nano /etc/systemd/system/mediamtx.service

and add the following…

[Unit] 
Wants=network.target
[Service] 
ExecStart=/opt/mediamtx/mediamtx /opt/mediamtx/mediamtx.yml
[Install] 
WantedBy=multi-user.target

Ctrl O and Ctrl X to same and exit.

As it’s a new service file, need to reload systemctl…

sudo systemctl daemon-reload

Now can start the service and enable at the same time so it starts when the Pi starts…

sudo systemctl enable --now mediamtx

To check its running, use the following

sudo systemctl status mediamtx

Should get the following…

Now you can access the stream again via VLC, or add as a network camera to a MotionEye setup.

Results

To goal of this exercise was to reduce bandwidth on the network and return to similar levels observed when using MotionEyeOS while using a Raspbian OS.

Below are iftop comparisons while a camera stream is open and at 1280 x 720.

Using MotionEye, with http connection to a MotionEye server:

Using MediaMTX streaming via RTSP to VLC:

Considerations

While searching for a solution I tried StreamEye, a simple program written by the same developer as MotionEye.

While a very easy program to get up and running and it offered features close to “Fast Network Camera” on MotionEyeOS, the pure MJPEG stream resulted in approx. 40Mbps bandwidth utilisation on a 720p stream.

The main compromise in choosing this was that it offered “near silent” operation by only spinning the fans when needed, compared to other switches where fans are on permanently.

Trouble is, when the fans do spin on the GS324TP they are audibly intrusive, whether brand new or a few months in they sound like the bearings are failing with a knock that matches the RPM, deploying four of these units previously with the same harmonics suggest it’s not a one off.

This isn’t good news when I intend to work a few feet from the switch, but from testing before the latest deployment, there’s a couple of ways to keep the GS324TP near silent…

Installing out of the box with firmware 10.0.0.38, the fans cut in for approx. 5 minutes, every 10 minutes. In close quarters this can be unbearable, as either the fans are disturbing, or you’re waiting for the fans to kick in and disturb you.

There’s not a lot of conversation on this unit, as it gets lost with many Netgear units suffering from the same low-quality fans. But a useful post suggests that heat soak while the fans are off is a contributing factor in the frequency of the fans spinning up.

To counteract this, let’s get a high-quality quiet fans to get some airflow through the case alleviate the factory fans.

Replacing the factory fans could be an option but for two issues; first the warranty, second finding a suitable replacement is difficult due to the signalling pin / speed pin which when wrong results in the fan light illuminating or the new fans not spinning at all.

POE Cooling

The alternative plan is to mount a high-quality quieter fan externally to push out the heat inside the case before the factory fans get called upon.

The fan of choice is a Noctua NF-A4x20 FLX, reused from a failed attempt to fan swap a Netgear JGS516P where this replacement didn’t spin.

As it’s a POE switch, POE would be a convenient power source for the external fan. It gives a more self-contained solution and more the operation of the fan can be toggled on/off via the web GUI of the switch by controlling the power to the port.

A POE to 12V splitter was purchased to negotiate power to the fan.

Modifications

Opening up the POE splitter, it’s lucky for the output ports to be socketed and the power delivery and ethernet elements separated;

Screw located under the label…

Make a note of the polarity of the power output, then remove the power and ethernet connectors…

To connect the fan, I used a coupe of male to female jumper cables to extend the cables outside the splitter case. The connecters would have sat proud of the case, so removed the connectors and replaced with shrink tubing.

Connecting to the fan, I replaced the two single pin headers with a three-pin header in a crude attempt to key to the fan socket, bypassing the sense pin.

After testing, the Noctua NA-RC12 was added to reduce speed and increase silence.

Mounting

To mount the fan externally to the case, a 3D printed bracket holds the fan to the case opening via the rackmount screws. Positioning of the fan is towards the back of the inlet vent, after experimentation there’s no benefit in having the fan pass directly over the PSU and heatsink, so chose to route airflow round the back of the unit to create an airflow.

STL for the mount is available here.

Results

During one of the hottest weeks of the year, temperatures while the Noctua fan was on averaged 47-49 Celsius, keeping it below the 51 degrees threshold where the factory fans kick in on firmware 10.0.0.38.

For reference, ambient reached around 30 Celsius for most of the day as noted by the thermostat…

Even though the Noctua fan speed was at its minimum, it was still noticeable, if this too is a concern, recent firmware can offer a solution…

Firmware

Firmware 10.0.0.38 from the release notes purports to start the fans at a lower temperature and at a lower speed. Translated the fans start when a temperature reaches 51 Celsius, spinning at 30% / 1800rpm until temps reduce to 45 degrees.

An earlier 10.0.0.30 firmware was released seemingly to deal with trigger happy fans. With this version fans don’t start until 60 degrees, where they run at 50% duty, although above 51 degrees a warning label is shown on the GUI, but that’s all.

Switching to this, temps stay between 57 – 59 degrees when ambient is reaching 27 which for me is at the peak of summer, negating the need for the external cooling solution but it’s nice to have as a backup, and more importantly keeping it completely silent.

Update: Dec 2022

With the exception of unseasonably hot summer heatwaves, I’ve not needed to think about the cooling of the switch. With the home heated to 18 degrees Celsius in winter temps on the highest sensor is at 54C suggesting this is the range it normally operates at and without the warning on firmware 1.0.0.30.

As we expand there is greater need for international connections, this is fine if they have a static WAN IP or FQDN, but the more recent requirements are for “home” users with phones on their residential connections where dynamic IPs are the standard.

Changing the whitelisted IP every time their IP changes is not only tedious, but gives poor service, plus due to recent events (here and here) I’m not prepared to open access to another country for a single extension.

In my case, these internationals are satellites of a UK based office, so the idea is having the overseas phone route all voice traffic through the UK office where its free to connect to the PBX…

For this setup, a Yealink T46S will connect to a Draytek 2927 via OpenVPN and crucially, route all traffic destined for the PBX via the VPN to get around the GeoIP block.

This guide should also be compatible with the Draytek 2865, and Yealink T4xS and T4xU series phones.

Notepad++ and 7zip are required.

Draytek Setup

Original Guide: https://www.draytek.com/support/knowledge-base/7462

First create a user for the Yealink, at the router GUI navigate to: VPN and Remote Access >> Remote Dial-in User.

Click an Index number and make the following changes:

• Enable this account: On
• Allowed Dail-In Type: OpenVPN Tunnel: On
• Username: Enter a username
• Password: Enter a password

It should look like this:

Next is to setup the Draytek to accept OpenVPN connections.

Navigate to VPN and Remote Access >> Remote Access Control. And check OpenVPN is enabled.

Then navigate to VPN and Remote Access >> OpenVPN >> OpenVPN Server Setup.

In the General Certificates section, select Router Generated Certificates, and then press generate.

After some time, the generated certificates appear in this section:

OpenVPN Setup

The Draytek has the ability to create an OpenVPN config file for clients. However, what the Draytek generates and what the Yealink requires is not compatible. Therefore, we’ll need to manipulate the file to file to get what we want.

Extracting Certificates

On the Draytek, navigate to Remote Access >> OpenVPN >> Client Config.

Leaving defaults in place, enter a filename and click the Export button to download the config file.

Open the file in Notepad++.

You’ll see the protocol config at start of file, followed by each of the certificates in the following order:

1. CA
2. Client
3. Private Key

The Yealink requires the certificates in their own file so they need to be extracted.

Copy the text from —–BEGIN CERTIFICATE—– to —–END CERTIFICATE—– of the first certificate and paste into a new Notepad++ file.

Save this file as ca.crt (remove the txt file extension)

Repeat this for the second certificate, naming this one client.crt

Now it’s the private key, copy text from —–BEGIN RSA PRIVATE KEY—– to —–END RSA PRIVATE KEY—– to a new file and save as client.key

Config files

For the next file, you’ll need to add the Draytek VPN user details as a file to allow the Yealink to authenticate.

In a new text file, enter the username and password on separate lines as below:

Save the file as auth.txt

You’ll now have the following files:

With the supporting files ready, it’s time to reference them together with the OpenVPN config file.

In a new text file, enter the following info:

client
dev tun
proto udp
remote nnn.nnn.nnn.nnn 1194                  # IP address of Draytek
auth sha256
cipher aes-256-cbc
resolv-retry infinite                        # Reconnect if dropped
nobind

ca /config/openvpn/keys/ca.crt
cert /config/openvpn/keys/client.crt
key /config/openvpn/keys/client.key

auth-user-pass /config/openvpn/keys/auth.txt

persist-key
persist-tun

route nnn.nnn.nnn.nnn 255.nnn.nnn.nnn nnn.nnn.nnn.nnn  # Static route:
                                                       # PBX IP
                                                       # IP Subnet
                                                       # Draytek LAN Gateway
verb 5

Save this as vpn.cnf

Preparing Yealink File

Original Guide: https://support.yealink.com/forward2download?path=ZIjHOJbWuW/DFrGTLnGypjZRKhDplusSymbolXJQ4JaUSvKXmAoZw0rMev5uUPSPDoclfqojerLoiDU/Ol0NW5DZdXcWplusSymbolZDNbde0dvqwZjDVChAjsaqHDjPW14991UaBvXhQ10P6Rm4u3tO4pNBqXRzzyvj9PbA==

The OpenVPN configuration is uploaded to the Yealink via a specifically arranged tar file, so the directory structure needs to be prepared.

On your desktop, create a new folder (named anything you like) and within this folder create another named “keys”

Move vpn.cnf to the upper folder, and move auth.txt, ca.crt, client.crt and client.key to keys directory.

Open 7-Zip and navigate to the newly created folder:

Highlight vpn.cnf and keys, right click and choose 7-Zip >> add to archive.

Ensure the following is set:

• Archive format: tar
• Compression level: Store

Click OK to create the file. The tar file is created in the directory and it’s ready to be uploaded to the Yealink

Yealink Setup

On the phone, press the OK key to discover it’s IP address, then navigate to it’s Web interface via a browser on your computer.

Login, then move to Network >> Advanced and scroll down to the VPN section.

Set Active to Enabled and set Mode to OpenVPN

Click browse next to Upload VPN Config and choose the created tar file.

Click Upload, the page will refresh and now Upload VPN Config is populated with vpn.cnf

Click Save at the bottom of the page.

OpenVPN will be set back to Disabled, scroll down and Enable it again, then click Save.

As there’s a network change pending, you’ll need to click apply at the warning message:

It’ll now connect to the VPN.

Note: If you are configuring a phone remotely, the web page will stop responding as traffic is now passing through the VPN. To get back to the interface, check the Draytek for the VPN connection (VPN and Remote Access >> Connection Management) to discover it’s local IP:

The phone is now connected and routing traffic via the VPN.

In newer Draytek models the perceived performance of wireless as been lacking based on earlier models such as the rock solid 2860n/plus with reduced range and throughput speeds, in particular poor VoIP performance for my industry.

This could be down to the passage of time and how WiFI has become even more ubiquitous, in demand and ultimately a more congested radio band. Regardless an alternative solution needs to be explored.

Previous dabbling with deployment of Unifi access points have yielded trouble fee results, so this would be a quick win. Trouble is, the default AC-Pro and AC-LR are in serious supply shortages at present. Wifi 6 variants have better stock availability but also have a higher purchase cost.

The only Unifi AC product that is plentiful is the NanoHD, so in desperation lets see if it is a justifiable upgrade to the Draytek offering…

Test Environment

There’s nothing scientific about the test setup here, I’m currently using a Draytek 2927ac for WiFi so will switch all home wireless traffic over to the Unifi AC-Nano (by cloning SSID and PSK) and observing any changes.

I’ll keep the Draytek radio’s active during use of the Nano, adding a ‘_D’ to the SSID to differentiate the devices for testing. This will also add a bit of competition on the radio spectrum that is now commonplace.

Location

The competing devices are placed within a foot of each other to give an accurate range comparison, I’ve chosen to suspend mount the Unifi as research suggests the antenna’s in the unit are somewhat directional.

As this is mounted on a fixture on the ground floor, I’d be interested on discovering WiFi performance on the first floor, ultimately to discover how directional the antenna’s are.

As mentioned, both Draytek and Unifi units will be broadcasting SSID’s and within a foot of each other, chosen as a worst case scenario of how each compete / compare in the radio spectrum (auto channel enabled on both).

Test Equipment

For simplicity, its a Samsung Galaxy Note9 using speedtest.net app, connecting to the same test server each time.

Test One

First test is an indoor line of sight, test phone is approx 25 feet away from the access points but still in line of sight.

Unifi:

Draytek:

I wouldn’t expect this to be a struggle, but both results were far shy of the available 550Mbps download bandwidth, however this could be down to the test server as it was kept as a constant. Upload reached full utilisation at 75Mbps.

Draytek wins this round.

Test Two

Relatively speaking I have a home that’s easy for Wifi, small and of traditional brick construction. To create a bit of a challenge for comparison the next will be from outside and within the car sitting on the drive, approx 50 foot distance

Unifi

Draytek

Something I’ve noticed during testing is the Unifi does seem to offer a better range over the Draytek, giving better bars / RSSI on the fringes of my network.

Results are pretty even, but from a VoIP perspective the latency and jitter under load is way too high to support real time media.

Test Three

More of a real world test, I have a Raspberry Pi Zero running in a garden shed running off a solar panel and 12V battery. The Pi Zero WiFi antenna is self contained on the chip, being a challenge to an access point to create a reliable connection to it from a distance.

The AC-Nano was installed on 9th June, although the ping times don’t show much of an improvement.

Summary

The results were disappointingly similar considering adding AC wireless to a Draytek router is around £40, compared to the £130 in buying the NanoHD (before required controller / Clouldkey).

Yes the NanoHD is not the most suitable product for the testing, but as mentioned this is the only one that has plentiful stock at the moment.

From testing, the Nano seems to advertise a better signal to devices than the Draytek, so ‘devices’ such as my car can pick up Wifi on the Nano where the Draytek could not.

But on comparison, this signal increase does not yield better throughput, devices that pick up the Draytek get more or less the same, with the Draytek advertising a greater speed.

From a VoIP perspective, where both pushed over 1 second latency on upload at load, neither can be considered a solution. I understand that a speedtest.net test aims to utilise all available bandwidth, but in real world scenarios, there nothing to stop any other application acquiring all available bandwidth during normal use and negatively affecting voice traffic at the same time.

Finally if you were wondering, suspending the NanoHD then using a device “behind” it (i.e above its location) worked fine.

Update: August 2021

Since initial testing I ended up reverting back to the Draytek for Wifi, as performance was the same and saved on powering another device. However I’ve now sourced an AC-Pro and replaced it in the same location as the NanoHD.

Performance with this model is improved, not so much from increased speed or reduced jitter but whats noticable is the reliability of devices on the fringes of range.

Below is a recent graph from the Pi Zero:

Its clear to see the AP-Pro’ installation on 9th Aug by the lowered ping times.

Its not perfect however as seen with the spikes, however am starting to suspect this is lining up with my activity in having other Wifi devices (laptop, mobile) in the same vicinity or between the Pi and Pro is causing these spikes.

If time permits I’d would like to revisit this compare the AC-Pro and NanoHD side by side, but for the original brief of is a NanoHD better than a Draytek, the answer is No.