OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Anonymous Submitter - 19.04.2020
Last edited by Adrian Schmutzler - 07.08.2020

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

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)

Closed by  Adrian Schmutzler
07.08.2020 21:45
Reason for closing:  Fixed
Additional comments about closing:  

Fixed in https://github.com/openwrt/op enwrt/commit/8b3e170526cf0f1d9b15a6dd778 7789d15e52cd4

Anonymous Submitter commented on 19.04.2020 07:50

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

dormancygrace commented on 04.05.2020 21:50

Same on mt7621 (Xiaomi Router 4A Gigabite)

dormancygrace commented on 07.05.2020 21:54

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

Borromini commented on 29.05.2020 13:01

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

Michael T Farnworth commented on 05.06.2020 20:43

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
Anonymous Submitter commented on 07.06.2020 05:20

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
Anonymous Submitter commented on 07.06.2020 05:31

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)
Michael T Farnworth commented on 07.06.2020 16:57

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.

Anonymous Submitter commented on 07.06.2020 17:11

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"}'
{

}
Michael T Farnworth commented on 07.06.2020 19:23

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.

Michael T Farnworth commented on 07.06.2020 19:37

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.

Michael T Farnworth commented on 08.06.2020 14:34

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

Michael T Farnworth commented on 08.06.2020 15:27

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing