FQDN field is cleared and locked after saving a manually created virtual device

[Gaspode-1974]

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

When manually creating a virtual device (e.g. to represent a NAS package or a Docker service that has no MAC of its own, using a manually assigned dummy MAC) and setting an FQDN value on it, the FQDN field is cleared and greyed out/locked after saving — even though it was entered manually and no scan plugin should have touched it.

Expected Behavior

A manually entered FQDN value on a manually created device should be saved and remain editable, not be cleared or locked after saving.

No errors are logged during the save itself (the POST to /device/02:00:00:00:01:01 succeeds). However, the naming plugins (NBTSCAN, NSLOOKUP, DIGSCAN) then run against this manually created device using its assigned IP (192.168.100.111, a placeholder/dummy IP, not a real scannable host), fail to resolve anything (No PTR record found), and appear to overwrite the manually-set FQDN back to empty — which would also explain why the field shows as locked/plugin-managed afterward (source becomes the naming plugin instead of USER). This suggests the naming plugins aren't skipping manually created/virtual devices with non-routable placeholder IPs, and are resetting fields a user explicitly set.

Environment: NetAlertX v26.8.5, Docker (jokobsk/netalertx image), network_mode: host

Steps To Reproduce

1. Create a new device manually (e.g. with a dummy MAC in the locally-administered range, Type: Server, Relationship Type: virtual, assigned to a parent host).
2. Enter a value in the FQDN field (e.g. service.example.com).
3. Save the device.
4. Reload the device detail page.
5. `

`is now empty and the field is greyed out/locked, as if it were auto-managed by a scan plugin.

Relevant app.conf settings

Nothing specific to this feature is customized — default FQDN/naming plugin settings (DIGSCAN, AVAHISCAN) are active

docker-compose.yml

services:
  netalertx:
    image: jokobsk/netalertx:latest
    container_name: netalertx
    network_mode: host
    cap_add:
      - NET_RAW
      - NET_ADMIN
      - NET_BIND_SERVICE
      - CHOWN
      - SETGID
      - SETUID
    environment:
      - PUID=1000001
      - PGID=1000001
      - TZ=Europe/Berlin
      - APP_CONF_OVERRIDE={"SMTP_SERVER":"${SMTP_SERVER}","SMTP_PORT":${SMTP_PORT},"SMTP_SKIP_LOGIN":false,"SMTP_USER":"${SMTP_USER}","SMTP_PASS":"${SMTP_PASS}","SMTP_SKIP_TLS":true,"SMTP_FORCE_SSL":true,"SMTP_REPORT_TO":"${SMTP_REPORT_TO}","SMTP_REPORT_FROM":"${SMTP_REPORT_FROM}","SMTP_RUN":"on_notification"}
    volumes:
      - /mnt_path/netalertx/data:/data
    restart: unless-stopped

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

Nothing specific to this feature is customized — default FQDN/naming plugin settings (DIGSCAN, AVAHISCAN) are active.

Docker Logs

09:22:09 [HTTP] POST /device/02:00:00:00:01:01 from 127.0.0.1
09:22:10 [HTTP] POST /logs/add-to-execution-queue from 127.0.0.1
09:22:10 [UserEventsQueueInstance] Action "...|update_api|devices,appevents" added to the execution queue.
09:22:12 [check_and_run_user_event] WARNING: Unhandled event in execution queue: ... | update_api
09:22:12 [UserEventsQueueInstance] Processed event: ...
...
09:22:41 [Plugin utils] display_name : AVAHISCAN (Naming)
09:22:44 [AVAHISCAN] Devices count: 1
09:22:45 [Plugin utils] display_name : NBTSCAN (Naming)
09:22:47 [NBTSCAN] DEBUG CMD : ['nbtscan', '192.168.100.111']
09:22:48 [NBTSCAN] Domain Name:
09:22:49 [Plugin utils] display_name : NSLOOKUP (Naming)
09:22:51 [NSLOOKUP] No PTR record found for IP: 192.168.100.111
09:22:51 [Plugin utils] display_name : Dig (Name resolution)

[jokob-sk]

Thanks for the report. I see.

The session info fields are not meant to be editable when a dummy device us created and I didn't lock them by mistake. The next version will fix this and the fields will be read only.