Re: [PATCH] realtek: fix ZyXEL initramfs image generation
Hi Bjørn,
On Thu, 2021-06-24 at 23:04 +0200, Bjørn Mork wrote:
> The current rule produces empty trailers, causing the OEM firmware
> update application to reject our images.
>
> The double expansion of a makefile variable does not work inside
> shell code. The second round is interpreted as a shell expansion,
> attempting to run the command ZYXEL_VERS instead of expanding the
> $(ZYXEL_VERS) makefile variable.
>
> Fix by removing one level of variable indirection.
>
> Fixes: c6c8d597e183 ("realtek: Add generic zyxel_gs1900 image definition")
> Signed-off-by: Bjørn Mork
> ---
> I got myself another brand new GS1900-10HP and used the opportunity to
> verify the console-less installation procedure. And of course, it didn't
> work
I wanted to verify that your patch fixes OpenWrt flashing, but V2.60(AAHH.4) on
my
GS1900-8 actually accepts images with bogus trailers. That being said, an image
produced with your patch applied, thus a correct trailer, can also be flashed
and the
trailer is recognized by the stock firmware.
So I guess I can already provide this:
Tested-by: Sander Vanheule
I also have one small question below.
> The reason is that we currently build images with a bogus trailer,
> lacking the crucial hardware version info the OEM firmware looks
> for.
>
> This needs to be backported yto 21.02 as well. I dowloaded the
> initramfs images from downloads.openwrt.org and verified that they have
> the same issue:
>
> $ hexdump -C openwrt-21.02.0-rc3-realtek-generic-zyxel_gs1900-10hp-initramfs-
> kernel.bin |tail -4
> 005b7240 ca 0f 86 61 cc 1b 7d 0a 0b 09 45 88 fc 06 fd ac
> |...a..}...E.|
> 005b7250 f6 82 7e 5d 7d 13 5a 56 8c 14 fe 7f 55 bf 19 d4
> |..~]}.ZVU...|
> 005b7260 ea 2d d7 00 56 45 52 53 0a |.-..VERS.|
> 005b7269
>
>
> A proper image should have a trailer similar to this:
>
> $ hexdump -C openwrt-initramfs.bin |tail -4
> 005746d0 10 e1 d2 0c 73 0a ff 07 eb 12 c6 f1 0a eb ca 00
> |s...|
> 005746e0 56 45 52 53 0a 56 39 2e 39 39 28 41 41 5a 49 2e
> |VERS.V9.99(AAZI.|
> 005746f0 30 29 20 7c 20 30 36 2f 32 34 2f 32 30 32 31 0a |0) |
> 06/24/2021.|
> 00574700
>
> The last one is the actual image I used to my initial install from OEM.
> It worked.
>
>
> Bjørn
>
> target/linux/realtek/image/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/linux/realtek/image/Makefile
> b/target/linux/realtek/image/Makefile
> index ebc0c0a78480..38b4d5e441cc 100644
> --- a/target/linux/realtek/image/Makefile
> +++ b/target/linux/realtek/image/Makefile
> @@ -10,7 +10,7 @@ DEVICE_VARS += ZYXEL_VERS
>
> define Build/zyxel-vers
> ( echo VERS;\
> - for hw in $(1); do\
> + for hw in $(ZYXEL_VERS); do\
> echo -n "V9.99($$hw.0) | ";\
> date -d @$(SOURCE_DATE_EPOCH) +%m/%d/%Y;\
> done ) >> $@
Would it be worthwile to make zyxel-vers fail if $(ZYXEL_VERS) is not
defined/empty?
A user could still define a wrong value of course, but at least they would know
to
provide something.
Best,
Sander
> @@ -117,7 +117,7 @@ define Device/zyxel_gs1900
> IMAGE_SIZE := 6976k
> DEVICE_VENDOR := ZyXEL
> UIMAGE_MAGIC := 0x8380
> - KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers
> (ZYXEL_VERS)
> | \
> + KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | zyxel-vers | \
> uImage gzip
> endef
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.1 First service release
Hi, The OpenWrt community is proud to announce the first service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes. Main changes from OpenWrt 21.02.0 Major bug fixes * Fix Let's Encrypt certificate handling in WolfSSL * Fix sysupgrade for Mikrotik targets * Fix sysupgrade for Rockchip target when using squashfs Device support * Add support for iEi Puzzle-M901/Puzzle-M902 Various fixes and improvements * Add build system support for Python 3.10 * Fix which handling on Fedora and MacOS build systems * Add Tmux terminfo Core components * Update Linux kernel from 5.4.143 to 5.4.154 * Update mac80211 from 5.10.42 to 5.10.68 * Update ath10k-ct to 2021-09-22 * Update wolfssl from 4.7.0 to 4.8.1 Known issues * Some IPv6 packets are dropped when software flow offloading is used: FS#3373 * As a workaround, do not activate software flow offloading, it is deactivate by default. * The menu bar in LuCI is wrongly aligned * If this is a real problem for you update the LuCI theme: opkg upgrade luci-theme-bootstrap Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.1 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.1#known_issues For a detailed list of all changes since 21.02.0, refer to https://openwrt.org/releases/21.02/changelog-21.02.1 To download the 21.02.0-rc4 images, navigate to: https://downloads.openwrt.org/releases/21.02.1/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFT PATCH] ath9k: OF: qca, disable-(2|5)ghz => ieee80211-freq-limit
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Christian, thank you for working on this! On Fri, Oct 29, 2021 at 10:13 PM Christian Lamparter wrote: > > OpenWrt maintains two special out-of-tree DT properties: > "qca,disable-5ghz" and "qca,disable-2ghz". These are implemented > in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch". > > With the things being what they are, now might be a good > point to switch the devices to the generic and upstream > "ieee80211-freq-limit" property. This property is much > broader and works differently. Instead of disabling the > drivers logic which would adds the affected band and typo: s/adds/add/ > channels. It now disables all channels which are not > within the specified frequency range. > > Signed-off-by: Christian Lamparter apart from above typo this is: Reviewed-by: Martin Blumenstingl as well as: Tested-by: Martin Blumenstingl # HH5A Best regards, Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFT PATCH] ath9k: OF: qca,disable-(2|5)ghz => ieee80211-freq-limit
OpenWrt maintains two special out-of-tree DT properties:
"qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".
With the things being what they are, now might be a good
point to switch the devices to the generic and upstream
"ieee80211-freq-limit" property. This property is much
broader and works differently. Instead of disabling the
drivers logic which would adds the affected band and
channels. It now disables all channels which are not
within the specified frequency range.
Signed-off-by: Christian Lamparter
---
...-ieee80211-freq-limit-property-to-li.patch | 29 +++
.../550-ath9k-disable-bands-via-dt.patch | 15 --
.../patches/ath9k/552-ath9k-ahb_of.patch | 8 +
target/linux/ath79/dts/ar9342_ubnt_wa.dtsi| 2 +-
.../linux/ath79/dts/ar9344_atheros_db120.dts | 2 +-
.../ath79/dts/ar9344_engenius_exx600.dtsi | 4 +--
target/linux/ath79/dts/ar9344_pcs_cap324.dts | 4 +--
.../boot/dts/lantiq/vr9_bt_homehub-v5a.dts| 2 +-
.../boot/dts/lantiq/vr9_tplink_tdw89x0.dtsi | 2 +-
9 files changed, 38 insertions(+), 30 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
delete mode 100644
package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
diff --git
a/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
b/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
new file mode 100644
index 00..4142cb6ffd
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath9k/040-ath9k-support-DT-ieee80211-freq-limit-property-to-li.patch
@@ -0,0 +1,29 @@
+From 03469e79fee9e8e908dae3bd1a80bcd9a66f2a88 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter
+Date: Mon, 11 Oct 2021 18:18:00 +0300
+Subject: ath9k: support DT ieee80211-freq-limit property to limit channels
+
+The common DT property can be used to limit the available channels
+but ath9k has to manually call wiphy_read_of_freq_limits().
+
+I would have put this into ath9k_of_init(). But it didn't work there.
+The reason is that in ath9k_of_init() the channels and bands are not yet
+registered in the wiphy struct. So there isn't any channel to flag as
+disabled.
+
+Signed-off-by: Christian Lamparter
+Signed-off-by: Kalle Valo
+Link: https://lore.kernel.org/r/20211009212847.1781986-1-chunk...@gmail.com
+---
+--- a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
+@@ -1094,6 +1094,8 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
+ ARRAY_SIZE(ath9k_tpt_blink));
+ #endif
+
++ wiphy_read_of_freq_limits(hw->wiphy);
++
+ /* Register with mac80211 */
+ error = ieee80211_register_hw(hw);
+ if (error)
+
diff --git
a/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
b/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
deleted file mode 100644
index d1593339d2..00
--- a/package/kernel/mac80211/patches/ath9k/550-ath9k-disable-bands-via-dt.patch
+++ /dev/null
@@ -1,15 +0,0 @@
a/drivers/net/wireless/ath/ath9k/init.c
-+++ b/drivers/net/wireless/ath/ath9k/init.c
-@@ -625,6 +625,12 @@ static int ath9k_of_init(struct ath_soft
-
- ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
-
-+ if (of_property_read_bool(np, "qca,disable-2ghz"))
-+ ah->disable_2ghz = true;
-+
-+ if (of_property_read_bool(np, "qca,disable-5ghz"))
-+ ah->disable_5ghz = true;
-+
- if (of_property_read_bool(np, "qca,no-eeprom")) {
- /* ath9k-eeprom--.bin */
- scnprintf(eeprom_name, sizeof(eeprom_name),
diff --git a/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
b/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
index 2552bbc7a1..fce6db2167 100644
--- a/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
+++ b/package/kernel/mac80211/patches/ath9k/552-ath9k-ahb_of.patch
@@ -16,7 +16,7 @@
static const struct platform_device_id ath9k_platform_id_table[] = {
{
-@@ -69,6 +77,242 @@ static const struct ath_bus_ops ath_ahb_
+@@ -69,6 +77,236 @@ static const struct ath_bus_ops ath_ahb_
.eeprom_read = ath_ahb_eeprom_read,
};
@@ -218,12 +218,6 @@
+ else
+ pdata->led_pin = -1;
+
-+ if (of_property_read_bool(pdev->dev.of_node, "qca,disable-2ghz"))
-+ pdata->disable_2ghz = true;
-+
-+ if (of_property_read_bool(pdev->dev.of_node, "qca,disable-5ghz"))
-+ pdata->disable_5ghz = true;
-+
+ if (of_property_read_bool(pdev->dev.of_node, "qca,tx-gain-buffalo"))
+ pdata->tx_gain_buffalo = true;
+
diff --git a/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
b/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
index 549daace7e..ba0f7ad23e 100644
[PATCH v2] rpcd: reload rpcd on installation of rpcd-mod-*
When installing additional rpcd modules, a restart of rpcd is required.
This often confuses users as even after installing rpcd-mod-rpcsys the
relevant ubus objects are still missing until rpcd has been reloaded
(or the system has been rebooted, obviously).
Let rpcd-mod-* reload rpcd as post-install action.
Signed-off-by: Daniel Golle
---
v2: use reload instead of restart to not break LuCI sessions
package/system/rpcd/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/package/system/rpcd/Makefile b/package/system/rpcd/Makefile
index 9880ea4d66..1642c97a42 100644
--- a/package/system/rpcd/Makefile
+++ b/package/system/rpcd/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=rpcd
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/rpcd.git
@@ -84,6 +84,11 @@ define BuildPlugin
$(3)
endef
+ define Package/rpcd-mod-$(1)/postinst
+#!/bin/sh
+[ -n "{IPKG_INSTROOT}" ] || /etc/init.d/rpcd reload
+ endef
+
define Package/rpcd-mod-$(1)/install
$(INSTALL_DIR) $$(1)/usr/lib/rpcd
$(INSTALL_BIN) $(PKG_BUILD_DIR)/$(1).so $$(1)/usr/lib/rpcd/
--
2.33.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firmware-utils][PATCH 2/2] build, cmake: switch OPENSSL_CRYPTO_LIBRARY -> OPENSSL_CRYPTO_LIBRARIES
OPENSSL_CRYPTO_LIBRARY returns just the full path to libcrypto.a
OPENSSL_CRYPTO_LIBRARIES returns also any other libraries required to fully
link an executable with libcrypto.a. This can be -lpthread, or -ldl, or
something else.
The FindOpenSSL.cmake module does a good job of identifying these dependent
libs, but the OPENSSL_CRYPTO_LIBRARIES variable must be used (same as using
ZLIB_LIBRARIES).
Signed-off-by: Alexandru Ardelean
---
CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3e206a2..f406520 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -62,7 +62,7 @@ FW_UTIL(mkedimaximg "" "" "")
FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" "${ZLIB_LIBRARIES}")
FW_UTIL(mkfwimage2 "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(mkheader_gemtek "" "" "${ZLIB_LIBRARIES}")
-FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARY}")
+FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARIES}")
FW_UTIL(mkmerakifw src/sha1.c "" "")
FW_UTIL(mkmerakifw-old "" "" "")
FW_UTIL(mkmylofw "" "" "")
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firmware-utils][PATCH 1/2] build, cmake: add quotes for FW_UTIL variable arguments
CMake macro arguments are special, so when passing ${ZLIB_LIBRARIES} as
an argument, this can actually be a list of strings.
In this case, the first library (for zlib) will be added to
TARGET_LINK_LIBRARIES() and the others will be discarded. This is likely
due to some expansion from the FW_UTIL macro.
So, if FindZLIB returns more libraries for linking, they will not be
considered.
This is the case when trying to change OPENSSL_CRYPTO_LIBRARY ->
OPENSSL_CRYPTO_LIBRARIES.
OPENSSL_CRYPTO_LIBRARY is just libcrypto.a
OPENSSL_CRYPTO_LIBRARIES can also include -ldl
There's a few points made here about macros:
https://cmake.org/cmake/help/latest/command/macro.html#argument-caveats
Signed-off-by: Alexandru Ardelean
---
CMakeLists.txt | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 556ec72..3e206a2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -18,10 +18,10 @@ ADD_DEFINITIONS(-Wall -Wno-unused-parameter)
MACRO(FW_UTIL util deps extra_cflags libs)
ADD_EXECUTABLE(${util} src/${util}.c ${deps})
INSTALL(TARGETS ${util} RUNTIME)
- IF(NOT ${ARGV2} STREQUAL "")
+ IF(NOT "${extra_cflags}" STREQUAL "")
SET_TARGET_PROPERTIES(${util} PROPERTIES COMPILE_FLAGS ${extra_cflags})
ENDIF()
- IF(NOT ${ARGV3} STREQUAL "")
+ IF(NOT "${libs}" STREQUAL "")
TARGET_LINK_LIBRARIES(${util} ${libs})
ENDIF()
ENDMACRO(FW_UTIL)
@@ -42,9 +42,9 @@ FW_UTIL(encode_crc "" "" "")
FW_UTIL(fix-u-media-header src/cyg_crc32.c "" "")
FW_UTIL(hcsmakeimage src/bcmalgo.c "" "")
FW_UTIL(imagetag "src/imagetag_cmdline.c;src/cyg_crc32.c" "" "")
-FW_UTIL(jcgimage "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(jcgimage "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(lxlfw "" "" "")
-FW_UTIL(lzma2eva "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(lzma2eva "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(makeamitbin "" "" "")
FW_UTIL(mkbrncmdline "" "" "")
FW_UTIL(mkbrnimg "" "" "")
@@ -56,20 +56,20 @@ FW_UTIL(mkcsysimg "" "" "")
FW_UTIL(mkdapimg "" "" "")
FW_UTIL(mkdapimg2 "" "" "")
FW_UTIL(mkdhpimg src/buffalo-lib.c "" "")
-FW_UTIL(mkdlinkfw src/mkdlinkfw-lib.c --std=c99 ${ZLIB_LIBRARIES})
+FW_UTIL(mkdlinkfw src/mkdlinkfw-lib.c --std=c99 "${ZLIB_LIBRARIES}")
FW_UTIL(mkdniimg "" "" "")
FW_UTIL(mkedimaximg "" "" "")
-FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" ${ZLIB_LIBRARIES})
-FW_UTIL(mkfwimage2 "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(mkheader_gemtek "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(mkhilinkfw "" "" ${OPENSSL_CRYPTO_LIBRARY})
+FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkfwimage2 "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkheader_gemtek "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARY}")
FW_UTIL(mkmerakifw src/sha1.c "" "")
FW_UTIL(mkmerakifw-old "" "" "")
FW_UTIL(mkmylofw "" "" "")
FW_UTIL(mkplanexfw src/sha1.c "" "")
FW_UTIL(mkporayfw "" "" "")
FW_UTIL(mkrasimage "" --std=gnu99 "")
-FW_UTIL(mkrtn56uimg "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(mkrtn56uimg "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(mksenaofw src/md5.c --std=gnu99 "")
FW_UTIL(mksercommfw "" "" "")
FW_UTIL(mktitanimg "" "" "")
@@ -96,8 +96,8 @@ FW_UTIL(tplink-safeloader src/md5.c --std=gnu99 "")
FW_UTIL(trx "" "" "")
FW_UTIL(trx2edips "" "" "")
FW_UTIL(trx2usr "" "" "")
-FW_UTIL(uimage_padhdr "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(uimage_sgehdr "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(uimage_padhdr "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(uimage_sgehdr "" "" "${ZLIB_LIBRARIES}")
FW_UTIL(wrt400n src/cyg_crc32.c "" "")
FW_UTIL(xiaomifw "" "" "")
FW_UTIL(xorimage "" "" "")
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] hostapd: add fallback for WPS on stations
Up to now the WPS script triggered WPS on the stations only if it
could not trigger it successfully on any hostapd instance.
In a Multi-AP context, there can be a need (to establish a new
wireless backhaul link) to trigger WPS on the stations, regardless of
whether there is already a hostapd instance configured or not. The
current script makes it impossible, as if hostapd is running and
configured, WPS would always be triggered on hostapd only.
To allow both possibilities, the following changes are made:
- Change the "pressed" action to "release", so that we can make use of
the "$SEEN" variables (to know for how long the button was pressed).
- If the button is pressed for less than 3 seconds, keep the original
behavior.
- If the button is pressed for 3 seconds or more, trigger WPS on the
stations, regardless of the status of any running hostapd instance.
- Add comments explaining both behaviors.
- While at it, replace the usage of '-a' with a '[] && []'
construct (see [1]).
This gives users a "fallback" mechanism to onboard a device to a
Multi-AP network, even if the device already has a configured hostapd
instance running.
[1]: https://github.com/koalaman/shellcheck/wiki/SC2166
Signed-off-by: Raphaël Mélotte
---
Changes v1 -> v2:
- minor comment update.
.../services/hostapd/files/wps-hotplug.sh | 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/package/network/services/hostapd/files/wps-hotplug.sh
b/package/network/services/hostapd/files/wps-hotplug.sh
index d00939d769..073bdd1868 100644
--- a/package/network/services/hostapd/files/wps-hotplug.sh
+++ b/package/network/services/hostapd/files/wps-hotplug.sh
@@ -38,13 +38,20 @@ wps_catch_credentials() {
done
}
-if [ "$ACTION" = "pressed" -a "$BUTTON" = "wps" ]; then
- wps_done=0
- ubusobjs="$( ubus -S list hostapd.* )"
- for ubusobj in $ubusobjs; do
- ubus -S call $ubusobj wps_start && wps_done=1
- done
- [ $wps_done = 0 ] || return 0
+if [ "$ACTION" = "released" ] && [ "$BUTTON" = "wps" ]; then
+ # If the button was pressed for 3 seconds or more, trigger WPS on
+ # wpa_supplicant only, no matter if hostapd is running or not. If
+ # was pressed for less than 3 seconds, try triggering on
+ # hostapd. If there is no hostapd instance to trigger it on or WPS
+ # is not enabled on them, trigger it on wpa_supplicant.
+ if [ "$SEEN" -lt 3 ] ; then
+ wps_done=0
+ ubusobjs="$( ubus -S list hostapd.* )"
+ for ubusobj in $ubusobjs; do
+ ubus -S call $ubusobj wps_start && wps_done=1
+ done
+ [ $wps_done = 0 ] || return 0
+ fi
wps_done=0
ubusobjs="$( ubus -S list wpa_supplicant.* )"
for ubusobj in $ubusobjs; do
--
2.33.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
