fping command runs into an error on a NetAlertX Installation with 2 LAN-Interfaces

[tuxecert]

What installation are you running?

Production (netalertx) 📦

Is there an existing issue for this?

• I have searched the existing open and closed issues and I checked the docs https://docs.netalertx.com/

The issue occurs in the following browsers. Select at least 2.

• Firefox
• Chrome
• Edge
• Safari (unsupported) - PRs welcome
• N/A - This is an issue with the backend

Current Behavior

I am running 2 Instances of NetAlertX, one has 2 LAN-Interfaces für 2 Subnets, the other only 1 LAN-Interface for one Subnet.
Both are running absolutely fine so far.

Now I wanted to execute the ICMP Plugin in addition to ARP-SCAN.

When running ICMP (using fping) on the machine with 1 LAN-Interface everything is working as expected.

But running the ICMP Plugin with fping on the machine with 2 LAN's never finds any device.

The fping command seems to have an error on execution.

If I try run the fping command from the log file in the shell of the container it gives me an error. The cause seems to be the syntax when addressing the interfaces.
In the log the syntax is -I ens18,ens19
Using this your get:
binding to specific interface (SO_BINTODEVICE): No such device

If I change the command to -I ens18 ens19 it is executes in the containers shell well.

The issue is related to fping only, ping is running without any problems.

Expected Behavior

Running the fping command with multiple LAN Interfaces/Subnets is executed without an error.

Steps To Reproduce

1. Run an instance with 2 LAN-Interfaces and 2 Subnets (one for each).
2. Enable ICMP in addition to ARP-SCAN
3. Wait for the execution of the ICMPJob and copy the ICMP logging output of the fping command to the containers shell and try to execute, it seems to fail
   Replace the "," in (for example) "-I ens18, ens19" with a blank " " and it is working

Relevant app.conf settings

docker-compose.yml

Debug or Trace enabled

• I have read and followed the steps in the wiki link above and provided the required debug logs and the log section covers the time when the issue occurs.

Relevant app.log section

[ICMP] fping cmd: fping -a -i 0.5 -c 3 192.168.178.1 192.168.178.2 192.168.178.4 192.168.178.5 192.168.178.3 192.168.178.6 192.168.178.7 192.168.178.8 192.168.178.10 192.168.178.12 192.168.178.9 192.168.178.17 192.168.178.11 192.168.178.18 192.168.178.19 192.168.178.14 192.168.178.22 192.168.178.23 192.168.178.24 192.168.178.30 192.168.178.31 192.168.178.32 192.168.178.34 192.168.178.35 192.168.178.36 192.168.178.37 192.168.178.61 192.168.178.68 192.168.178.69 192.168.178.70 192.168.178.73 192.168.178.92 192.168.178.97 192.168.178.56 192.168.178.71 192.168.178.49 192.168.178.157 192.168.178.159 192.168.178.72 192.168.178.188 192.168.178.204 192.168.178.207 192.168.178.230 192.168.178.248 192.168.178.241 192.168.178.47 192.168.178.43 192.168.178.246 192.168.178.178 192.168.178.219 192.168.178.45 192.168.178.86 192.168.178.55 192.168.178.132 192.168.178.115 192.168.178.84 192.168.178.130 192.168.178.222 192.168.178.187 192.168.178.233 192.168.178.212 192.168.178.252 192.168.178.165 192.168.178.133 192.168.178.110 192.168.178.50 192.168.178.213 192.168.178.67 192.168.178.48 192.168.178.186 192.168.178.253 217.250.245.61 192.168.178.38 192.168.178.240 192.168.178.181 192.168.178.46 192.168.178.131 192.168.178.108 192.168.178.117 192.168.178.239 192.168.178.122 192.168.178.158 192.168.178.197 192.168.178.217 192.168.178.174 192.168.178.123 10.20.30.1 10.20.30.5 10.20.30.10 10.20.30.25 10.20.30.30 10.20.30.40 10.20.30.60 10.20.30.70 10.20.30.100 192.168.176.4 192.168.176.6 192.168.176.7 192.168.176.50 192.168.176.72 192.168.176.85 192.168.176.10 192.168.176.20 192.168.176.21 192.168.176.30 192.168.176.47 192.168.176.61 192.168.176.77 192.168.176.83 192.168.176.95 192.168.176.98 192.168.176.99 192.168.176.129 192.168.176.138 192.168.176.146 192.168.176.149 192.168.178.146 192.168.178.57 192.168.178.126 192.168.176.2 -I ens18,ens19
12:15:41 [ICMP] fping returned non-zero exit code, reading alive hosts anyway
12:15:41 [ICMP] online_ips: []
12:15:41 [ICMP] Script finished - 0 added or updated

Docker Logs

  PASTE DOCKER LOG HERE. Using the triple backticks preserves format.

[jokob-sk]

Hi,

Thanks for the report.

What is the value of your SCAN_SUBNETS setting?

[tuxecert]

My settings from config file:

SCAN_SUBNETS=['192.168.178.0/24 --interface=ens18','192.168.176.0/24 --interface=ens19']

[jokob-sk]

Thanks! This should be available/fixed in the next release.
It would be great if you could test the ghcr.io/netalertx/netalertx-dev-unsafe Docker image in ~15 minutes (or once the latest GitHub Action finishes).

⚠️ Please back up everything first, or ideally spin up a separate container with its own DB and config (a copy of your current setup), as database changes may occur.

After updating:

• Click the 🔄 refresh button in the blue header at the top
• Hard refresh your browser cache (shift + reload) to force js and css files reload

👉 If I don’t receive confirmation that this works, I may temporarily remove the feature to avoid introducing bugs.

Please test with 1 and 2 interfaces/subnets.

Disclaimer: Running the dev container long-term may lead to data loss, as upgrade paths are not guaranteed.

Thanks in advance,
j

[tuxecert]

I tested the dev container with two interfaces and it seems to me we have an additional problem with the syntax of fping.
Your code works exactly as requested but I made a mistake in my first analysis:
Now fping is executed and does not abort any more but apparently it does not to use the second interface either.
I had overlooked a warning message in my first analysis, see the output of the command executed in the dev container:

ens19: Name does not resolve, see below

If I change the order of these 2 interfaces in this command the warning is thrown for ens18 as second element in the interfacelist too.

Maybe I am wrong, but it seems to me we can only scan with fping using one dedicated interface at a time.

netalertx01:/# fping -a -i 0.5 -c 3 192.168.178.1 192.168.178.2 192.168.178.4 192.168.178.5 192.168.178.3 192.168.178.6 192.168.178.7 192.168.178.8 192.168.178.10 192.168.178.12 192.168.178.9 192.168.178.17 192.168.178.11 192.168.178.18 192.168.178.19 192.168.178.14 192.168.178.22 192.168.178.23 192.168.178.24 192.168.178.30 192.168.178.31 192.168.178.32 192.168.178.34 192.168.178.35 192.168.178.36 192.168.178.37 192.168.178.61 192.168.178.68 192.168.178.69 192.168.178.70 192.168.178.73 192.168.178.92 192.168.178.97 192.168.178.56 192.168.178.71 192.168.178.49 192.168.178.157 192.168.178.159 192.168.178.72 192.168.178.188 192.168.178.204 192.168.178.207 192.168.178.230 192.168.178.248 192.168.178.241 192.168.178.47 192.168.178.43 192.168.178.246 192.168.178.178 192.168.178.219 192.168.178.45 192.168.178.86 192.168.178.55 192.168.178.132 192.168.178.115 192.168.178.84 192.168.178.130 192.168.178.222 192.168.178.187 192.168.178.233 192.168.178.212 192.168.178.252 192.168.178.165 192.168.178.133 192.168.178.110 192.168.178.50 192.168.178.213 192.168.178.67 192.168.178.48 192.168.178.186 192.168.178.253 217.250.245.61 192.168.178.38 192.168.178.240 192.168.178.181 192.168.178.46 192.168.178.131 192.168.178.108 192.168.178.117 192.168.178.239 192.168.178.122 192.168.178.158 192.168.178.197 192.168.178.217 192.168.178.174 192.168.178.123 10.20.30.1 10.20.30.5 10.20.30.10 10.20.30.25 10.20.30.30 10.20.30.40 10.20.30.60 10.20.30.70 10.20.30.100 192.168.176.4 192.168.176.6 192.168.176.7 192.168.176.50 192.168.176.72 192.168.176.85 192.168.176.10 192.168.176.20 192.168.176.21 192.168.176.30 192.168.176.47 192.168.176.61 192.168.176.77 192.168.176.83 192.168.176.95 192.168.176.98 192.168.176.99 192.168.176.129 192.168.176.138 192.168.176.146 192.168.176.149 192.168.178.57 192.168.178.126 192.168.176.2 -I ens18 ens19
ens19: Name does not resolve
192.168.178.1 : [0], 64 bytes, 0.177 ms (0.177 avg, 0% loss)
192.168.178.2 : [0], 64 bytes, 0.427 ms (0.427 avg, 0% loss)
192.168.178.4 : [0], 64 bytes, 1.69 ms (1.69 avg, 0% loss)
192.168.178.5 : [0], 64 bytes, 1.12 ms (1.12 avg, 0% loss)
192.168.178.7 : [0], 64 bytes, 1.16 ms (1.16 avg, 0% loss)
192.168.178.6 : [0], 64 bytes, 2.34 ms (2.34 avg, 0% loss)
192.168.178.3 : [0], 64 bytes, 3.71 ms (3.71 avg, 0% loss)
192.168.178.12 : [0], 64 bytes, 0.856 ms (0.856 avg, 0% loss)
192.168.178.10 : [0], 64 bytes, 1.55 ms (1.55 avg, 0% loss)
192.168.178.17 : [0], 64 bytes, 0.267 ms (0.267 avg, 0% loss)
192.168.178.8 : [0], 64 bytes, 2.76 ms (2.76 avg, 0% loss)
192.168.178.18 : [0], 64 bytes, 0.291 ms (0.291 avg, 0% loss)
192.168.178.19 : [0], 64 bytes, 0.232 ms (0.232 avg, 0% loss)
192.168.178.11 : [0], 64 bytes, 2.11 ms (2.11 avg, 0% loss)
192.168.178.22 : [0], 64 bytes, 0.598 ms (0.598 avg, 0% loss)
192.168.178.23 : [0], 64 bytes, 0.825 ms (0.825 avg, 0% loss)
192.168.178.30 : [0], 64 bytes, 0.239 ms (0.239 avg, 0% loss)

[jokob-sk]

Thanks for testing, please re-pull and test again:

1. With 1 interface
2. With 2 interfaces
3. With no interfaces, just subnet

Thanks in advance.

[tuxecert]

Great work !
fing is running so far without issues.

Tested with ghcr.io/netalertx/netalertx-dev-unsafe:sha-af14dea

Test case 1:
Machine with two LAN interfaces in this configuration - fping working:

Test case 2:
Machine with one LAN interface in this configuration - fping working:

Test case 3:
Machine with one LAN interface in this configuration - fping working:

Will keep it running for the next 2 or 3 days and report here again.

[jokob-sk]

Thanks for testing - glad it's working as expected!

If you find NetAlertX useful, consider sharing the app on forums or socials, at your work, or share a quick review on Reddit or elsewhere to help support the project. See more ideas and how-to in the growth playbook. Danke!

[tuxecert]

No further issues detected, thanks for your support.