Hostapd's control file location was changed in 2013, and that has apparently
broken the wps button hotplug script in cases where there are multiple radios
and wps is possibly configured also for the second radio. The current wps
button hotplug script always handles only the first radio.
https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wps-hotplug.sh
The reason is that the button hotplug script seeks directories like
/var/run/hostapd*, as the hostapd-phy0.conf files were earlier in
per-interface subdirectories.
Currently the *.conf files are directly in /var/run and the control sockets
are in /var/run/hostapd, but there is no subdirectory for each radio.
root@OpenWrt:/# ls /var/run/hostapd*
/var/run/hostapd-phy0.conf /var/run/hostapd-phy1.conf
/var/run/hostapd:
wlan0 wlan1
The hotplug script was attempted to be fixed after the hostapd change by
r38986 in Dec2013, but that change only unbroke the script for the first
radio, but left it broken for multiple radios.
https://dev.openwrt.org/changeset/38986/
The script fails to find subdirectories with [ -d "$dir" ], and passes just
the only found directory /var/run/hostapd, leading into activating only the
first radio, as hostapd_cli defaults to first socket found inthe passed
directory:
root@OpenWrt:/# hostapd_cli -?
...
usage: hostapd_cli [-p<path>] [-i<ifname>] [-hvB] [-a<path>] \
[-G<ping interval>] [command..]
...
-p<path> path to find control sockets (default: /var/run/hostapd)
...
-i<ifname> Interface to listen on (default: first interface found in the
socket path)
Below is a run with the default script and with my proposed solution.
Default script (with logging added):
==================================
root@OpenWrt:/# cat /etc/rc.button/wps
#!/bin/sh
if [ "$ACTION" = "pressed" -a "$BUTTON" = "wps" ]; then
for dir in /var/run/hostapd*; do
[ -d "$dir" ] || continue
logger "WPS activated for: $dir"
hostapd_cli -p "$dir" wps_pbc
done
fi
>>>> WPS BUTTON PRESSED <<<<<
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan0 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan1 wps_get_status
PBC Status: Timed-out
Last WPS result: None
root@OpenWrt:/# logread | grep WPS
Tue Apr 14 18:38:50 2015 user.notice root: WPS activated for: /var/run/hostapd
wlan0 got WPS activated, while wlan1 remained inactive.
I have modified the script to search for sockets instead of directories and
to use the "-i" option with hostapd_cli, and now the script properly
activates wps for both radios. As "-i" needs the interface name instead of
the full path, the script first changes dir to /var/run/hostapd to get simply
the interface names.
Modified script (with logging):
===============================
root@OpenWrt:/# cat /etc/rc.button/wps
#!/bin/sh
if [ "$ACTION" = "pressed" -a "$BUTTON" = "wps" ]; then
cd /var/run/hostapd
for dir in *; do
[ -S "$socket" ] || continue
logger "WPS activated for: $socket"
hostapd_cli -i "$socket" wps_pbc
done
fi
>>>> WPS BUTTON PRESSED <<<<<
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan0 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# hostapd_cli -p /var/run/hostapd -i wlan1 wps_get_status
PBC Status: Active
Last WPS result: None
root@OpenWrt:/# logread | grep WPS
Tue Apr 14 18:53:06 2015 user.notice root: WPS activated for: wlan0
Tue Apr 14 18:53:06 2015 user.notice root: WPS activated for: wlan1
Both radios got their WPS activated properly.
I am not sure if my solution is optimal, but it seems to work. WPS button is
maybe not that often used functionality, but it might be fixed in any case.
Routers with multiple radios are common now, so the bug is maybe more
prominent than earlier.
The modified script has been in a slightly different format in my community
build since r42420 in September 2014.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45492
The last line of procd.sh has a reference to procd_add_interface_reload. procd_add_interface_reload
doesn't seem to exist. I've removed the reference of it to minimize confusion.
Signed-off-by: Eric Schultz <eschultz@prplfoundation.org>
SVN-Revision: 45487
Depending on configuration, disable the LED before writing the trigger
and enable it after writing it. Fixes LEDs where the value defaults to 1
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45463
it has been non-functional for years and caused numerous memleaks and
crashes for people that tried to enable it.
it has no maintained upstream source, and it does not look like it's
going to be fixed any time soon
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45423
To prevent future confusion around '/overlay' vs. 'overlay' simply reject
relative path specifications as mount points since such paths result in
undefined behaviour anyway.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 45404
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r45051 (ieee80211r in
hostapd) and r45326 (start_disabled in mac80211). My patches fix two
instances of "bad number", but there may be a third one, as the original
report in bug 19345 pre-dates r45326 and already has two "bad number" errors
for radio0.
https://dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45380
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r45051 (ieee80211r in
hostapd) and r45326 (start_disabled in mac80211). My patches fix two
instances of "bad number", but there may be a third one, as the original
report in bug 19345 pre-dates r45326 and already has two "bad number" errors
for radio0.
https://dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45379
