[bug] iwinfo: ssid is a required property

[asmodehn]

Describe the bug
In the schema here the SSID of the Wireless access point is marked as mandatory.

However, in my tests, with the monitoring agent, while having iwinfo enabled (iwinfo.lua file present on device)
AND having a Master wireless interface disabled, the monitoring agent does not report any SSID (which makes sense)

Should we make the SSID not required in the schema ? Is there a more involved fix required elsewhere ?

Steps To Reproduce
Steps to reproduce the behavior:

1. On your device, make sure you have iwinfo.lua in there:

# ls /usr/lib/lua/openwisp-monitoring/
dhcp.lua        interfaces.lua  iwinfo.lua      monitoring.lua  neighbors.lua   resources.lua   utils.lua       wifi.lua

If not, it is safe to create it with the same content as from the source

2. Verify that you now get more details about your wireless interface when running netjson-monitoring --dump <iface_name>

3. On the device (maybe via LUCI -> Wireless), disable an Access Point

4. Check your logs on openwisp server, you should see something like:

Invalid data in "#/interfaces/9/wireless", validator says:
'ssid' is a required property

Expected behavior
We should still receive data, even if one Access Point is disabled (some device may have multiple access points, some enabled, some disabled...)

System Information
My system is somewhat custom (custom OpenWRT build on device and django 4.2 running openwisp 24.11 with some extensions), but afaict it should not have any impact on this bug.
Feel free to ping me for additional information if necessary.

[asmodehn]

I managed to connect to the device and dig up more information...

In my version:

# iwinfo | grep SSID
phy0-ap0 ESSID: "MY_SSID"
phy1-ap0 ESSID: "MY_SSID"

but netjson-monitoring output does not contain the ssid:

# netjson-monitoring -v
netjson-monitoring 0.3.0
# netjson-monitoring --dump phy1-ap0 | grep -i ssid
# 

[nemesifier]

@asmodehn is my understanding correct that we're talking about disabled WiFi interfaces, that is, wifi interfaces that are not broadcasting?

[asmodehn]

I think I incorrectly assumed the problem was because of a disabled interface... I had the problem with enabled(broadcasting) interfaces too. And indeed, since I made the ssid not required in my custom version, wifi sessions are shown in OW, but the ssid field is empty. These commands were run with both interfaces broadcasting (I believe, from memory) Maybe it s a matter of version of OpenWrt, since we build our own from recent snapshots ? I also wonder what is the thinking with making all these fields required ? I d think a bit of data is better than no data ?

…

-- AlexV

On Thu, Jan 8, 2026, 21:35 Federico Capoano ***@***.***> wrote: *nemesifier* left a comment (openwisp/openwisp-monitoring#729) <#729 (comment)> @asmodehn <https://github.com/asmodehn> is my understanding correct that we're talking about disabled WiFi interfaces, that is, wifi interfaces that are not broadcasting? — Reply to this email directly, view it on GitHub <#729 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWASEWSUZLJBBLG3OCVHD4F25PZAVCNFSM6AAAAACQIDIDI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRVGY3TGNZZGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nemesifier]

I think I incorrectly assumed the problem was because of a disabled
interface...

I had the problem with enabled(broadcasting) interfaces too.
And indeed, since I made the ssid not required in my custom version, wifi
sessions are shown in OW, but the ssid field is empty.

@asmodehn please check if the interface is really working.

These commands were run with both interfaces broadcasting (I believe, from
memory)

Maybe it s a matter of version of OpenWrt, since we build our own from
recent snapshots ?

In my experience when the SSID is not provided it's because there's something wrong, eg: the radio is not correctly starting due to some hardware issue (eg: trying to use a channel not supported in that country or something like that).

I also wonder what is the thinking with making all these fields required ?
I d think a bit of data is better than no data ?
…

The main goal of the monitoring is to help troubleshooting, it's not for statistical purposes.
For statistical purposes, some data is better than no data.
For troubleshooting purposes we need to have correct data, if critical information is missing there's either something wrong from a technical standpoint or we could be encountering a case which is not handled properly and needs to be handled.

Accepting any data without rigorous validation could make the life of network admins harder as they may lose trust in the data reported by the tool.

[asmodehn]

Thanks for the detailed explanation. Makes total sense.
I m certain the interface is active.
The ssid is shown when I call ubus call iwinfo info '{"device": "radio0"}' but not when calling netjson-monitoring...

l ll investigate more when I get the chance...

[asmodehn]

Ah maybe I m onto something finally...

I noticed I get a ssid when my wireless device is connected as client:

# ubus call iwinfo info '{"device": "radio0"}'
{
	"phy": "phy0",
	"ssid": "Sulex",
	"bssid": "FA:5E:3C:6B:AA:0F",
	"country": "00",
	"mode": "Client",
	"channel": 2,
	"center_chan1": 2,
	"frequency": 2417,
	"frequency_offset": 0,
	"txpower": 20,
	"txpower_offset": 0,
	"quality_max": 70,
	"noise": 0,
	"htmodes": [
		"HT20",
		"HT40",
		"HE20",
		"HE40"
	],
	"hwmodes": [
		"b",
		"g",
		"n",
		"ax"
	],
	"hwmodes_text": "ax/b/g/n",
	"hwmode": "n",
	"htmode": "HT20",
	"hardware": {
		"id": [
			0,
			0,
			0,
			0
		],
		"name": "MediaTek MT7981"
	}
}

but not when it is an AP (I have a client connected to it, and working fine):

# ubus call iwinfo info '{"device": "radio1"}'
{
	"phy": "phy1",
	"bssid": "F8:5E:3C:6B:AA:10",
	"country": "00",
	"mode": "Master",
	"channel": 44,
	"center_chan1": 42,
	"frequency": 5220,
	"frequency_offset": 0,
	"txpower": 20,
	"txpower_offset": 0,
	"quality_max": 70,
	"noise": 0,
	"htmodes": [
		"HT20",
		"HT40",
		"VHT20",
		"VHT40",
		"VHT80",
		"VHT160",
		"HE20",
		"HE40",
		"HE80",
		"HE160"
	],
	"hwmodes": [
		"n",
		"ac",
		"ax"
	],
	"hwmodes_text": "ac/ax/n",
	"hwmode": "ax",
	"htmode": "HE80",
	"hardware": {
		"id": [
			0,
			0,
			0,
			0
		],
		"name": "MediaTek MT7981"
	}
}

So I understand you re telling me that I should get a ssid here in the AP case, is that correct ?

Note iwinfo returns a ESSID for both these interfaces:

phy0-sta0 ESSID: "Sulex"
         Access Point: fa:5e:3c:6b:aa:0f
         Mode: Client  Channel: 2 (2.417 GHz)  HT Mode: HE40
         Center Channel 1: 2 2: unknown
         Tx-Power: 20 dBm  Link Quality: 42/70
         Signal: -68 dBm  Noise: -91 dBm
         Bit Rate: 130.0 MBit/s
         Encryption: none
         Type: nl80211  HW Mode(s): 802.11ax/n/g/b
         Hardware: embedded [MediaTek MT7981]
         TX power offset: none
         Channel offset: none
         Supports VAPs: yes  PHY name: phy0

phy1-ap0 ESSID: "6baa10"
         Access Point: f8:5e:3c:6b:aa:10
         Mode: Master  Channel: 44 (5.220 GHz)  HT Mode: HE80
         Center Channel 1: 42 2: unknown
         Tx-Power: 20 dBm  Link Quality: 64/70
         Signal: -46 dBm  Noise: -92 dBm
         Bit Rate: 1200.9 MBit/s
         Encryption: WPA-PSK (CCMP)
         Type: nl80211  HW Mode(s): 802.11ax/ac/n
         Hardware: embedded [MediaTek MT7981]
         TX power offset: none
         Channel offset: none
         Supports VAPs: yes  PHY name: phy1