Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

UNFIMP does not populate devSSID for UniFi wireless clients

Chiusa
#1,832 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #1836 di @itwormz — integrata

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
json, python

Direzione di ricerca

Read server/plugins/unifi_import/script.py and server/plugins/unifi_import/config.json to trace how the plugin extracts and maps SSID data. Check the linked pull request first, since it is merged; done means wireless clients have their SSID in devSSID and wired clients remain empty.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Feature request ➕ next release/in dev image 🚀 Waiting for reply⏳
What installation are you running?

Production (netalertx) 📦

Is there an existing issue for this?
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

Bug description

The UNFIMP plugin successfully imports UniFi clients, including hostname, IP, vendor, and parent AP/switch information, but WiFi SSIDs are not populated in devSSID.

Environment
  • NetAlertX: v26.10.0
  • UniFi Network: 10.6.106
  • UniFi OS: 5.1.33
  • Controller type: UniFi Cloud Gateway
  • UNFIMP version setting: UDMP-unifiOS
  • Installation type: Production container

UNFIMP successfully connects to the UniFi controller and imports clients.

Current behavior

For a wireless client, the UniFi API data contains the actual WiFi SSID in essid.

Sanitized example:

{
  "is_wired": false,
  "hostname": "<REDACTED_HOSTNAME>",
  "last_connection_network_name": "<REDACTED_NETWORK_NAME>",
  "network": "<REDACTED_NETWORK_NAME>",
  "essid": "<REDACTED_SSID>",
  "last_uplink_name": "<REDACTED_AP_NAME>"
}

Another wireless client shows the same relevant fields:

{
  "is_wired": false,
  "hostname": "<REDACTED_HOSTNAME>",
  "last_connection_network_name": "<REDACTED_NETWORK_NAME>",
  "essid": "<REDACTED_SSID>"
}

The actual WiFi SSID is therefore available in the returned UniFi client data as:

essid

However, the current UNFIMP implementation in server/plugins/unifi_import/script.py uses:

extra=get_unifi_val(device, 'connection_network_name', ''),

In this environment, connection_network_name is not present in the returned wireless client objects, so extra remains empty.

There also appears to be a second issue in:

server/plugins/unifi_import/config.json

The UNFIMP extra column is defined without a mapped_to_column entry.

In particular, it does not contain:

"mapped_to_column": "scanSSID"

Other NetAlertX plugins that provide SSID information use this mapping. For example, the included WiFi Canary plugin defines its extra field using:

{
  "column": "extra",
  "mapped_to_column": "scanSSID"
}

At the same time, UNFIMP exposes devSSID in both its SET_ALWAYS and SET_EMPTY options, which suggests that the plugin is intended to populate devSSID.

Additional information

Parent topology import works correctly using the same UniFi client data.

Fields such as:

last_uplink_name
last_uplink_mac
last_uplink_remote_port
ap_mac

are available from UniFi and the corresponding parent AP/switch information is imported successfully by UNFIMP.

The issue therefore appears to be specific to SSID extraction and SSID-to-devSSID mapping.

No local patches have been applied. The behavior was observed with the unmodified NetAlertX v26.10.0 container.

Expected Behavior

Expected behavior

For wireless UniFi clients, UNFIMP should populate devSSID with the actual WiFi SSID reported by the UniFi controller.

For example:

devSSID = <REDACTED_SSID>

For wired clients, devSSID should remain empty.

Possible cause

There appear to be two related issues:

  1. script.py reads connection_network_name, while the UniFi client data returned in this environment provides the actual WiFi SSID in essid.

  2. The UNFIMP extra field is not mapped to scanSSID in config.json.

For comparison, the UniFi data may also contain:

last_connection_network_name

but this represents the UniFi network name, not necessarily the actual wireless SSID, so it should not be used as a substitute for essid.

Possible fix

The SSID extraction could use essid for wireless clients, for example:

ssid = (
    ''
    if device.get('is_wired') is True
    else get_unifi_val(device, 'essid', '')
)

and then:

extra=ssid,

The corresponding extra column in config.json could also be mapped to scanSSID:

{
  "column": "extra",
  "mapped_to_column": "scanSSID"
}

This would ensure that the SSID extracted from UniFi is propagated into NetAlertX's devSSID field.

Steps To Reproduce
  1. Run NetAlertX v26.10.0 with the UNFIMP plugin configured for a UniFi OS controller using UDMP-unifiOS.

  2. Allow UNFIMP to import clients from the UniFi controller.

  3. Verify that wireless clients are successfully imported and that other UniFi-derived information, such as hostname, vendor, and parent AP/switch data, is populated.

  4. Inspect the UniFi client data for a wireless client and confirm that it contains an essid value, for example:

{
  "is_wired": false,
  "essid": "<REDACTED_SSID>"
}
  1. Open the corresponding device in NetAlertX.

  2. Observe that devSSID is empty even though the UniFi client data contains the SSID in essid.

Relevant app.conf settings

docker-compose.yml

Lingua principale
Python
Stelle
7.2k
Fork
456
Merge medio
16h 25m
PR unite (30g)
30

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di netalertx/NetAlertX

Tutte le issue di netalertx/NetAlertX

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.