Netifd, ubus or wpad bug

For Developers
1

I am using my own compile of the latest snapshot and periodically my router gives the following error ...

WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)

I have managed to track this issue down to the the file /lib/netifd/netifd-wireless.sh and in particular the line ...

	[ "$exe" != "$exe2" ] && echo "WARNING (wireless_add_process): executable path $exe does not match process $1 path ($exe2)"

This line is part of a function which is called by /lib/netifd/hostapd.sh and /lib/netifd/wireless/mac80211.sh.

Digging into those two files they both do very similar things, broadly speaking something along the following lines ...

local supplicant_pid=$(ubus call service list '{"name": "hostapd"}' | jsonfilter -l 1 -e "@['hostapd'].instances['supplicant'].pid")
wireless_add_process "$supplicant_pid" "/usr/sbin/wpa_supplicant" 1

When using wpad you get nothing from this query because the top level index to the hash is called "wpad" not "hostapd".

You can get this to work if the ubus command is changed to something like:

ubus call service list '{"name": "wpad"}' | jsonfilter -l 1 -e "@['wpad'].instances['supplicant'].pid"

It seems to me that we either need "wpad" to present as "hostapd" when querying using ubus, or these scripts need to acknowledge that "wpad" could be installed in place of "hostapd". I don't claim to know anything about how ubus functions, so perhaps somebody else could advise which of the two it should be, or possibly even fix this?

2

Having looked further into this I note that if you do

ubus call service list

and look at the latest firmware you see ...

	"wpad": {
		"instances": {
			"hostapd": {
				"running": true,
				"pid": 1686,
				"command": [
					"/usr/sbin/hostapd",
					"-s",
					"-g",
					"/var/run/hostapd/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			},
			"supplicant": {
				"running": true,
				"pid": 1687,
				"command": [
					"/usr/sbin/wpa_supplicant",
					"-n",
					"-s",
					"-g",
					"/var/run/wpa_supplicant/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			}
		}
	}

but under slightly older firmware configured in exactly the same way it used to come up as something like ...

	"hostapd": {
		"instances": {
			"hostapd-phy0": {
				"running": true,
				"pid": 17090,
				"command": [
					"/usr/sbin/hostapd",
					"-s",
					"-n",
					"phy0",
					"-g",
					"/var/run/hostapd-phy0/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			},
			"hostapd-phy1": {
				"running": true,
				"pid": 17092,
				"command": [
					"/usr/sbin/hostapd",
					"-s",
					"-n",
					"phy1",
					"-g",
					"/var/run/hostapd-phy1/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			},
			"supplicant-phy0": {
				"running": true,
				"pid": 1247,
				"command": [
					"/usr/sbin/wpa_supplicant",
					"-s",
					"-n",
					"phy0",
					"-g",
					"/var/run/wpa_supplicant-phy0/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			},
			"supplicant-phy1": {
				"running": true,
				"pid": 1249,
				"command": [
					"/usr/sbin/wpa_supplicant",
					"-s",
					"-n",
					"phy1",
					"-g",
					"/var/run/wpa_supplicant-phy1/global"
				],
				"term_timeout": 5,
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			}
		}
	},

So basically something has caused "ubus" to show up the information as "wpad" rather than "hostapd", so I suspect I won't be the only person that sees this problem.

3

As nobody else has yet commented I have continued to dig to try to work out what is going on. After great deal of head scratching I eventually worked out that the "ubus call service" is basically connecting to procd to obtain its information and that information is automatically created at boot time by a new file called ...

/etc/init.d/wpad

The script is started at boot and creates the "wpad" entries that I am seeing in "ubus call service list".

When I rename the file to:

/etc/init.d/hostapd

the entries move back to the "hostapd" entry that they are expected to be in by other system scripts.

Now it is time to dig some more and try to find out who created this new /etc/init.d/wpad file, because before the creation of this new file there was no /etc/init.d/hostapd as far as I can tell.

4

There is FS3018 in which you might want to enter your findings

5

Thanks I have added my comments there and hopefully somebody will action it.

6

I have also emailed in a patch which will hopefully be applied to fix this problem.