Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3018 - /usr/sbin/wpad does not match process path (/proc/exe) #6420

Closed
openwrt-bot opened this issue Apr 19, 2020 · 13 comments
Closed

FS#3018 - /usr/sbin/wpad does not match process path (/proc/exe) #6420

openwrt-bot opened this issue Apr 19, 2020 · 13 comments
Labels

Comments

@openwrt-bot
Copy link

None:

Error during boot on trunk:
Sun Apr 19 09:40:41 2020 daemon.notice netifd: radio0 (1205): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Sun Apr 19 09:40:41 2020 daemon.notice netifd: radio0 (1205): Command failed: Invalid argument

Present on following builds:
r12991-75ef28be59 - build from Thu Apr 16 17h13m41s 2020
r13021-a2cf87a7b1 - latest (Sun Apr 19 06h50m09s 2020)

@openwrt-bot
Copy link
Author

None:

Might be duplicate of FS#3009 - executable path /usr/sbin/hostapd does not match process path (/proc/exe)

@openwrt-bot
Copy link
Author

dormancygrace:

Same on mt7621 (Xiaomi Router 4A Gigabite)

@openwrt-bot
Copy link
Author

dormancygrace:

Why nothing happens? Severity is high, wireless completely down. I tried full wpad and mini - no success.

@openwrt-bot
Copy link
Author

Borromini:

I've been seeing the same here on master on a DIR-860L.

@openwrt-bot
Copy link
Author

farnwomt:

This error is generated because the command:

ubus call service list '{"name": "hostapd"}'

is called by a couple of different scripts

/lib/netifd/hostapd.sh
/lib/netifd/wireless/mac80211.sh

The primary reason for this call is to get a process id for hostapd, but it currently returns absolutely nothing. The output of that command used to have an entry at the top level called "hostapd", but it is now listed as "wpad".

There are basically two solutions, either you modify the scripts mentioned above so that they read:

ubus call service list '{"name": "wpad"}'

or alternatively and perhaps more simply you rename a newly created file which creates these entries.

The file is currently called:

/etc/init.d/wpad

but if you rename it to:

/etc/init.d/hostapd

it will fix the problem.

This can be tested by logging in through a terminal and typing:

/etc/init.d/wpad stop
/etc/init.d/wpad disable
mv /etc/init.d/wpad /etc/init.d/hostapd
/etc/init.d/hostapd enable
/etc/init.d/hostapd start

@openwrt-bot
Copy link
Author

None:

Hi,

Thank you for the debug. However I recommend to use symlink as a temporary fix:

/etc/init.d/wpad stop
/etc/init.d/wpad disable
ln -s /etc/init.d/wpad /etc/init.d/hostapd
/etc/init.d/hostapd enable
/etc/init.d/hostapd start

@openwrt-bot
Copy link
Author

None:

Hi,

Just tested recommended fix. After a reboot, issue still persist.
Created symlink first with following command:
ln -s /etc/init.d/wpad /etc/init.d/hostapd
Checked if symlink is ok:
# ll /etc/init.d/
drwxr-xr-x 1 root root 0 Jun 7 07:17 ./
drwxr-xr-x 1 root root 0 Jun 5 21:54 ../
lrwxrwxrwx 1 root root 16 Jun 7 07:17 hostapd -> /etc/init.d/wpad*

After reboot error still visible in logs:
logread | grep wpad
Sat Jun 6 07:57:37 2020 daemon.notice netifd: radio0 (1217): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)

@openwrt-bot
Copy link
Author

farnwomt:

Can you please type:

ubus call service list '{"name": "wpad"}'

and

ubus call service list '{"name": "hostapd"}'

I would like to know if either of these two commands give you some output and if they do which one?

Also did you do the:

/etc/init.d/wpad disable
/etc/init.d/hostapd enable

If you didn't do those two commands before rebooting I suspect your symbolic link will be insufficient.

@openwrt-bot
Copy link
Author

None:

I did not do the process switch before reboot, just created the symlink.

Output of requested commands are:
@OpenWrt:~# ubus call service list '{"name": "wpad"}'
{
"wpad": {
"instances": {
"hostapd": {
"running": true,
"pid": 1000,
"command": [
"/usr/sbin/hostapd",
"-s",
"-g",
"/var/run/hostapd/global"
],
"term_timeout": 5,
"respawn": {
"threshold": 3600,
"timeout": 5,
"retry": 5
}
},
"supplicant": {
"running": true,
"pid": 1001,
"command": [
"/usr/sbin/wpa_supplicant",
"-n",
"-s",
"-g",
"/var/run/wpa_supplicant/global"
],
"term_timeout": 5,
"respawn": {
"threshold": 3600,
"timeout": 5,
"retry": 5
}
}
}
}
}

@OpenWrt:~# ubus call service list '{"name": "hostapd"}'
{

}

@openwrt-bot
Copy link
Author

farnwomt:

Take a look at:

ls /etc/rc.d

In that directory you should see:

K21hostapd
S19hostapd

if you are seeing

K21wpad
S19wpad

(and I suspect you are) then you didn't do ...

/etc/init.d/wpad disable
/etc/init.d/hostapd enable

You need to reboot after doing that.

@openwrt-bot
Copy link
Author

farnwomt:

Just to be clear if you prefer a symlink over a rename then there are really two options.

The version using a reboot ...

ln -s /etc/init.d/wpad /etc/init.d/hostapd
/etc/init.d/wpad disable
/etc/init.d/hostapd enable
reboot

or this version without a reboot ...

ln -s /etc/init.d/wpad /etc/init.d/hostapd
/etc/init.d/wpad stop
/etc/init.d/wpad disable
/etc/init.d/hostapd enable
/etc/init.d/hostapd start

Unless you do the disable and enable it will leave the symlinks in /etc/rc.d that make the script launch under the name wpad rather than hostapd and when it launches a script named wpad that is the name the ubus command uses.

@openwrt-bot
Copy link
Author

farnwomt:

I believe the change was introduced by Daniel Golle on the 6 April 2020.

I haven't tested this yet, but I think you should be able to patch your compile to make it work by editing:

package/network/services/hostapd/Makefile

you just need to change the line:

$(INSTALL_BIN) ./files/wpad.init $(1)/etc/init.d/wpad

to read:

$(INSTALL_BIN) ./files/wpad.init $(1)/etc/init.d/hostapd

@openwrt-bot
Copy link
Author

farnwomt:

I have emailed a patch to openwrt-devel@lists.openwrt.org and I hope it will be accepted because it fixes this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant