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
Comments
None: Might be duplicate of FS#3009 - executable path /usr/sbin/hostapd does not match process path (/proc/exe) |
dormancygrace: Same on mt7621 (Xiaomi Router 4A Gigabite) |
dormancygrace: Why nothing happens? Severity is high, wireless completely down. I tried full wpad and mini - no success. |
Borromini: I've been seeing the same here on master on a DIR-860L. |
farnwomt: This error is generated because the command:
is called by a couple of different scripts /lib/netifd/hostapd.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:
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:
|
None: Hi, Thank you for the debug. However I recommend to use symlink as a temporary fix:
|
None: Hi, Just tested recommended fix. After a reboot, issue still persist. After reboot error still visible in logs: |
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 If you didn't do those two commands before rebooting I suspect your symbolic link will be insufficient. |
None: I did not do the process switch before reboot, just created the symlink. Output of requested commands are:
|
farnwomt: Take a look at: ls /etc/rc.d In that directory you should see: K21hostapd if you are seeing K21wpad (and I suspect you are) then you didn't do ... /etc/init.d/wpad disable You need to reboot after doing that. |
farnwomt: Just to be clear if you prefer a symlink over a rename then there are really two options. The version using a reboot ...
or this version without a reboot ...
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. |
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: to read: |
farnwomt: I have emailed a patch to openwrt-devel@lists.openwrt.org and I hope it will be accepted because it fixes this problem. |
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)
The text was updated successfully, but these errors were encountered: