Both avahiscan and nbtscan aren't working inside the container

[KayJay7]

Is there an existing issue for this?

• I have searched the existing open and closed issues and I checked the docs https://github.com/jokob-sk/NetAlertX/tree/main/docs

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

Avahiscan and nbtscan are not working inside the container. But if run their commands outside of the container they work.

The logs of avahi-scan reports that avahi-daemon isn't running (logs in the log section). Trying to open a shell in the container and running avahi-daemon I get the following output:

Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.8 exiting.

suggesting that some dependencies are missing from the dockerfile.

---

For nbtscan, the tool runs but doesn't find any hostname, the logs reports every query as successful but didn't find any name.

Expected Behavior

The plugins should populate the database with the same names visible from outside the container.

NOTE: device scanning plugins do find all the devices visible from the machine.

Steps To Reproduce

1. Running latest docker image from docker hub
2. With avahiscan and nbtscan enabled
3. Run either
4. Go to the log

app.conf

[hang.log](https://github.com/user-attachments/files/17852408/hang.log)

docker-compose.yml

version: "3"
services:
  netalertx:
    container_name: netalertx
    # use the below line if you want to test the latest dev image
    # image: "jokobsk/netalertx-dev:latest" 
    image: "jokobsk/netalertx:latest"      
    network_mode: "host"        
    restart: always
    volumes:
      - /home/user/netalertx/config:/app/config
      - /home/user/netalertx/db:/app/db      
      # (optional) useful for debugging if you have issues setting up the container
      - /home/user/netalertx/logs:/app/front/log
	  # IPNEIGH is a local plugin and is unrelated to the issue
      - /home/user/netalertx/extra_plugins/ipneigh:/app/front/plugins/ipneigh 
    environment:
      - TZ=Europe/Rome      
      - PORT=20211

What branch are you running?

Production

app.log

The logs are trimmed to some relevant errors

AVAHISCAN log

22:25:48 [AVAHISCAN] Attempt 1 - Ensuring D-Bus and Avahi daemon are running...
22:25:48 [AVAHISCAN] Avahi Daemon is already running.
22:25:48 [AVAHISCAN] DEBUG CMD :['avahi-resolve', '-a', '192.168.1.102']
22:25:48 [AVAHISCAN] ⚠ ERROR - Failed to create client object: Daemon not running

22:25:48 [AVAHISCAN] Scan: FAIL - check logs
22:25:48 [AVAHISCAN] DEBUG CMD :['avahi-resolve', '-a', '192.168.1.201']
22:25:48 [AVAHISCAN] ⚠ ERROR - Failed to create client object: Daemon not running

Launching avahi-daemon attempt

ubuntu:/# avahi-daemon 
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.8 exiting.

NBTSCAN log

22:25:49 [NBTSCAN] Unknown devices count: 3
22:25:49 [NBTSCAN] DEBUG CMD :['nbtscan', '192.168.1.102']
22:25:50 [NBTSCAN] DEBUG OUTPUT : Doing NBT name scan for addresses from 192.168.1.102

IP address       NetBIOS Name     Server    User             MAC address      
------------------------------------------------------------------------------

22:25:50 [NBTSCAN] Domain Name: 
22:25:50 [NBTSCAN] DEBUG CMD :['nbtscan', '192.168.1.201']
22:25:51 [NBTSCAN] DEBUG OUTPUT : Doing NBT name scan for addresses from 192.168.1.201

IP address       NetBIOS Name     Server    User             MAC address      
------------------------------------------------------------------------------

Debug 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.

[jokob-sk]

Thanks for the report @KayJay7

The above errors are expected. Some devices don't respond to identification requests because they don't support those service calls.

So in short, if most of your device names are recognized and there is an odd device that doesn't, it's probably related to that device, not the scanner itself.

Also ALPINE linux doesn't support nss-mdns, so again, although unfortunate, the error and behavior is expected.

For better device name discovery, you can try following this guide:

https://github.com/jokob-sk/NetAlertX/blob/main/docs/REVERSE_DNS.md

Happy to hear any suggestions and/or approve PRs if someone has an idea how to improve this.

Thanks,
j

[KayJay7]

Yes, ALPINE doesn't support nss-mdns because of musl's limitations, but that only means that it cannot be used for name resolution (actually you can covert mDNS to DNS), but what NetAlertX needs is just name discovery so we don't actually need nss-mdns for the AVAHISCAN plugin but just a working avahi-daemon and avahi-utils.

There's a number of "somewhat-working" guides online to get an avahi-daemon running in a container but it's not recommended to have two mDNS servers running in the same machine (inside and outside the container) and avahi-daemon warns you when you run it.

A better way to handle the situation is to map the avahi-daemon's sockets inside the container (with /var/run/dbus:/var/run/dbus and /var/run/avahi-daemon:/var/run/avahi-daemon) and to avoid starting the daemon inside the container, or it will mess up the sockets in the host machine.
This way the container does not need to run an avahi-daemon, but avahi-utils still work correctly connecting to the host's daemon.

Some minor drawback are:

• OpenRC doesn't know that the daemon is actually running
  • So we to edit the /etc/init.d/avahi-daemon file to stop it from starting the daemon
  • So the current AVAHISCAN plugin needs to be modified to not manually attempt start the daemon
• The container now needs to run in privileged mode to access the sockets
  • Possible security concerns

This could become a pull request, it should:

• "Prep" the container by disabling the containerized avahi-daemon
• Remove the manual startup of the daemon from the AVAHISCAN plugin
• Provide documentation on how to map the sockets

I am not familiar with OpenRC so my way of disabling the daemon was to edit the init file "hollowing out" the start, stop, and restart functions, but leaving the depend function as is, to not mess up dependencies. There is probably a better way.

[jokob-sk]

Thanks for the detailed information. Feel free to submit a PR if you have time, I'm regrettably pretty busy in the next week or so and not a networking expert. I'd probably shelf this under nice to have, but not needed at this point,if not someone else submits a solution. Hope that makes sense.

…

On Tue, 26 Nov 2024, 20:50 KayJay7, ***@***.***> wrote: Yes, ALPINE doesn't support nss-mdns because of musl's limitations, but that only means that it cannot be used for name *resolution* (actually you can covert mDNS to DNS <https://wiki.alpinelinux.org/wiki/MDNS>), but what NetAlertX needs is just name *discovery* so we don't actually need nss-mdns for the AVAHISCAN plugin but just a working avahi-daemon and avahi-utils. There's a number of "somewhat-working" guides online to get an avahi-daemon running in a container but it's not recommended to have two mDNS servers running in the same machine (inside and outside the container) and avahi-daemon warns you when you run it. A better way to handle the situation is to map the avahi-daemon's sockets inside the container (with /var/run/dbus:/var/run/dbus and /var/run/avahi-daemon:/var/run/avahi-daemon) and to *avoid* starting the daemon inside the container, or it will mess up the sockets in the host machine. This way the container does not need to run an avahi-daemon, but avahi-utils still work correctly connecting to the host's daemon. Some minor drawback are: - OpenRC doesn't know that the daemon is actually running - So we to edit the /etc/init.d/avahi-daemon file to stop it from starting the daemon - So the current AVAHISCAN plugin needs to be modified to not manually attempt start the daemon - The container now needs to run in privileged mode to access the sockets - Possible security concerns This could become a pull request, it should: - "Prep" the container by disabling the containerized avahi-daemon - Remove the manual startup of the daemon from the AVAHISCAN plugin - Provide documentation on how to map the sockets I am not familiar with OpenRC so my way of disabling the daemon was to edit the init file "hollowing out" the start, stop, and restart functions, but leaving the depend function as is, to not mess up dependencies. There is probably a better way. — Reply to this email directly, view it on GitHub <#890 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW5URDAOW27Y7IL4LE2P2Q32CQ75DAVCNFSM6AAAAABSIADQ2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBQGE2TANBTGY> . You are receiving this because you commented.Message ID: ***@***.***>

[jokob-sk]

leaving in backlog