Joseph Zikusooka ~ Zik

A software engineer specializing in open source technologies | Very experienced in building and configuring UNIX/Linux systems and servers. Passionate about developing software applications and hardware for the smart home | Currently serving as the CEO of Jambula Labs and the project leader at JambulaTV, a smart home automation and entertainment platform - | This blog focuses on the following areas: Linux How-Tos and Tutorials ::: IT Security News ::: Free and Libre Open Source Software ::: Smart Home Software ::: Digital Innovations in East Africa |

Year: 2021

How to monitor the presence of nearby WiFi devices using Icinga2


I recently published a Python based plugin for Icinga and Nagios monitoring platforms that monitors the presence of wireless devices in the vicinity.

I really like the stability and reliability Icinga provides when it comes to monitoring the state of hosts or services. There are so many software applications that let you do this, including one I talked about a while back called trackerjacker:

Why this way?

At first trackerjacker seemed like what I needed to do this sort of thing, but after several months of testing one issue persisted. The performance hit whenever I started the process was huge. The server, would frequently slow down, as packet capturing and monitoring of WiFi devices took place. So I decided to ditch this tool, and write my own plugin.

I am already using icinga on the server, so I figured, rather than write another app for polling, why not use the existing and well performing icinga2 monitoring software. After all, I had done this with bluetooth devices earlier and presence detection was working so well.


You are running a Linux based server with Icinga2 monitoring software installed, configured and working properly. There are several articles about how to install and configure icinga2 including the official documentation at:

The heavy lifting i.e. scanning is done by the Wireshark based CLI tool ‘tshark’. Therefore, ensure that Wireshark is installed on your system. Also, a separate wireless interface that supports monitor mode is required

To capture packets as a non-root user, run the following command in your terminal:
sudo setcap cap_net_raw,cap_net_admin+eip $(which dumpcap)

If you’re still having trouble capturing packets as a non-root user, check out the following Wireshark wiki page:

You will need to identify the MAC address of each wireless device you plan on monitoring. For phones for example, this information is in the Settings >> General >> About >> WiFi Address for iOS. For Android, go to Settings >> About >> Status >> Wi-Fi MAC address

NOTE: Some phones like the iPhone may have MAC randomization enabled, which makes it difficult to reliably monitor their presence status

Setup Icinga2 plugin

Download icinga2 monitoring plugin named ‘check_tshark’ from my Github page at:

Alternatively, you can clone the entire repository and check out my other plugins too:

git clone

Copy the icinga2 plugin i.e. check_tshark to your icinga2 monitoring plugins directory e.g. /usr/lib64/nagios/plugins/

cp -v check_tshark /usr/lib64/nagios/plugins/

Configure Icinga2

Add new check and event command objects to icinga2 i.e. Add and save the following snippets to the file:

object CheckCommand "tshark" {
        import "plugin-check-command",

        command = [ PluginDir + "/check_tshark" ]

        arguments = {
object EventCommand "wifi-tshark-status-event" {
  import "plugin-event-command"

  command = [ SysconfDir + "/icinga2/scripts/" ]

  env = {
    "HOSTALIAS" = "$host.display_name$",
    "HOSTADDRESS" = "$address$",
    "HOSTSTATE" = "$host.state$",
    "HOSTSTATEID" = "$host.state_id$",
    "HOSTSTATETYPE" = "$host.state_type$",
    "HOSTOUTPUT" = "$host.output$",
    "HOSTDISPLAYNAME" = "$host.display_name$",
    "LASTHOSTSTATE" = "$host.last_state$",
    "LASTEHOSTSTATEID" = "$host.last_state_id$",
    "LASTHOSTSTATETYPE" = "$host.last_state_type$",
    "LASTHOSTSTATECHANGE" = "$host.last_state_change$",
    "LASTHOSTCHECK" = "$host.last_check$",
    "LONGDATETIME" = "$icinga.long_date_time$",


Add new host templates to icinga2 i.e. Add and save the following snippets to the file:

template Host "event-tshark-status" {
  max_check_attempts = 6
  check_interval = 30s
  retry_interval = 5s

  check_command = "tshark"

  enable_event_handler = 1
  event_command = "wifi-tshark-status-event"

  enable_flapping = 1
  flapping_ignore_states = ["Critical"]

Finally add the wireless devices you want to monitor to the hosts in icinga2 i.e. Add and save the following snippets to the file:

NOTE: In addition to the MAC address, make sure you specify the WiFi interface used for monitoring

object Host "Phone_Zik" {
  import "event-tshark-status"
  vars.tshark_interface = "wlan1"
  vars.tshark_timeout = 10
  vars.tshark_address = "xx:xx:xx:xx:xx:xx"

object Host "Phone_Shushu" {
  import "event-tshark-status"
  vars.tshark_interface = "wlan1"
  vars.tshark_timeout = 10
  vars.tshark_address = "xx:xx:xx:xx:xx:xx"

Optional: Add Alert notification using MQTT

In order to send alerts whenever a WiFi device appears or disappears, you will need to set up a MQTT broker server. I personally use mosquitto on Fedora Linux. For detailed instructions on how to setup mosquitto on Fedora Linux, check out this how to:

Since, we have already enabled event handling for our monitored devices in icinga2, all that is left is to add an event script that will be triggered by the HOST state of either UP or DOWN. Here’s an example:

Create the following script and make it executable:

cat > /etc/icinga2/scripts/ <<ET
# Variables
TSHARK_MAC_ADDRESS=$(echo "$HOSTOUTPUT" | grep -oP "(?<=\[).+?(?=\])")
MQTT_PUBLISH_OPTS="--quiet -h -p 8883"
# Quit if type of state alert is 'SOFT'
[[ "$HOSTSTATETYPE" = "SOFT" ]] && exit 0

# Publish status via MQTT
if [[ "$HOSTSTATE" = "UP" ]];

chmod 755 /etc/icinga2/scripts/

To check your configuration and that all syntax is correct; run the following command:

icinga2 daemon -C

If all’s OK, restart icinga2 as follows:

systemctl restart icinga2


Next, log into your icinga2 web interface (if you have this setup) and ensure your devices are reporting correctly.

In order to monitor alerting via MQTT run the following command in a terminal:

mosquitto_sub -v -h JambulaTV -p 8883 -t "JambulaTV/#" --insecure  | grep presence

That’s all for now. Until next time!

How to automatically backup your data to an external USB disk on Linux


One of the most critical roles that any Systems Administrator must perform on a regular basis is that of running backups for an organization. These days, most big and medium sized offices use Network Attached Storage servers to quickly perform backups on their networks. However, for small offices with limited IT budgets, a DIY solution which uses a simple USB external hard drive is a viable option.

In this setup, the resident “IT guy” is assigned the task of backing up data. This could be from a handful of desktops/laptops, or a central backup server. However, the problem with this setup is that they often will forget to plug in the disk or even initiate the manual backup process, leading to a very unreliable backup scheme.

In this article, I will guide you on how to set up a cheaper, reliable and automated backup scheme. All the operator has to do is to plug in the USB external hard disk any time, and the backup process commences immediately.

This solution takes advantage of a bash script that is triggered once the USB hard disk is inserted into the computer desktop or laptop’s USB ports. The trigger mechanism is handled by udev rules via a systemd unit as will be shown below.


Operating system: Linux
Desktop: GNOME – mainly for notification purposes
Username: erica (Must have permissions to run ‘sudo’)
Data: /home
Partition is NOT encrypted. See ‘cryptsetup’ tool

Create the following backup script. Save it and make it executable:

vim /opt/
chmod 755 /opt/

# Variables
# Excludes 4 /home

# Functions
notice () {

disable_automount () {
su -l $NORMALUSER -c "dbus-launch gsettings set automount false"
su -l $NORMALUSER -c "dbus-launch gsettings set autorun-never true"

sync_data () {
sudo rsync $RSYNC_OPTIONS --delete "$1" "$2"

mount_partition () {
# Create mountpoint if it does not exist
[ -d $MOUNTPOINT ] || mkdir -p $MOUNTPOINT
# Mount drive
if [ "$STATUS_MOUNT" != "0" ];
exit 1

backup_thinkpad () {
# Create backupdir directory

# Start of backup
notice "Backup Started"

# /home
sleep 3
rsync $RSYNC_OPTIONS --delete --exclude-from=$EXCLUDE_FILE_4_HOME_DIR /home/ $MOUNTPOINT/home/

# other partitions

umount_partition () {
if [ "$STATUS_UMOUNT" != "0" ];
notice "ERROR: umount $USB_DISK_PARTITION failed"
exit 1

enable_automount () {
su -l $NORMALUSER -c "dbus-launch gsettings set automount true"
su -l $NORMALUSER -c "dbus-launch gsettings set autorun-never false"

# Process the following routines

# Notice of completion
sleep 10
notice "Backup completed successfully"

Start/Stop service

Create the systemd unit file:
/etc/systemd/system/backup-usb-disk.service and add the following:

Description=USB Portable Drive



Reload systemd daemon i.e. ‘systemctl –system daemon-reload’
It is not necessary to enable or start the above unit at this time
since that will be done by the udev rule below.

UDEV rules

Create the udev rules file: /etc/udev/rules.d/97-backup-usb-disk.rules and add the following:

ACTION=="add", ATTRS{idVendor}=="0bc2", ATTRS{idProduct}=="2400", SYMLINK+="disk/by-id/$env{ID_NAME}_$env{ID_SERIAL}", RUN+="/usr/bin/systemctl start backup-usb-disk.service"

ACTION=="remove", ATTRS{idVendor}=="0bc2", ATTRS{idProduct}=="2400", RUN+="/usr/bin/systemctl stop backup-usb-disk.service"

To find your USB disk Vendor and Product ID, run the command:

udevadm info -a -p $(udevadm info -q path -n /dev/sdX) | grep -B2 -i -e idvendor -e idproduct

Change ‘X’ to suit your setup
Run the command ‘udevadm control –reload’ to reload the rules


That’s it! Now when ever, the USB external disk is plugged into the USB port, the backup script will be triggered. You can extend the above mentioned backup script to not only back up other partitions beyond just the /home in our example, but also email the operator whenever the process completes.

Scroll to top