NEWDEV_ignored_IPs/MACs cannot exclude the app's self-registered local MAC — exclusions run before it is inserted

[saargilat]

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

On bridge-network installs, NetAlertX self-registers the container's own interface MAC as an "(unknown)" device (devSourcePlugin='local_MAC'). Docker bridge MACs are random per container start, so restarts/recreates keep spawning new ghost devices.

Adding the bridge subnet to NEWDEV_ignored_IPs (e.g. ['192.168.215.%']) does NOT prevent this. Verified with the setting confirmed live in /tmp/api/table_settings.json: after deleting the ghost device, it was re-created on the very next scan cycle.

Root cause is call ordering in server/scan/session_events.py process_scan():

exclude_ignored_devices(db)   # ignore filters applied to CurrentScan first...
save_scanned_devices(db)      # ...then the local MAC is inserted into CurrentScan
                              # (device_handling.py ~line 524)

The exclusion filter can never see the self-registered entry, so create_new_devices() always creates the device regardless of NEWDEV_ignored_IPs / NEWDEV_ignored_MACs.

Expected Behavior

Devices matching NEWDEV_ignored_IPs / NEWDEV_ignored_MACs are never created, including the self-registered local MAC.

Suggested fix (verified in production over many scan cycles): swap the two calls so exclude_ignored_devices() runs after save_scanned_devices(). With the reorder in place, the ghost device is never re-created and no side effects were observed — exclusions simply apply to everything gathered in the cycle.

Steps To Reproduce

1. Run the container on bridge networking (e.g. Docker Desktop / OrbStack on macOS, where host networking is unavailable) — v26.2.6; the call order is identical on current main
2. Observe an "(unknown)" device appear with the container's bridge IP (e.g. 192.168.215.2) and devSourcePlugin='local_MAC'
3. Set NEWDEV_ignored_IPs=['192.168.215.%'], restart, confirm the setting is live in /tmp/api/table_settings.json
4. Delete the "(unknown)" device
5. It is re-created on the next scan cycle
6. Swap the exclude_ignored_devices()/save_scanned_devices() calls in process_scan() and repeat step 4 — the device is never re-created

Relevant app.conf settings

NEWDEV_ignored_IPs=['192.168.215.%']
SCAN_SUBNETS=[]
LOADED_PLUGINS=['CSVBCKP','DBCLNP','MAINT','NEWDEV','NTFPRCS','SETPWD','SYNC','VNDRPDT','WORKFLOWS','UI','CUSTPROP','INTRNT']

docker-compose.yml

# No compose file — docker run equivalent (bridge networking, arm64 host):
# docker run -d --name netalertx --restart unless-stopped \
#   --cap-add=NET_RAW --cap-add=NET_ADMIN --cap-add=NET_BIND_SERVICE \
#   -p 20211:20211 -p 20212:20212 \
#   -v /path/to/netalertx/data:/data \
#   ghcr.io/jokob-sk/netalertx:26.2.6

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

The log shows only the normal pipeline lines, in the problematic order (debug adds no extra output in this code path):

[Process Scan]  Exclude ignored devices
[Process Scan]  Processing scan results      <- local MAC inserted AFTER exclusions already ran

Behavioral proof, with NEWDEV_ignored_IPs=['192.168.215.%'] confirmed live in /tmp/api/table_settings.json:
1. Deleted the "(unknown)" device (devLastIP 192.168.215.2, devSourcePlugin='local_MAC')
2. Re-created on the next scan cycle
3. After reordering the two calls in process_scan(): deleted once more — never re-created across many subsequent cycles

Docker Logs

--> mounts.py
 Path                     | R | W | Mount
--------------------------+---+---+-------
 /data                    | Y | Y |   Y
 /data/db                 | Y | Y |   Y
 /data/config             | Y | Y |   Y
Starting supercronic --quiet "/services/config/cron/crontab" >>"/tmp/log/cron.log" 2>&1 &
Starting /usr/sbin/php-fpm83 -y "/services/config/php/php-fpm.conf" -F
Starting python3 -m server > /tmp/log/stdout.log 2> >(tee /tmp/log/stderr.log >&2)
Starting /usr/sbin/nginx -p "/tmp/run/" -c "/tmp/nginx/active-config/nginx.conf" ...

Container startup is clean — the bug produces no docker-log output; it is visible only as the recurring "(unknown)" device and in app.log as described above.

[jokob-sk]

Thanks for the report! 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 (make sure you use a unique PORT and GRAPHQL_PORT if running instances concurrently) 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 revert the changes to avoid introducing bugs.

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

Thanks in advance,
j

[saargilat]

Tested ghcr.io/netalertx/netalertx-dev-unsafe:next_release (digest b2b43c8) in an
isolated container - verified in both directions:

1. Control (NEWDEV_ignored_IPs empty): the container's own bridge MAC was
   self-registered as an "(unknown)" device within 5 scan cycles, as on current
   releases - confirming the mechanism still runs.

2. With NEWDEV_ignored_IPs=['.%']: deleted the device, then ran
   5+ further cycles across a restart - it was never re-created.

Fix confirmed working. The save_own_device()-before-exclusions approach also
reads cleaner than reordering the whole block. Thanks for the quick turnaround!

[jokob-sk]

Thanks for the confirmation!