mac80211: fix compilation error for old stable kernel version
Fix compilation error for old stable version caused by
genlmsg_multicast_allns backport fix pushed middle version.
Version 5.15 version 0-169, 6.1 version 0-115, 6.6 version 0-58 have the
old genlmsg_multicast_allns version with flags variable.
Compiling backport project with these version result in a compilation
error. To handle this, introduce a backport function for the affected
kernel version.
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op replace oui 33:44:55 subtype fe
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:44 subtype e8
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:33 subtype 42
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:33 subtype 42
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:31 subtype 2c
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:31 subtype 2c
Sat Mar 16 19:11:39 2024 daemon.warn lldpcli[10915]: invalid OUI value '3322'
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: an error occurred while executing last command
Sat Mar 16 19:11:39 2024 daemon.warn lldpcli[10915]: invalid OUI value '3312'
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: an error occurred while executing last command
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: lldpd should resume operations
( The last two TLV are invalid: their oui must be three hex bytes, comma
separated. Only the first hex byte of oui-info 5555555555 is used )
Quoting the kconfig description for CONFIG_PCPU_DEV_REFCNT:
network device refcount are using per cpu variables if this option is
set. This can be forced to N to detect underflows (with a performance
drop).
This was introduced from kernel 5.13 and was wrongly set as disabled.
Some target actually enables it but this should be always enabled unless
refcount needs to be debugged (unlikely for production images)
Enable in generic and drop the entry in every other target.
With upstream changes hitting kernel 6.4 the dtb for u7623 ends up with
both mac (gmac) disabled, since this is now the default status in
mt7623.dtsi. Fix this by including mt7623a.dtsi (which already has all
necessary bits) and enabling all revlevant ports. This will also do
a side hustle of assigning proper clocks for power controller and
specifying proper power domain for few devices.
Apparently U-Boot will discard whole node if requested pin function is
unknown to the driver. This resulted in inability to interact with
U-Boot on the said board, as U-Boot always assumed the recovery key
pressed and issued recovery procedure. Log snippet:
Recovery procedure also booted recovery image, which didn't affect much
the 23.05.x release, since the root fs argument was valid, so changes
persisted. But as 24.10.x hit with fitblk, the board will boot only
recovery image (initramfs) because of default bootargs will reset on each
boot and U-Boot provided bootargs took precedence.
Like #15865, it seems that gmac0 does not rename eth0 to dsa until after the
switch ports are initialized, leading to a name collision (error -17 = EEXIST).
This patch follows #17062 by using openwrt,netdev-name to fix the collision.
Thomas Richard [Mon, 24 Feb 2025 10:15:51 +0000 (11:15 +0100)]
optee-os.mk: override default PATH to not use hostpkg python
In some cases hostpkg python from packages feed is used (hostpkg has higher
priority in PATH) which causes build failure (cryptography module is
missing). So override PATH to not use hostpkg python.
local access.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel disclosed
that some processor models were already fixed by a previous
microcode update.
- Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Added mitigations for more processor models.
* Updated Microcodes:
sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
* source: update symlinks to reflect id of the latest release, 20241112
* Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
some processor models.
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 15:37:40 -0300
* New upstream microcode datafile 20241029
- Not relevant for operating system microcode updates
- Only when loaded from firmware, this update fixes the critical,
potentially hardware-damaging errata RPL061: Incorrect Internal
Voltage Request on Raptor Lake (Core 13th/14th gen) Intel
processors.
* Updated Microcodes:
sig 0x000b0671, pf_mask 0x32, 2024-08-29, rev 0x012b, size 211968
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 14:49:03 -0300
* New upstream microcode datafile 20240910 (closes: #1081363)
- Mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Fixes for unspecified functional issues on several processor models
- The processor voltage limit issue on Core 13rd/14th gen REQUIRES A
FIRMWARE UPDATE. It is present in this release for sig 0xb0671, but
THE VOLTAGE ISSUE FIX ONLY WORKS WHEN THE MICROCODE UPDATE IS LOADED
THROUGH THE FIT TABLE IN FIRMWARE. Contact your system vendor for a
firmware update that includes the appropriate microcode update for
your processor.
* Updated Microcodes:
sig 0x00090672, pf_mask 0x07, 2024-02-22, rev 0x0036, size 224256
sig 0x00090675, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f2, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f5, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000906a3, pf_mask 0x80, 2024-02-22, rev 0x0434, size 222208
sig 0x000906a4, pf_mask 0x80, 2024-02-22, rev 0x0434
sig 0x000a06a4, pf_mask 0xe6, 2024-06-17, rev 0x001f, size 137216
sig 0x000b0671, pf_mask 0x32, 2024-07-18, rev 0x0129, size 215040
sig 0x000b06a2, pf_mask 0xe0, 2024-02-22, rev 0x4122, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06a8, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06e0, pf_mask 0x19, 2024-03-25, rev 0x001a, size 138240
* Update changelog for 3.20240813.1 with new information
* Update changelog for 3.20240514.1 with new information
* source: update symlinks to reflect id of the latest release, 20240910
* New upstream microcode datafile 20240813 (closes: #1078742)
- Mitigations for INTEL-SA-01083 (CVE-2024-24853)
Incorrect behavior order in transition between executive monitor and SMI
transfer monitor (STM) in some Intel Processors may allow a privileged
user to potentially enable escalation of privilege via local access.
- Mitigations for INTEL-SA-01118 (CVE-2024-25939)
Mirrored regions with different values in 3rd Generation Intel Xeon
Scalable Processors may allow a privileged user to potentially enable
denial of service via local access.
- Mitigations for INTEL-SA-01100 (CVE-2024-24980)
Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel
Xeon Processors may allow a privileged user to potentially enable
escalation of privilege via local access.
- Mitigations for INTEL-SA-01038 (CVE-2023-42667)
Improper isolation in the Intel Core Ultra Processor stream cache
mechanism may allow an authenticated user to potentially enable
escalation of privilege via local access. Intel disclosed that some
processor models were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01046 (CVE-2023-49141)
Improper isolation in some Intel Processors stream cache mechanism may
allow an authenticated user to potentially enable escalation of
privilege via local access. Intel disclosed that some processor models
were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel released this
information during the full disclosure for the 20241112 update.
Processor signatures 0x606a6 and 0x606c1.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Intel released this information during the full disclosure
for the 20240910 update. Processor signatures 0x5065b, 0x606a6,
0x606c1.
- Fix for unspecified functional issues on several processor models
- Fix for errata TGL068/ADL075/ICL088/... "Processor may hang during a
microcode update". It is not clear which processors were fixed by this
release, or by one of the microcode updates from 2024-05.
- Mitigations for INTEL-SA-01213 (CVE-2024-36293)
Improper access control in the EDECCSSA user leaf function for some
Intel Processors with Intel SGX may allow an authenticated user to
potentially enable denial of service via local access. Intel released
this information during the full disclosure for the 20250211 update.
Processor signature 0x906ec (9th Generation Intel Core processor).
* Updated microcodes:
sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936
sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720
sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224
sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032
sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688
sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640
sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328
sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448
sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472
sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496
sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480
sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472
sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496
sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496
sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496
sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304
sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280
sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544
sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216
* source: update symlinks to reflect id of the latest release, 20240813
* postinst, postrm: switch to dpkg-trigger to run update-initramfs
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 15 Aug 2024 14:41:50 -0300
Tianling Shen [Sun, 2 Mar 2025 12:06:49 +0000 (20:06 +0800)]
ramips: fix reading mac address for hiwifi hc5962
The spaces in variables have been stripped since commit 551e04f3c9c0
("base-files: strip space and tab characters from ASCII mac address"),
resulting "Vfac_mac " matches nothing. Fix the issue by removing the
space at end.
MAC Addresses:
- There is one on the label, e.g. xx:xx:xx:xx:xx:A4
- LAN (bottom connector) is the same as the label, e.g. xx:xx:xx:xx:xx:A4
- WAN (top connector) is label + 1, e.g. xx:xx:xx:xx:xx:A5
- WLAN (2.4G) is the same as the label, e.g. xx:xx:xx:xx:xx:A4
- WLAN (5G) is label + 2, e.g. xx:xx:xx:xx:xx:A6
UART:
- is available via the pin holes on the board
- The pinout is printed to the board: P: VCC, G: GND, R: RX, T:TX
- RX and TX require solder bridges to be installed
- Do NOT connect VCC
- Settings: 3.3V, 115200, 8N1
GPIO:
- There are two LEDs: Red (GPIO 4) and White (GPIO 0)
- There are two buttons: Reset (GPIO 11) and WPS (GPIO 5)
Migration to OpenWrt:
- Download the migration image from the Cudy website (it should be available as soon as OpenWrt officially supports the device)
- Connect computer to LAN (bottom connector) and flash the migration image via OEM web interface
- OpenWrt is now accessible via 192.168.1.1
Revert back to OEM firmware:
- Set up a TFTP server on IP 192.168.1.88 and connect to the WAN port (upper port)
- Provide the Cudy firmware as recovery.bin in the TFTP server
- Press the reset button while powering on the device
- Recovery process is started now
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
General information:
- No possibility to load a initramfs image via U-Boot because there is no option to interrupt U-Boot
Adds latest 6.6 patches from the Raspberry Pi repository.
These patches were generated from:
https://github.com/raspberrypi/linux/commits/rpi-6.6.y/
With the following command:
git format-patch -N v6.6.83..HEAD
(HEAD -> 08d4e8f52256bd422d8a1f876411603f627d0a82)
Felix Fietkau [Sun, 9 Mar 2025 15:43:58 +0000 (16:43 +0100)]
unetd: update to Git HEAD (2025-03-09)
d8b43985e4d7 ubus: fix token_create policy 7326459bd743 ubus: dump service information on network_get 6c9c8fbd8128 service: add @all as alias for all members, unless defined differently
MAC Addresses:
- There is one on the label, e.g. xx:xx:xx:xx:xx:1C
- LAN (bottom connector) is the same as the label, e.g. xx:xx:xx:xx:xx:1C
- WAN (top connector) is label +2, e.g. xx:xx:xx:xx:xx:1E
- WLAN (2.4G) is the same as the label, e.g. xx:xx:xx:xx:xx:1C
- WLAN (5G) is the same as WAN, e.g. xx:xx:xx:xx:xx:1E
UART:
- is available via the pin holes on the board
- From inner to outer pin: TX, RX, GND, VCC
- Do NOT connect VCC
- Settings: 3.3V, 115200, 8N1
GPIO:
- There are two LEDs: Red (GPIO 3) and White (GPIO 4)
- There are two buttons: Reset (GPIO 8) and WPS (GPIO 10)
Migration to OpenWrt:
- Download the migration image from the Cudy website (it should be available as soon as OpenWrt officially supports the device)
- The migration image is also available here until a image is provided by Cudy: https://github.com/RolandoMagico/openwrt-build/releases/tag/M1300_Build_20240222
- File: openwrt-ramips-mt7621-cudy_m1300-v2-squashfs-flash-signed.bin
- Connect computer to LAN (bottom connector) and flash the migration image via OEM web interface
- In the migration image, LAN and WAN are swapped. Computer must be connected to the other port after flashing
- OpenWrt is now accessible via 192.168.1.1
- After flashing an up to date OpenWrt image, LAN and WAN settings are again the same as in the OEM firmware
- So use the other connector again
Revert back to OEM firmware:
- Set up a TFTP server on IP 192.168.1.88 and connect to the LAN port (lower port)
- Provide the Cudy firmware as recovery.bin in the TFTP server
- Press the reset button while powering on the device
- Recovery process is started now
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
General information:
- No possibility to load a initramfs image via U-Boot because there is no option to interrupt U-Boot
The fixes are only for the WRT1900X and WRT1200AC.
It contains:
Deletes the driver's ability to modify the debit table.
Remove skb_get(done_skb) in txdone
Reworking ISR
clean code
Napi replaces tasklet
Add rx_decrypt feature
Andreas Gnau [Tue, 7 Jan 2025 22:55:12 +0000 (23:55 +0100)]
ramips: Add support for Genexis / Inteno Pulse EX400
Add support for Genexis Pulse EX400 / Inteno Pulse EX400. A branded
variant for the Finnish ISP DNA has already been added in fea2264d9fdd
(ramips: mt7621: Add DNA Valokuitu Plus EX400, 2023-07-31). This commit
adds support for the generic variants with Inteno and Genexis branding.
Inteno changed its name to Genexis and both brandings exist.
In terms of electronics, there is no difference between the DNA-branded
version and other brandings. LED markings on the case are different,
though. While the DNA-version has a "software-update" LED, the other
versions have a WPS LED. To reduce user confusion, create a separate
image.
Add the different device-tree with the different LED and rename things
to work the same way for both variants.
Firmware:
The vendor firmware is a fork of OpenWrt (Reboot) with a kernel version
4.4.93. The flash is arranged as below and there is a dual boot
mechanism alternating between rootfs_0 and rootfs_1.
In OpenWrt rootfs_0 will be used as a boot partition that will contain the
kernel and the dtb. The squashfs rootfs and overlay are standard OpenWrt
behaviour.
U-boot:
With proper serial access, booting can be halted to U-boot by pressing
any key. TFTP and flash writes are available, but only the first one has
been tested.
NOTE: Recovery mode can be accessed by holding down the reset button while
powering on the device. The led 'Update' will show a solid green light
once ready. A web server will be running at 192.168.1.1:80 and it will
allow flashing a firmware package. You can cycle between rootfs_0 and
rootfs_1 by pressing the reset button once.
Root password:
With the vendor web UI create a backup of your settings and download the
archive to your computer. Within the archive in the file
/etc/shadow replace the password hash for root with that of a password you
know. Restore the configuration with the vendor web UI and you will have
changed the root password.
SSH access:
You might need to enable the SSH service for LAN interface as by default
it's enabled for WAN only.
Installing OpenWrt:
With the vendor web UI, or from the U-Boot recovery UI, install the
OpenWrt factory image. Alternatively, ssh to the device and use
sysupgrade -n from cli.
Finalize by installing the OpenWrt sysupgrade image to get a fully
functioning system.
Reverting to the vendor firmware:
Boot with OpenWrt initramfs image
- Remove volumes rootfs_0, rootfs and rootfs_data and create vendor
volumes.
Andreas Gnau [Tue, 7 Jan 2025 22:04:30 +0000 (23:04 +0100)]
ramips: mt7621: Move common DNA EX400 defs to dtsi
Move common definitions for DNA Valokuitu Plus EX400 to a dtsi include.
This is in preparation of adding the non-branded variant of the device
produced by Genexis / Inteno in the next commit. The device with DNA
branding differs in the LED labling on the device.
Coia Prant [Tue, 11 Mar 2025 03:33:00 +0000 (11:33 +0800)]
ramips: add support for Hongdian H8922 v30
This is an industrial 4G router equipped with OpenWrt 14.07 OEM
customized version
WARNING: The original firmware device tree is common to multiple
boards, and the device tree name is H9350. This submitted device
tree is a modified version, which deletes the non-this-device parts
and adds GPIO watchdog.
Issue:
- No factory partition, eeprom is located
at /lib/firmware/mt7620a.eeprom
Flash instruction:
Using UART:
1. Configure PC with a static IP address and setup an TFTP server.
2. Put rootfs into the tftp directory.
3. Connect the UART line as described on the PCB.
4. Power up the device and press Ctrl+C to break auto boot.
5. Use `system 6` command and follow the instruction to set device
and tftp server IP address and input the rootfs file name.
U-boot will then load the rootfs and write it into
the flash.
6. Use `system 1` command and follow the instruction to set device
and tftp server IP address and input the firmware file name.
U-boot will then load the firmware once.
7. Login to LuCI and use LuCI upgrade firmware.
Original Firmware Dump / More details:
https://blog.gov.cooking/archives/research-hongdian-h8922-and-flash.html
Coia Prant [Tue, 11 Mar 2025 03:21:33 +0000 (11:21 +0800)]
mac80211: rt2x00: load the eeprom data from devicetree embedded data on Ralink SoCs
It will allow loading eeprom from eeprom-data embedded in device tree.
Ported from mediatek mt76 wireless driver (drivers/net/wireless/mediatek/mt76/eeprom.c)
Tianling Shen [Wed, 26 Feb 2025 13:52:53 +0000 (21:52 +0800)]
mediatek: add support for CMCC A10
This board is also as known as SuperElectron ZN-M5 and ZN-M8. However,
for ZN-M5 and ZN-M8, there's another version uses ZX279128 as CPU
chip, which is unsupported.
You can check it in "高级设置" > "系统日志" > "内核日志" page from webUI.
Stock layout flash instructions:
Login into webUI and upload sysupgrade firmware in "系统管理" > "升级固件" page.
Remember to unselect "保留配置" ("Keep configurations") first before doing that.
OpenWrt U-Boot layout flash instructions:
1. Flash stock layout firmware first.
2. Connect to the device via SSH, and backup everything,
especially 'Factory' partition.
3. Unlock MTD partitions:
opkg update && opkg install kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
4. Write new BL2 and FIP:
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-preloader.bin BL2
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-bl31-uboot.fip FIP
5. Set static IP on your PC:
IP 192.168.1.254/24, GW 192.168.1.1
6. Serve OpenWrt initramfs image using TFTP server.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt has booted, perform sysupgrade.
Daniel Golle [Mon, 3 Mar 2025 13:27:15 +0000 (13:27 +0000)]
libpcap: backport support for various DSA tags
Trying to tcpdump DSA conduits results in errors such as
"unsupported DSA tag: mtk".
Backport two commits adding support for various DSA tags to libpcap.
Robert Marko [Thu, 27 Feb 2025 10:05:26 +0000 (11:05 +0100)]
libpcap: add missing PKG_CONFIG_DEPENDS entries
Currently, enabling USB, BT or Netfilter support after initial compilation
will not trigger a rebuild, so add the missing PKG_CONFIG_DEPENDS so
that rebuild gets triggered.
Eric ZHANG [Sun, 2 Mar 2025 07:54:37 +0000 (15:54 +0800)]
dnsmasq: fix handlers for options `filter_rr` and `cache_rr`
According to:
- https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js#L700
- https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js#L402
These two options should be of type `MultiValue` but here there're used as single value. This results in dnsmasq crashes when either of these options are set with multiple values, which leads to an invalid space-separated value.
As these options are designed to take multiple values, I think it's better to use list format eg. `list filter_rr 'AAAA'`, instead of `option filter_rr 'AAAA,HTTPS'`.
Martin Schiller [Thu, 6 Mar 2025 08:38:12 +0000 (09:38 +0100)]
mediatek: Refresh kernel configuration
I selected one subtarget after the other and refreshed their
configuration using this command:
make kernel_oldconfig CONFIG_TARGET=subtarget
For MT7629 I had to re-add CONFIG_LEDS_SMARTRG_LED manually.
Otherwise, building MT7629 with ALL_KMODS we get prompted for
LEDS_SMARTRG_LED and this will break CI and in future buildbot
compilation. See commit 6bdea8c7bd85 ("mediatek: mt7629: 6.6: disable
LEDS_SMARTRG_LED by default") for more details.
Ahmed Naseef [Tue, 28 Jan 2025 07:28:31 +0000 (11:28 +0400)]
kernel: usbnet: Restore usb%d naming for cdc-ethernet devices with local MAC
Prior to commit https://github.com/torvalds/linux/commit/8a7d12d674ac6f2147c18f36d1e15f1a48060edf,
cdc-ethernet USB LTE modems (e.g. Quectel EC200A) were consistently named
usb0. After 8a7d12d67, devices began renaming to eth1 due to an assumption
that local MAC addresses originate exclusively from the kernel. Some
devices provide driver-assigned local MACs, causing point-to-point
interfaces with driver-set MACs to adopt eth%d names instead of usb%d.
Restore the naming exception for point-to-point devices: interfaces
without driver MACs or with driver-provided local MACs will retain the
usb%d convention. This addresses issues reported in [1] and fixed in [2].
Matthew Cather [Mon, 3 Mar 2025 21:46:03 +0000 (15:46 -0600)]
hostapd: get reference to object before removal
`ucv_array_set` releases the array's reference to the object being cleared.
If this is the last reference to the object, it will be freed, making our
pointer `val` invalid.
To avoid this, we need to obtain our own reference to the object so we
can safely return `val`.
Matthew Cather [Mon, 3 Mar 2025 20:00:35 +0000 (14:00 -0600)]
hostapd: consistent reference counting for registry
Since `wpa_ucode_registry_add` collects its own reference to the values added, the
two functions `hostapd_ucode_bss_get_uval` and `hostapd_ucode_iface_get_uval` would
sometimes return a referenced object (from `uc_resource_new`) and sometimes return
an unreferenced object (from `wpa_ucode_registry_get`). Now, both functions always
return a referenced object.
This change also indirectly fixes `hostapd_ucode_bss_get_uval`, ensuring it now
always returns a referenced object.
Signed-off-by: Matthew Cather <mattbob4@gmail.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 7729f960933a03c9eebd2b65a695ea57718ccb77)
Matthew Cather [Mon, 3 Mar 2025 19:40:39 +0000 (13:40 -0600)]
hostapd: clean-up references to local variables
Remove extra ucv_get calls when passing a referenced value to an object
without using it further.
Signed-off-by: Matthew Cather <mattbob4@gmail.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 22eaf1864731dd29918357b26565dbd9420fd314)
Matthew Cather [Mon, 3 Mar 2025 19:22:11 +0000 (13:22 -0600)]
hostapd: fix ucode memory leak with strings
This fixes a common reference counting bug typically along the lines of:
```
uc_value_push(ucv_get(ucv_string_new(...)));
```
This would leave our new string with a reference count of 2, one from
the construction of the string, the other from `ucv_get`. This would
prevent the strings from being correctly cleaned up when it goes out
of scope.
Cedric CHEDALEUX [Mon, 17 Feb 2025 09:44:36 +0000 (10:44 +0100)]
scripts/feeds: shallow clone submodules
When a feed has submodules, all its submodules are fully cloned whereas
the feed itself is shallowed. Let's be consistent and perform shallow clones
as well for the submodules.
Cedric CHEDALEUX [Mon, 17 Feb 2025 09:41:32 +0000 (10:41 +0100)]
scripts/feeds: shallow clone for specific commit update
When a feed is referenced with a specific commit (i.e. <git_url>^<sha1>),
a full clone was performed and a branch was created from the sha1
and named with the sha1. Other git clones operations are shallowed.
As Git does not support clone at a specific commit, let's first perform
a shallow clone to latest commit, then fetch the relevant commit and
finally checkout it (no more 'pseudo' branch).
It saves bandwith and significantly speeds up the feed update process.
Felix Fietkau [Fri, 28 Feb 2025 15:27:36 +0000 (16:27 +0100)]
unetd: update to Git HEAD (2025-02-28)
75a236be122a service: add missing null pointer check f5341f327539 ubus: add api for generating and validating security tokens 3fab99eab4d5 add udebug support 28d86bd30e97 pex: only respond to update requests when we have network data 8e6f37cc361e pex-msg: ignore no-data responses if version is zero 12e6cf7f63e1 pex: create pex host from update responses edc8fdae463a ubus: show the local addresses in network status
Daniel Golle [Wed, 12 Feb 2025 04:21:22 +0000 (04:21 +0000)]
ethtool: work-around ETHTOOL_GRSSH/ETHTOOL_SRSSH ABI breakage
ethtool since version 6.9 introduced support for getting/setting RSS
input transformation supported in Linux since version 6.8.
The now changed kernel ioctl ABI, however, cannot be detected from
userland, and ethtool since version 6.9 simply assumes that a previously
reserved field is now used to set the input transformation.
Unfortunately the default value RXH_XFRM_NO_CHANGE (0xff) used by ethtool
userland creates an incompatibility with older kernels which cannot be
resolved easily without introducing even more ABI breakage.
Work-around the issue and fix support for --set-rxfh and --set-rxfh-indir
ethtool userland tool commands by making the support for input_xfrm
conditional on compile time, and keep it disabled for Linux 6.6.
Fixes: 8c2dcd1518 ("ethtool: update to 6.10") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Stijn Segers <foss@volatilesystems.org>
(cherry picked from commit 3a7467ffde413677de5465dde78a62dfa8d6774f)
Notes:
* The device supports dual boot mode
* Fn led reassigned to wlan 2.4
Flash instruction:
The only way to flash OpenWrt image is to use tftp recovery mode in U-Boot:
1. Configure PC with static IP 192.168.1.2/24 and tftp server.
2. Rename "openwrt-mediatek-filogic-keenetic_kn-3811-squashfs-factory.bin"
to "KN-3811_recovery.bin" and place it in tftp server directory.
3. Connect PC with ethernet port, press the reset button, power up
the device and keep button pressed until status led start blinking.
4. Device will download file from server, write it to flash and reboot.
Flash instruction:
The only way to flash OpenWrt image is to use tftp recovery mode in U-Boot:
1. Configure PC with static IP 192.168.1.2/24 and tftp server.
2. Rename "openwrt-mediatek-filogic-keenetic_kn-3911-squashfs-factory.bin"
to "KN-3911_recovery.bin" and place it in tftp server directory.
3. Connect PC with ethernet port, press the reset button, power up
the device and keep button pressed until status led start blinking.
4. Device will download file from server, write it to flash and reboot.
John Audia [Wed, 12 Feb 2025 13:56:47 +0000 (08:56 -0500)]
openssl: update to 3.0.16
Changes between 3.0.15 and 3.0.16 [11 Feb 2025]
CVE-2024-13176[1] - Fixed timing side-channel in ECDSA signature
computation.
There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In
particular the NIST P-521 curve is affected. To be able to measure this
leak, the attacker process must either be located in the same physical
computer or must have a very fast network connection with low latency.
CVE-2024-9143[2] - Fixed possible OOB memory access with invalid
low-level GF(2^m) elliptic curve parameters.
Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit
values for the field polynomial can lead to out-of-bounds memory reads
or writes. Applications working with "exotic" explicit binary (GF(2^m))
curve parameters, that make it possible to represent invalid field
polynomials with a zero constant term, via the above or similar APIs,
may terminate abruptly as a result of reading or writing outside of
array bounds. Remote code execution cannot easily be ruled out.
Rudy Andram [Wed, 12 Feb 2025 19:28:49 +0000 (19:28 +0000)]
wireless-regdb: Update to version 2025.02.20
b43aeb5 wireless-regdb: assert and correct maximum bandwidth within frequency difference 68588bf wireless-regdb: Update regulatory info for Syria (SY) for 2020 0dda57e wireless-regdb: Update regulatory info for Moldova (MD) on 6GHz for 2022 b19ab0b wireless-regdb: Update regulatory info for Azerbaijan (AZ) on 6GHz for 2024 f67f40d wireless-regdb: Update regulatory info for Oman (OM) bd70876 wireless-regdb: Update regulatory rules for Armenia (AM) on 2.4 and 5 GHz 6c7cbcc wireless-regdb: Permit 320 MHz bandwidth in 6 GHz band in ETSI/CEPT f9f6b30 wireless-regdb: Update regulatory rules for Austria (AT) 39b47ea wireless-regdb: Update regulatory info for Cayman Islands (KY) for 2024 3dd7ceb wireless-regdb: allow NO-INDOOR flag in db.txt 4d754a1 wireless-regdb: Update regulatory rules for Iran (IR) on both 2.4 and 5Ghz for 2021 8c8308a wireless-regdb: Update frequency range with NO-INDOOR for Oman (OM) c2f11e2 wireless-regdb: update regulatory database based on preceding changes
The proposed detection method was based on reading the LAUNCH_FREADY core flag.
However, this method only works before the cores are launched.
For this reason, the core number detection method has been changed to a simpler one.
For mt6721s the 17th revision bit is zero, hence we know that it is this chip,
so the number of cores is 1.
Sander Vanheule [Sat, 22 Feb 2025 11:06:10 +0000 (12:06 +0100)]
realtek: add PoE enable line to Netgear GS310TP
By switching to the new RTL8231 driver in commit b7af54d5c18c ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Evan Jobling [Thu, 23 Jan 2025 00:13:35 +0000 (00:13 +0000)]
realtek: HPE 1920-48G-PoE: allow fan speed control
The JG928A has an RTL8231 on the aux mdio bus. Add it to dts to expose
the GPIO pins used to control and monitor the fan speed. To enable speed
control, add the appropriate kernel driver module to DEVICE_PACKAGES.
Of note, this does not control all fans for the unit. The power supply
fans are not controlled.
Sander Vanheule [Tue, 28 Jan 2025 07:14:03 +0000 (08:14 +0100)]
realtek: drop old RTL8231 driver
The old RTL8231 driver integrated the MDIO bus access with the GPIO
control ops, making this driver not very portable to newer platforms.
It depended on the SoC ID instead of the compatible to determine the
MDIO access register, further complicating portability.
A new MFD driver is now available, which offers proper pin config as
well as optional LED support, which can work on any (bitbanged) MDIO
bus. Now that all devices have been migrated, we can drop the old code.
Sander Vanheule [Mon, 27 Jan 2025 21:17:57 +0000 (22:17 +0100)]
realtek: add PoE enable line to Netgear GS110TPP
By switching to the new RTL8231 driver in commit b7af54d5c18c ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Sander Vanheule [Sun, 12 Jan 2025 16:57:33 +0000 (17:57 +0100)]
realtek: switch RTL8231 driver for D-Link DGS-1210
Update the common external GPIO DTSI file for the DGS-1210 devices to
use an MDIO device on the auxilairy MDIO bus, as the original driver was
doing behind the screen.
Switching to the new driver will allow for full pin-control and will no
longer reset pin config set by the bootloader.
Sander Vanheule [Sun, 12 Jan 2025 16:53:34 +0000 (17:53 +0100)]
realtek: Switch DGS-1210-10P DTS to gpio.dtsi
The DTS file for the DGS-1210-10P is slightly different from the other
DGS-1210 devices, in that it didn't specify a gpio-restart node when it
was added. The gpio-restart has been found to work on the DGS-1210-10P
as well, so switch it over to the common definitions.
This converts the last device from the product family to the common
definition for the (external) GPIOs.
Tested-by: Michel Thill <jmthill@gmail.com> Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 7c0d1c1eb10a7040af6478742dd053f40b24a467)
Sander Vanheule [Sat, 18 Jan 2025 15:51:59 +0000 (16:51 +0100)]
realtek: Drop unused property on DGS-1210 gpio0
The 'indirect-access-id' property on gpio0 is a remnant from the
original GPIO driver. This property has not been relevant on the SoC's
embedded GPIO controller for a long time, so just drop it.
Sander Vanheule [Sat, 18 Jan 2025 20:40:06 +0000 (21:40 +0100)]
realtek: Simple conversions to RTL8231 MFD driver
Change devices with RTL8231 GPIO expander definition that can easily be
translated to the new RTL8231 binding and carry over any gpio-hogs. This
will let them use the new RTL8231 MFD driver, without any functional
changes.
Sander Vanheule [Wed, 22 Jan 2025 11:25:18 +0000 (12:25 +0100)]
realtek: Split Zyxel GS1900-8 into v1 and v2
Zyxel GS1900-8 v2 devices have been produced more recently than v1
devices. As there are v1 boards with RTL8380M rev. C SoCs, it can likely
safely be assumed that all v2 devices will also have a recent SoC
revision, supporting the hardware auxiliary MDIO controller.
Make the GS1900-8 v1 use an emulated auxiliary MDIO bus, for backward
compatibility with devices containing an RTL8380M rev. A.
Since the devicetrees are otherwise identical, GS1900-8 v1 devices with
an RTL8380M rev. B or C will also be able to use the (more efficient) v2
image. This includes any currently functioning device with OpenWrt, so
include the old compatible as a supported device for the GS1900-8 v2.
Sander Vanheule [Tue, 21 Jan 2025 18:57:22 +0000 (19:57 +0100)]
realtek: rtl838x: Enable MDIO_GPIO driver
The mdio-gpio driver is required to support early revision of RTL8380M
slicon (rev A) where the auxilairy MDIO controller does not function
correctly. Add this driver to the rtl838x kernel so devices with old
SoCs are also able to function correctly.
Sander Vanheule [Wed, 22 Jan 2025 11:16:00 +0000 (12:16 +0100)]
realtek: Move GS1900 external GPIO to new DTSI
In order to be able to define the external GPIO controller on an
emulated MDIO bus, move the controller definition outside of the main
GS1900 include for RTL838x-based devices.
Additionally, a new DTSI is provided defining the RTL8231 on the
emulated MDIO bus.
Sander Vanheule [Tue, 21 Jan 2025 18:40:11 +0000 (19:40 +0100)]
realtek: Add virtual MDIO bus on rtl838x
Some RTL8380M-based devices have been around for a long time and use an
early A revision of the RTL8380M SoC. This revision has an issue with
the auxiliary MDIO controller, causing it to malfunction. This may lead
to device reboots when the controller is used.
Provide a bit-banged MDIO bus, which muxes the auxiliary MDIO pins to
their GPIO function. Although this will result in lower performance,
there should otherwise be no functional differences.
Sander Vanheule [Tue, 21 Jan 2025 18:37:25 +0000 (19:37 +0100)]
realtek: Enable Zyxel GS1900's RTL8231 reset line
As the bootloader is reconfiguring the RTL8231 on these devices anyway,
no pin state can be maintained over warm reboots. This results in for
example the PoE disable pin always being asserted by the bootloader.
Define the GPIO line linked to the RTL8231's reset so the MDIO subsystem
will also reset the expander on boot and ensure the line in the correct
state.
Sander Vanheule [Sat, 18 Jan 2025 12:45:55 +0000 (13:45 +0100)]
realtek: rtl839x: Enable AUX MDIO controller
Enable the driver for the Realtek Otto auxiliary MDIO driver so RTL839x
devices can use it. The related node is added to the base devicetree for
rtl839x-based devices, so they can enabled and use it when required.
Sander Vanheule [Sat, 18 Jan 2025 12:28:44 +0000 (13:28 +0100)]
realtek: Update aux-mdio driver
For RTL839x, the driver was producing frequent timeouts on bus accesses.
Increasing the timeout to the one from a recent Realtek SDK resolves
these timeouts. To minimize overhead on different SoCs, each controller
can specify their own timeout.
This also add support for the register format as used on RTL93xx.
Support is added for the RTL930x "ext gpio" controller.
Sander Vanheule [Thu, 16 Jan 2025 12:23:54 +0000 (13:23 +0100)]
realtek: Use atomic poll for aux-mdio commands
regmap_read_poll_timeout() relies on usleep_range() to time the polling
loop. With the current, rather large, scheduling interval, a short
usleep_range() may take a lot longer than expected, causing performance
issues.
Switch the driver over to using regmap_read_poll_timeout_atomic(), which
uses udelay() to time the polling loop.
For comparision, the 'ethtool -m <dev>' command is about 10 times faster
with the atomic variant.
Using 'perf -r10 ethtool -m lan25':
- Driver using regmap_read_poll_timeout():
2.0117 +- 0.0118 seconds time elapsed ( +- 0.58% )
- Driver using regmap_read_poll_timeout_atomic():
0.1674 +- 0.0250 seconds time elapsed ( +- 14.95% )
Fabian Groffen [Wed, 15 Jan 2025 19:12:02 +0000 (20:12 +0100)]
realtek: HPE 1920 24G PoE+ 180W/370W move fans to hwmon
Apply the equivalent of commit f64541db020e ("realtek: HPE 1920 8G PoE+
180W move fans to hwmon") to the 24-ports variants of the HPE 1920 PoE+
switches, with model numbers JG925A and JG926A.
Copy from the original commit message:
Move to using hwmon and gpio-fan. This is by adding gpio_fan_array to
DTS and kmod-hwmon-gpiofan to DEVICE_PACKAGES.
In combination with the new rtl8231 gpio driver the default fan
behaviour will be maximum fan speed.
Bump compat value to 1.1 due to existing config in /etc/config/system
via gpio_switch. Also notify in device compat that fan is now going to
be at bootloader setting (maximum in this case) by default unless turned
down.
As the init script 03_gpio_switches does not perform any action after
removing these devices from it, the file can be dropped.
Sander Vanheule [Tue, 7 Jan 2025 13:59:20 +0000 (14:59 +0100)]
realtek: switch RTL8231 driver for HPE 1920-16/24G
Update the base DTS file for the 16 and 24 port HPE 1920 devices
(JG923A, JG924A, JG925A, JG926A), causing the new RTL8231 MFD driver to
be loaded at start-up.
Evan Jobling [Tue, 14 Jan 2025 12:13:21 +0000 (12:13 +0000)]
realtek: HPE 1920 8G PoE+ 180W move fans to hwmon
The GPIO numbering has changed and is not stable. As a result fan
control via gpio_switch is broken, resulting in errors:
"export_store: invalid GPIO 456"
Move to using hwmon and gpio-fan. This is by adding gpio_fan_array to
DTS and kmod-hwmon-gpiofan to DEVICE_PACKAGES.
In combination with the new rtl8231 gpio driver the default fan
behaviour will be maximum fan speed.
Bump compat value to 1.1 due to existing config in /etc/config/system
via gpio_switch. Also notify in device compat that fan is now going to
be at bootloader setting (maximum in this case) by default unless turned
down.
Sander Vanheule [Thu, 26 Dec 2024 21:26:33 +0000 (22:26 +0100)]
realtek: rtl838x: Switch GS1900 rtl8231 driver
Update the devicetree files to switch the GS1900 devices over to the new
pinctrl and GPIO driver. Enable the drivers to ensure the nodes can be
used.
This may fix issues caused by bad RMW behaviour on the GPIO data lines,
or glitches due to setting the pin direction before the pin level.
Although the driver supports retaining GPIO state after a warm boot,
some bootloaders appear to apply a default configuration on boot, which
may cause an interrupt in PoE-PSE support.
Sander Vanheule [Thu, 26 Dec 2024 19:55:16 +0000 (20:55 +0100)]
realtek: Add pinctrl support for RTL8231
Add pending patches to add RTL8231 support as a MDIO-bus attached
multi-functional device. This includes subdrivers for the pincontrol and
GPIO features, as well as the LED matrix support.
Leave the drivers disabled until required by a device.
Sander Vanheule [Fri, 27 Dec 2024 14:56:44 +0000 (15:56 +0100)]
realtek: rtl838x: Instantiate auxiliary MDIO bus
Add a disabled node for the auxiliary MDIO bus, used to manage the
RTL8231 expanders. A simple-mfd parent node is added, at the same
(implied) address as the switch@1b000000 node, as the switch drivers
should anyway transistion to MFD subdivices at some point.
Additionally, two pinctrl-single node are added to allow the MDX pins to
be muxed correctly, in case the bootloader leaves these unconfigured.
Sander Vanheule [Fri, 27 Dec 2024 14:53:23 +0000 (15:53 +0100)]
realtek: Add driver for auxiliary MDIO busses
Add a driver that exposes the auxiliary busses, used for the RTL8231
expanders, as a proper MDIO controller. The device must be instantiated
under an MFD device, so the driver should also be compatible with SoC
managed by an external CPU via SPI.
Leave the driver disabled in builds until required.
Daniel Golle [Mon, 10 Feb 2025 23:18:46 +0000 (23:18 +0000)]
mediatek: apply bootloader work-around for affected ASUS devices
Apply "u-boot-dont-touch-spi-nand" to ASUS RT-AX59U, ASUS TUF-AX4200 as
well as ASUS TUF-AX6000 routers to prevent U-Boot from wiping MTD
child nodes from DT.
projects / thirdparty / openwrt.git / log
