Add missing wpabuf_free calls to the hostapd_rrm_nr_set and
hostapd_rrm_beacon_req functions.
Signed-off-by: Vladimir Palevich <palevichva@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22538
Signed-off-by: Nick Hainke <vincent@systemli.org>
The hostapd configuration for SU-BEAMFORMEE was incorrectly using the
beamformer antenna count instead of the beamformee antenna count for the
[BF-ANTENNA-N] capability string.
Fix this by using config.beamformee_antennas instead.
Signed-off-by: Andrew Sim <andrewsimz@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22511
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
parent_tsf in struct rrm_measurement_beacon_report is le32 (32-bit),
but was being added with blobmsg_add_u16, truncating the value.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The beacon measurement token was not included in the ubus beacon-report
notification, causing consumers that need the token (e.g. for constructing
Beacon Metrics Response TLVs) to receive null.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Use blobmsg_add_u32 for non-bool fields in order to avoid wrong
interpretations of the data on JSON/ucode conversion.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The Reporting Detail value is a 1-byte field, but was written as le16,
producing a 2-byte write that also contradicts the length field of 1
in the subelement header.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The reporting detail subelement (up to 3 bytes) was not accounted for
in the wpabuf allocation, causing a crash when reporting_detail is set
to a valid value (0, 1, or 2).
Signed-off-by: Felix Fietkau <nbd@nbd.name>
After 02e2065203, it can happen that both,
[VHT160-80PLUS80] and [VHT160] are added to the vht_capab option in
an AP's hostapd.conf, which would cause a failure to start the AP.
Fix the logic in order to prevent such misconfiguration.
Fixes: #22481
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/22482
Signed-off-by: Robert Marko <robimarko@gmail.com>
% git shortlog v1.0.20250521..v1.0.20260223
Doug Freed (1):
wg-quick@.service: add deps on wg-quick.target
Jason A. Donenfeld (8):
wg-quick: linux: use smallest mtu, not largest
syncconf: account for psks removed from config file
wg-quick: linux: deal with resolvconf migration more gracefully
wg-quick: use addconf instead of setconf
wg-quick: linux: do not unnecessarily set sysctl
config: preserve const correctness
syncconf: account for persistent keepalive removed from config file
version: bump
Robyn Kosching (1):
wg-quick: pass on # comments to {Pre,Post}{Up,Down}
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/22190
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
a52cdb354d13 dns: validate IPv4 record addresses
b798c24205b5 dns: validate IPv6 record addresses
a3dcb4adc635 dns: validate reverse dns query name lengths
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
When the virtual package "uci-firewall" is installed, the choice
between "firewall" and "firewall4" is arbitrary, sometimes resulting
in one, sometimes the other.
Set the default variant on "firewall4" to make it the preferred
package when installed as a dependency.
Link: https://forum.openwrt.org/t/owut-openwrt-upgrade-tool/200035/1126
Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22328
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
memcpy() with overlapping src and dest buffers is an undefined behavior
in C. In the current code, a ConfRej response is generated by copying
input data in-place, where the dest address is lower than the src.
This happens to work in practice because memcpy() forward-copies data,
matching the behavior of memmove() in this case.
However, if FORTIFY_SOURCE or Address Sanitizer is enabled, memcpy()
will detect the overlap at run time and abort the program.
Replace the memcpy() with memmove() to ensure a well-defined behavior.
Reported-by: Filippo Carletti <filippo.carletti@gmail.com>
MRU patch https://github.com/ppp-project/ppp/pull/573
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22286
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Introduce the devpath option to find the control channel device from a
hardware path for a USB or a WWAN device.
This option is useful when there are multiple modems connected to the
system. The name of the control channel device of a modem can change
depending on which modem initialises first or if it was recently plugged
in. The devpath option allows specifying the hardware path of the modem
where the control channel device will be found using that.
For the USB device hardware path, it is allowed to specify the USB port
number the modem is directly connected to.
If the device and devpath options are both set, devpath takes precedence
over device.
The USB device hardware path of a control channel device can be found by:
readlink -f /sys/class/usbmisc/cdc-wdmX/device
The WWAN device hardware path of a control channel device can be found by:
readlink -f /sys/class/wwan/wwanXqmiX/device
An example uci configuration would be:
config interface 'wwan_usb1'
option proto 'qmi'
option auth 'none'
option devpath '/sys/devices/platform/1e1c0000.xhci/usb1/1-1'
option apn 'internet'
option pdptype 'ipv4v6'
Or:
config interface 'wwan_pcie1'
option proto 'qmi'
option auth 'none'
option devpath '/sys/devices/platform/soc/11280000.pcie/pci0003:00/0003:00:00.0/0003:01:00.0'
option apn 'internet'
option pdptype 'ipv4v6'
Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com>
Introduce the devpath option to find the control channel device from a
hardware path for a USB or a WWAN device.
This option is useful when there are multiple modems connected to the
system. The name of the control channel device of a modem can change
depending on which modem initialises first or if it was recently plugged
in. The devpath option allows specifying the hardware path of the modem
where the control channel device will be found using that.
For the USB device hardware path, it is allowed to specify the USB port
number the modem is directly connected to.
If the device and devpath options are both set, devpath takes precedence
over device.
The USB device hardware path of a control channel device can be found by:
readlink -f /sys/class/usbmisc/cdc-wdmX/device
The WWAN device hardware path of a control channel device can be found by:
readlink -f /sys/class/wwan/wwanXmbimX/device
An example uci configuration would be:
config interface 'wwan_usb1'
option proto 'mbim'
option auth 'none'
option devpath '/sys/devices/platform/1e1c0000.xhci/usb1/1-1'
option apn 'internet'
option pdptype 'ipv4v6'
Or:
config interface 'wwan_pcie1'
option proto 'mbim'
option auth 'none'
option devpath '/sys/devices/platform/soc/11280000.pcie/pci0003:00/0003:00:00.0/0003:01:00.0'
option apn 'internet'
option pdptype 'ipv4v6'
Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com>
The key variable is not defined in the scope when setting wpa_psk. Use
config.key instead.
This fixes configuration the 64 characters wpa_psk directly.
Reported-by: donjoe in OpenWrt Forum
Link: https://github.com/openwrt/openwrt/pull/22182
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Due to a missing include, the constant UINT_MAX is undefined. This
fixes issues when building v25.12.0-rc5. Including a newer version of
iproute2 would include the patch, but causes other building issues.
Signed-off-by: Jonas Lochmann <openwrt@jonaslochmann.de>
Link: https://github.com/openwrt/openwrt/pull/22128
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Use substr() instead of array index syntax to access the first
character of the endpoint host string, as ucode does not support
array-style indexing on strings.
Fixes: https://github.com/openwrt/openwrt/issues/22116
Fixes: 8f977b4a40 ("wireguard-tools: fix handling of multi-value config options")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Config options like addresses and ip6prefix can be passed as either a
space-separated string or an array. Add a to_array() helper and use it
consistently for all multi-value options (addresses, ip6prefix,
allowed_ips).
Fixes: https://github.com/openwrt/openwrt/issues/22102
Fixes: 41bc454602 ("wireguard-tools: rewrite proto handler in ucode")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Without initializing pwd_group, it's set to 0, which is reserved value.
When EAP-PWD is used in wpa_supplicant/eapol_test, next error is seen:
EAP-PWD: Server EAP-pwd-ID proposal: group=0 random=1 prf=1 prep=0
EAP-pwd: Unsupported or disabled proposal
Signed-off-by: Yaroslav Isakov <yaroslav.isakov@gmail.com>
Secondary BSSes inherit the alloc value which bypasses
NL80211_ATTR_VIF_RADIO_MASK in nl80211_create_iface() and causes the
kernel to default new interfaces to all radios.
The ucode bss_create fallback fails to correct this because
the interface is already UP.. the kernel rejects SET_INTERFACE with
-EBUSY.
Signed-off-by: Chad Monroe <chad@monroe.io>
Add the OpenWrt CPPFLAGS to the CFLAGS. ebtables does not
support CPPFLAGS. This fixes fortify sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add the OpenWrt CPPFLAGS to the CFLAGS. arptables does not
support CPPFLAGS. This fixes fortify sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add the OpenWrt CPPFLAGS to the FLAGS. iwinfo does not support CPPFLAGS.
This fixes fortify sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add the OpenWrt CPPFLAGS to the CFLAGS. wireless-tools does not
support CPPFLAGS. This fixes fortify sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Forward the OpenWrt CPPFLAGS to the compile process. This fixes fortify
sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Forward the OpenWrt CPPFLAGS to the compile process. This fixes fortify
sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Forward the OpenWrt CPPFLAGS to the compile process. This fixes fortify
sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Forward the OpenWrt CPPFLAGS to the compile process. This fixes fortify
sources support.
Link: https://github.com/openwrt/openwrt/pull/22056
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add optional chaining when accessing device config in the wifi-iface
loop to handle cases where a referenced device doesn't exist.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit ebd2fefea5152d032cded1ccc7cf6e731b5bbcc2)
This should not be defaulted to anything in the schema.
What seemed like a minor cleanup actually broke this
as the schema defines a default value already. I did
not notice as I had this explictly set in my config.
Fixes: 70ba7512 ("wifi-scripts: ucode: allow sae_pwe to be modified for AP mode")
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/22043
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some Android devices have issues with H2E causing downgrades to PSK
when using WPA2/3. With WPA3 it doesn't work reliably whatsoever.
My Samsung A55/6 for example has the following behavior:
daemon.info hostapd: lan5g: STA <redacted> IEEE 802.11: authenticated
daemon.notice hostapd: SAE: <redacted> indicates support for SAE H2E, but did not use it
daemon.info hostapd: lan2g: STA <redacted> IEEE 802.11: authenticated
daemon.info hostapd: lan2g: STA <redacted> IEEE 802.11: associated (aid 1)
daemon.notice hostapd: lan5g: Prune association for <redacted>
daemon.notice hostapd: lan2g: AP-STA-CONNECTED <redacted> auth_alg=open
daemon.info hostapd: lan2g: STA <redacted> RADIUS: starting accounting session 8234C696AAC1AE7D
daemon.info hostapd: lan2g: STA <redacted> WPA: pairwise key handshake completed (RSN)
daemon.notice hostapd: lan2g: EAPOL-4WAY-HS-COMPLETED <redacted>
This is also brought up in the issue: https://github.com/openwrt/openwrt/issues/9963
Ultimately this allows users to have the option to at the very least
disable H2E.
Unrelated: a minor cleanup was done so that ieee80211w uses set_default instead.
There is no functional change on that front.
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/22021
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
- uclient-fetch timeout bumped from 5s to 15s. If we do not do this
we get flagged by HE as the update request is expensive and takes
more than 5s to execute. Currently 5s timeout causes uclient-fetch
to be killed prematurely as can be seen by the following log:
10:34:57 user.notice 6in4-henet: update 1/3: timeout
10:35:07 user.notice 6in4-henet: update 2/3: timeout
10:35:17 user.notice 6in4-henet: update 3/3: timeout
10:35:22 user.notice 6in4-henet: update failed
The above is the worst case, what usually happens is:
10:53:59 user.notice 6in4-henet: update 1/3: timeout
10:54:06 user.notice 6in4-henet: update 2/3: abuse
10:54:06 user.notice 6in4-henet: updated
- We now use an exponential backoff starting from 5 seconds.
- Detect ca-bundle so we don't use --no-check-certificates
unnecessarily.
- The while loop was changed so we don't retry unnecessarily
after the final failure.
- Worst-case total time the update operation might take before
bailing out is:
(sum(15 + (5 × (2^(x − 1))), 1, 2) + 15) seconds = 1 min
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/22016
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Increase PKG_RELEASE so buildbots pick up and rebuild the updated
package files.
Fixes: c752525511 ("xdp-tools: add patch to fix stddef.h build issue")
Link: https://github.com/openwrt/openwrt/pull/21988
Signed-off-by: Nick Hainke <vincent@systemli.org>
Add a patch that avoids including <stddef.h> in BPF headers, fixing
build failures on OpenWrt toolchains where the header is unavailable:
In file included from xdpfilt_dny_udp.c:10:
In file included from ./xdpfilt_prog.h:24:
../lib/../headers/xdp/parsing_helpers.h:18:10: fatal error: 'stddef.h' file not found
18 | #include <stddef.h>
| ^~~~~~~~~~
1 error generated.
make[5]: *** [../lib/common.mk:111: xdpfilt_dny_udp.o] Error 1
make[4]: *** [Makefile:40: xdp-filter] Error 2
Link: https://github.com/openwrt/openwrt/pull/21972
Signed-off-by: Nick Hainke <vincent@systemli.org>
When config_change is set during an active setup (e.g. by a concurrent
reconf call), wdev_mark_up() attempted to call setup() while still in
"setup" state. Since setup() requires state "up" or "down", it silently
returned, leaving the state as "setup". The subsequent wdev_setup_cb()
then treated this as a setup failure, triggering an unnecessary
teardown+restart cycle.
Fix this by removing the config_change handling from wdev_mark_up() and
moving it to wdev_setup_cb() instead. wdev_mark_up() now always
transitions to "up" state. When wdev_setup_cb() runs afterwards and
finds the device already "up" with config_change set, it initiates a
clean re-setup from the "up" state where setup() can run.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Commit 01a87f4bd0 changed the encryption
setting of the default SSID "OpenWrt" from "none" to "open". The correct
setting as per the documentation [1] is "none", though.
While this invalid setting won't cause a wrong hostapd setup, it will
at least cause malfunction in LuCI.
Change the default encryption setting back to "none".
[1] https://openwrt.org/docs/guide-user/network/wifi/basic#encryption_modes
Fixes: 01a87f4bd0
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21925
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
