“failed to initialize main scan loop” when starting hcxdumptool as a service

[reweb87]

I’ve been using hcxdumptool for several years on a Raspberry Pi Zero 2, and I update it regularly. With every major update there are usually some parameter changes, but that has never caused any real issues. This time, however, I’m running into a strange problem.

I’ve always started hcxdumptool as a systemd service (hcxd.service), because that allows me to easily start and stop it using hardware buttons.

With the latest version (7.1.0‑6‑gc662861), the service fails immediately after startup with the error:
failed to initialize main scan loop

systemctl start hcxd.service 
journalctl -u hcxd.service 

Feb 06 22:45:59 raspberrypi systemd[1]: Starting hcxdumptool starten...
Feb 06 22:46:29 raspberrypi systemd[1]: Started hcxdumptool starten.
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: This is a highly experimental penetration testing tool!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: It is made to detect vulnerabilities in your NETWORK mercilessly!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: Misuse within a network, without specific authorization, may cause
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: irreparable damage and result in significant consequences!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: Not understanding what you were doing is not going to work as an excuse!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: Warning: BPF is unset!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: Make sure hcxdumptool is running in a 100% controlled environment!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: Checkout (and understand) README.md and docs/example.md!
Feb 06 22:46:31 raspberrypi start_hcxdumptool.sh[1828]: [48B blob data]
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: failed to initialize main scan loop
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: [38B blob data]
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: 96 Packet(s) dropped by kernel
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: 1 ERROR(s) during runtime:
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: - mostly caused by a broken driver
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: - or running hcxdumptool on a shared interface)
Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: - or a misconfigured system
Feb 06 22:46:36 raspberrypi systemd[1]: hcxd.service: Succeeded.

What’s odd is that the exact same Bash script runs perfectly fine when executed manually in a shell:

./start_hcxdumptool.sh

This is a highly experimental penetration testing tool!
It is made to detect vulnerabilities in your NETWORK mercilessly!
Misuse within a network, without specific authorization, may cause
irreparable damage and result in significant consequences!
Not understanding what you were doing is not going to work as an excuse!

Warning: BPF is unset!
Make sure hcxdumptool is running in a 100% controlled environment!
Checkout (and understand) README.md and docs/example.md!

starting in headless mode (display off)...
^C
386 Packet(s) captured by kernel
90 Packet(s) dropped by kernel
exit on sigterm

It only fails when started as a systemd service.

My service file (hcxd.service) looks like this:

[Unit]
Description=hcxdumptool starten
After=multi-user.target

[Service]
Type=simple
ExecStartPre=/bin/sleep 30
ExecStart=/root/start_hcxdumptool.sh
Restart=on-abort

[Install]
WantedBy=multi-user.target

The start script (start_hcxdumptool.sh) looks like this:

#!/bin/bash

adapter=$(hcxdumptool -L | awk '/ath9k_htc|mt76x2u/ {print $6}')
datei=$(date +"%Y-%m-%d_%H%M")

if [ ! -d "/sys/class/net/wlan1/" ]; then
	echo "Kein zusätzlicher Adapter installiert. Abbruch..."
	exit 1
fi

if [ -n "$adapter" ]; then
	service dhcpcd stop
	service wpa_supplicant stop

	hcxdumptool -i $adapter -w /Daten/$datei-dump.pcapng --disable_disassociation -F
fi

Do you have any idea what might be causing this? What changed in the new version that prevents it from running correctly as a service, even though it still works from the shell?

[ZerBea]

Lat's take a closer look at this problem shown by journalctl::

Feb 06 22:46:36 raspberrypi start_hcxdumptool.sh[1828]: failed to initialize main scan loop

That's interesting. Because I've not changed the main scan loop since a long time.

I'm running hcxdumptool on a Raspberyy Pi Zero and it is started and stopped by an init.d script.
Therefore (running from systemd or init.d) I've added an option to demonize hcxdumptool:

--daemonize               : daemonize
                             status messages are suppressed
                              to terminate hcxdumptool send SIGTERM to its PID
                              or press push button (modified Raspberry Pi)

I've added some more functions to debug mode to show problems inside the main scan loop.
Please do a git pull
Uncomment debug mode

# uncomment to enable DEBUG log
DEFS		+= -DHCXDEBUG

compile and run hcxdumptool via systemd.
When finished, you find a log file in the working directory: hcxerror.log

I suggest to set the working dir in the startup script which makes it easier to locate the error log.

cd HCXDUMTOOL_WORKINGDIR
hcxdumptool -i $adapter -w /Daten/$datei-dump.pcapng --disable_disassociation -F

Please attach the error log file.

[ZerBea]

BTW:
There is no need to stop the dhcpcd service!

[ZerBea]

Please test latest commit.

I've installed systemd to reproduce the issue. It should be fixed now.

[reweb87]

You’re incredible. Before I even had the chance to provide further details, you already fixed it. Everything works fine now.

This is exactly why I keep coming back to this repository several times a month to read through the issues and discussions. I’m always impressed by how quickly and thoroughly you respond to every request. Keep up the great work!

[ZerBea]

I'm glad to read that it is working.
Problem was caused by this code line:

hcxdumptool/hcxdumptool.c

Line 3567 in 3a003ca

if(epoll_ctl(fd_epoll, EPOLL_CTL_ADD, fd_timer2, &ev) < 0)

Looks like systemd doesn't like if "epoll_ctl" is done on an unarmed timer.