econet: Add Nokia G-240G-E and EN751221 recovery image
The Nokia G-240G-E is an xPON device with an EN7526G, 256M of
memory and 128M of flash. It has 1 USB2 port as well as phone and
ethernet but no wifi. Flashing instructions are per the typical
process using xmodem in the bootloader. This and other things
are described here: https://openwrt.org/inbox/toh/bt/g-240g-e_1
In addition, a generic image is offered, this image can be loaded
into memory from within the bootloader and launched directly. It
is recommended on the wiki of G-240G-E and other EcoNet devices
to be used for backing up the flash before flashing OpenWRT.
Shiji Yang [Mon, 19 May 2025 13:56:58 +0000 (21:56 +0800)]
mvebu: dts: fix unit name leading 0s warnings
Trim unnecessary 0s from the node name to fix the dtc warnings:
cn9131-puzzle-m901.dts:43.18-46.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
cn9130-clearfog-pro.dts:33.18-36.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
cn9132-puzzle-m902.dts:50.18-53.4: Warning (unit_address_format): /memory@00000000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:148.26-152.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00000000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:154.26-157.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00500000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:159.26-163.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00a00000: unit name should not have leading 0s
armada-385-wd_cloud-mirror-gen2.dts:165.26-168.9: Warning (unit_address_format): /soc/internal-regs/nand-controller@d0000/nand@0/partitions/partition@00f00000: unit name should not have leading 0s
David Härdeman [Fri, 10 Oct 2025 09:43:11 +0000 (11:43 +0200)]
odhcp6c: use the global DHCP DUID for DHCPv6
odhcp6c already supports custom DUIDS on a per-interface basis. When no client
identifier has been set, odhcp6c will generate one on the basis of the MAC
address of the given interface.
This is contrary to how DUIDs are meant to be used, as the client identifier
will vary from interface to interface, while it is meant to remain stable for a
given host, no matter how the network hardware changes (see RFC8415, §11).
Fix this by letting odhcp6c use the global DHCP DUID, if configured.
David Härdeman [Thu, 9 Oct 2025 14:16:53 +0000 (16:16 +0200)]
base-files: generate a global DHCP DUID
odhcp6c and odhcpd currently generate custom DUIDS on a per-interface basis
using the MAC address of the given interface.
This is contrary to how DUIDs are meant to be used, as the client identifier
will vary from interface to interface, while it is meant to remain stable for a
given host, no matter how the network hardware changes (see RFC8415, §11).
The same problem exists in odhcpd, which also generates server-side DUIDs on a
per-interface basis.
In order to support a stable per-device DUID, generate one on first boot and
store it via uci.
Currently, a DUID-UUID style clientid is generated. This is mostly meant as an
RFC, and we might consider using a different kind of DUID instead (DUID-LLT,
DUID-EN).
One drawback is that this will typically change the DUID used on existing
OpenWrt devices when upgrading to a new release. However, that seems
unavoidable and is a one-time pain in order to have stable DUIDs (and in many
cases, it shouldn't cause any issues).
v2: move the uci cfg generation outside of an IPv6-only block since this
is relevant to the DHCPv4 client as well
realtek: add xgs1210-12 b1 and switch to rt-loader
rev B1 is identical to rev A1 except for different PHYs on the 2.5gbps ports (lan9 and lan10)
Both revisions of xgs1210-12 are also switched to use rt-loader to avoid
problems due to overwriting the compressed image in memory when flashing
with the oem firmware (and also to save flash space with respect to gzip
compression)
Christoph Krapp [Sun, 19 Oct 2025 11:52:31 +0000 (13:52 +0200)]
ipq40xx: add device alias for Linksys VLP01
Both devices, the Linksys WHW01 and the VLP01, are essentially the same
device. Even Linksys provides only one image for both devices which uses
the WHW01 identifier in the image header.
Paul Donald [Fri, 17 Oct 2025 19:33:13 +0000 (21:33 +0200)]
lldpd: bump to 1.0.20
Also implemented the med fast-start -> lldp fast-start change.
lldpd includes a backwards compat handler for the older med command,
but it's better to make these changes so they align with documentation.
Changes:
Enable fast start unconditionally (and move its configuration in "configure lldp")
Make VLAN advertisements configurable
Fix:
Do not break zero-copy traffic on Linux
Fix crash on rapid addition/removal of interfaces
Fix management address selection when pattern is a negative IP address
LAN5 (rear) is for POE input. LAN4 has POE output (802.3af) when powered
by an 802.3at source.
The LAN4 port is used for tftp booting in U-Boot.
This device does not have secure boot, but cannot be flashed without
external programmers (TSOP48 NAND) as Meraki disabled interrupting U-Boot
for any device that updated after ~2017.
Disassembly:
* Remove the two T10 screws on the rear of the AP.
* Using a guitar pick or similar plastic tool, insert it on the side between
the grey metal plate and the white plastic body and pry up gently.
* The rubberised border on the metal plate does not need to be removed.
* The metal back plate has several latches around the perimeter (but none on
the bottom by the Ethernet ports).
* Once you have removed the metal back plate, push up gently on the bottom
Ethernet ports while pulling gently on the rear-mounted Ethernet port to remove
the PCB.
* The PCB should come free from the plastic housing, pull the bottom
(4 Ethernet ports) up as if you are opening a book.
* If done carefully, there is no need to remove the WiFi antenna connectors
to access the NAND flash.
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
opposite side of the PCB.
* To flash, you need to desolder the TSOP48 or use a 360 clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/mr30h
The device has the following flash layout (offsets with OOB data):
```
0x000000000000-0x000000100000 : "sbl1"
0x000000100000-0x000000200000 : "mibib"
0x000000200000-0x000000300000 : "bootconfig"
0x000000300000-0x000000400000 : "qsee"
0x000000400000-0x000000500000 : "qsee_alt"
0x000000500000-0x000000580000 : "cdt"
0x000000580000-0x000000600000 : "cdt_alt"
0x000000600000-0x000000680000 : "ddrparams"
0x000000700000-0x000000900000 : "u-boot"
0x000000900000-0x000000b00000 : "u-boot-backup"
0x000000b00000-0x000000b80000 : "ART"
0x000000c00000-0x000007c00000 : "ubi"
```
* Dump your original NAND (if using nanddump, include OOB data).
* Decompress `u-boot.bin.gz` dump from the GitHub repository above (dump
contains OOB data) and overwrite the `u-boot` portion of NAND from
`0x738000`-`0x948000` (length `0x210000`). Offsets here include OOB data.
* Resolder the NAND after overwriting the `u-boot` regions.
OpenWrt Installation:
* After flashing NAND with the external programmer. Plug an Ethernet
cable into port 4. Power up the device.
* The new U-Boot build uses the space character `" "` (without quotes) to
interrupt boot.
* Interrupt U-Boot and `tftpboot` the OpenWrt initramfs image from your
tftp server
```
dhcp
setenv serverip <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_mr30h-initramfs-uImage.itb
```
* Once booted into the OpenWrt initramfs, `scp` the `sysupgrade` image to
the device and run the normal `sysupgrade` procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin"
```
* OpenWrt should now be installed on the device.
Alternative installation steps if your device has U-Boot older than:
`U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)`
**BIG FAT WARNING BEGIN**
Attmping to interrupt boot on a newer U-Boot release may permanently
brick your device! See: riptidewave93/LEDE-MR33#13
**BIG FAT WARNING END**
* Use `ubootwrite.py` from the above GitHub repository to transfer the
`u-boot.itb`
image to the router.
```
./ubootwrite.py --serial=/dev/ttyUSB0 --write u-boot.itb
```
* To avoid bricking your router, it is highly recommended at this point that
you flash the unlocked U-Boot to the `part.safe` ubi volume.
```
run set_ubi && ubi write $loadaddr part.safe 0x2fd48
```
* Power cycle the router. The stock Meraki U-Boot will boot `part.safe` which
is now the unlocked U-Boot.
* Use the new U-Boot build (`" "` to interrupt boot) to
`tftpboot` the OpenWrt initramfs image:
```
dhcp
setenv serverip <tftp_server_addr>
tftpboot openwrt-ipq40xx-generic-meraki_mr30h-initramfs-uImage.itb
bootm
```
* It is only recommended to flash U-Boot to the `u-boot` NAND region from
Linux:
```
insmod mtd-rw i_want_a_brick=1
```
* Copy `u-boot.elf` to the router:
```
scp -O u-boot.elf root@192.168.1.1:/tmp/
```
Note: If any of the below commands fails, YOU WILL HAVE A BRICK IF YOU
REBOOT OR LOSE POWER. Only a hardware programmer can recover the device.
```
flash_erase /dev/mtd8 0 0
nandwrite -p /dev/mtd8 /tmp/u-boot.elf
```
Note: ONLY use `u-boot.elf` when flashing the `u-boot` region (`/dev/mtd8`);
`u-boot.bin` or `u-boot.itb` will BRICK YOUR DEVICE
* `scp` the `sysupgrade` image to the device and run the normal `sysupgrade`
procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_mr30h-squashfs-sysupgrade.bin"
```
Hal Martin [Sun, 19 Oct 2025 10:13:54 +0000 (12:13 +0200)]
ipq40xx: add support for Cisco Meraki Go GX20
This commit adds support for the Cisco Meraki Go GX20. The Go GX20 is a wired
router with 5 port Gigabit switch. It shares the same PCB as the Meraki Z3,
but without the WiFi radios.
Port 5 has POE output (802.3af). The Internet/WAN port is used for tftp booting
in U-Boot.
This device ships with secure boot, and cannot be flashed without
external programmers (TSOP48 NAND and I2C EEEPROM)!
Disassembly:
* Remove the four T8 screws on the bottom of the device under the rubber feet.
* Using a guitar pick or similar plastic tool, insert it on the side between
the bottom case and the side, pry up gently. The plastic bottom has several
latches around the perimeter (but none on the rear by the Ethernet ports).
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
bottom side of the PCB (facing you as you remove the bottom plastic).
To flash, you will need to desolder the TSOP48. Attempts to flash in-circuit
using a 360 clip were unsuccessful.
* The SOIC8 I2C EEPROM (U32, Atmel 24C64) is located on the bottom side of
the PCB (facing you as you remove the bottom plastic). It can be flashed in
circuit using a SOIC8 chip clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/z3_gx20
The device has the following flash layout (offsets with OOB data):
```
0x000000000000-0x000000100000 : "sbl1"
0x000000100000-0x000000200000 : "mibib"
0x000000200000-0x000000300000 : "bootconfig"
0x000000300000-0x000000400000 : "qsee"
0x000000400000-0x000000500000 : "qsee_alt"
0x000000500000-0x000000580000 : "cdt"
0x000000580000-0x000000600000 : "cdt_alt"
0x000000600000-0x000000680000 : "ddrparams"
0x000000700000-0x000000900000 : "u-boot"
0x000000900000-0x000000b00000 : "u-boot-backup"
0x000000b00000-0x000000b80000 : "ART"
0x000000c00000-0x000007c00000 : "ubi"
```
* Dump your original NAND (if using nanddump, include OOB data).
* Decompress `u-boot.bin.gz` dump from the GitHub repository above (dump
contains OOB data) and overwrite the `u-boot` portion of NAND from
`0x738000`-`0x948000` (length `0x210000`). Offsets here include OOB data.
* Decompress `ubi.bin.gz` dump from the GitHub repository above (dump
contains OOB data) and overwrite the `ubi` portion of NAND from
`0xc60000`-`0x8400000` (length `0x77a0000`). Offsets here include OOB data.
* Dump your original EEPROM. Change the byte at offset `0x49` to `0x1e`
(originally `0x2b`). Remember to re-write the EEPROM with the modified data.
* This can be done on Linux via the following command:
`printf "\x1e" | dd of=/tmp/eeprom.bin bs=1 seek=$((0x49)) conv=notrunc`
**Note**: the device will not boot if you modify the board major number and
have not yet overwritten the `ubi` and `u-boot` regions of NAND.
* Resolder the NAND after overwriting the `u-boot` and `ubi` regions.
OpenWrt Installation:
* After flashing NAND and EEPROM with external programmers. Plug an Ethernet
cable into the Internet/WAN port. Power up the device.
* The new U-Boot build uses the space character `" "` (without quotes) to
interrupt boot.
* Interrupt U-Boot and `tftpboot` the OpenWrt initramfs image from your
tftp server
```
dhcp
setenv serverip <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_gx20-initramfs-uImage.itb
```
* Once booted into the OpenWrt initramfs, `scp` the `sysupgrade` image to
the device and run the normal `sysupgrade` procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_gx20-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_gx20-squashfs-sysupgrade.bin"
```
Port 5 has POE output (802.3af). The Internet/WAN port is used for tftp booting
in U-Boot.
This device ships with secure boot, and cannot be flashed without
external programmers (TSOP48 NAND and I2C EEEPROM)!
Disassembly:
* Remove the four T8 screws on the bottom of the device under the rubber feet.
* Using a guitar pick or similar plastic tool, insert it on the side between
the bottom case and the side, pry up gently. The plastic bottom has several
latches around the perimeter (but none on the rear by the Ethernet ports).
* The TSOP48 NAND flash (U30, Spansion S34ML01G200TFV00) is located on the
bottom side of the PCB (facing you as you remove the bottom plastic).
To flash, you will need to desolder the TSOP48. Attempts to flash in-circuit
using a 360 clip were unsuccessful.
* The SOIC8 I2C EEPROM (U32, Atmel 24C64) is located on the bottom side of
the PCB (facing you as you remove the bottom plastic). It can be flashed in
circuit using a SOIC8 chip clip.
Installation:
The dumps to flash can be found in this repository:
https://github.com/halmartin/meraki-openwrt-docs/tree/main/z3_gx20
The device has the following flash layout (offsets with OOB data):
```
0x000000000000-0x000000100000 : "sbl1"
0x000000100000-0x000000200000 : "mibib"
0x000000200000-0x000000300000 : "bootconfig"
0x000000300000-0x000000400000 : "qsee"
0x000000400000-0x000000500000 : "qsee_alt"
0x000000500000-0x000000580000 : "cdt"
0x000000580000-0x000000600000 : "cdt_alt"
0x000000600000-0x000000680000 : "ddrparams"
0x000000700000-0x000000900000 : "u-boot"
0x000000900000-0x000000b00000 : "u-boot-backup"
0x000000b00000-0x000000b80000 : "ART"
0x000000c00000-0x000007c00000 : "ubi"
```
* Dump your original NAND (if using nanddump, include OOB data).
* Decompress `u-boot.bin.gz` dump from the GitHub repository above (dump
contains OOB data) and overwrite the `u-boot` portion of NAND from
`0x738000`-`0x948000` (length `0x210000`). Offsets here include OOB data.
* Decompress `ubi.bin.gz` dump from the GitHub repository above (dump
contains OOB data) and overwrite the `ubi` portion of NAND from
`0xc60000`-`0x8400000` (length `0x77a0000`). Offsets here include OOB data.
* Dump your original EEPROM. Change the byte at offset `0x49` to `0x1e`
(originally `0x24`). Remember to re-write the EEPROM with the modified data.
* This can be done on Linux via the following command:
`printf "\x1e" | dd of=/tmp/eeprom.bin bs=1 seek=$((0x49)) conv=notrunc`
**Note**: the device will not boot if you modify the board major number and
have not yet overwritten the `ubi` and `u-boot` regions of NAND.
* Resolder the NAND after overwriting the `u-boot` and `ubi` regions.
OpenWrt Installation:
* After flashing NAND and EEPROM with external programmers. Plug an Ethernet
cable into the Internet/WAN port. Power up the device.
* The new U-Boot build uses the space character `" "` (without quotes) to
interrupt boot.
* Interrupt U-Boot and `tftpboot` the OpenWrt initramfs image from your
tftp server
```
dhcp
setenv serverip <your_tftp>
tftpboot openwrt-ipq40xx-generic-meraki_z3-initramfs-uImage.itb
```
* Once booted into the OpenWrt initramfs, created the `ART` ubivol with
the WiFi radio calibration from the mtd partition:
```
cat /dev/mtd10 > /tmp/ART.bin
ubimkvol /dev/ubi0 -N ART -s 524288
ubiupdatevol /dev/ubi0_1 /tmp/ART.bin
```
* `scp` the `sysupgrade` image to
the device and run the normal `sysupgrade` procedure:
```
scp -O openwrt-ipq40xx-generic-meraki_z3-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
ssh root@192.168.1.1 "sysupgrade -n /tmp/openwrt-ipq40xx-generic-meraki_z3-squashfs-sysupgrade.bin"
```
Christoph Krapp [Fri, 17 Oct 2025 22:23:35 +0000 (00:23 +0200)]
ipq40xx: add label-mac-device alias for Linksys WHW01
Set the label-mac-device to be able to easily fetch the mac-address of
the device, which is printed on the bottom of the case.
While at it, remove the TODO - the ethernet0 alias is needed to get the
mac from bootloader.
Felix Fietkau [Sat, 18 Oct 2025 19:58:45 +0000 (19:58 +0000)]
hostapd: increase netlink buffer size
When lots of events are waiting to be received, the default buffer size
is not enough, and hostapd can run into "No buffer space available" on
recvmsg. This will cause the netdev state tracking to go out of sync.
John Thomson [Sun, 5 Oct 2025 03:45:41 +0000 (13:45 +1000)]
ipq40xx: mikrotik: kernel: pet watchdog during kernel uncompress
kernel 6.9 removed the KConfig entry our RouterBOOT watchdog pet hack was relying on:
Linux df59427a1122 ("ARM: qcom: merge remaining subplatforms into sensible Kconfig entry")
Introduce a new specific KConfig entry for this hack,
and enable it for Mikrotik ipq40xx kernel.
CONFIG_ARCH_QCOM_IPQ40XX_BOOT_COMPRESSED_PET_WATCHDOG_EARLY
With appropriate DEBUG_LL and DEBUG_UNCOMPRESS, this watchdog reset
can be typically seen on console as a reset before "Uncompressing Linux..."
reaches " done, booting the kernel."
RouterBOOT
loading kernel... OK
setting up elf image... OK
jumping to kernel code
Jumping to kernel
DTB:0x80381A60 (0x000048C4)
C:0x800000E0-0x80386420->0x80FAB500-0x81331840
DTB:0x8132CE80 (0x000049B8)
Uncompressing Linux...
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.1-00096
versus:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
On Mikrotik RouterBOOT devices, this is complicated by some RouterBOOT
versions successfully loading the same kernel that other RouterBOOT versions fail. Example:
RouterBOOT backup booter 6.45.9 fine, RouterBOOT booter 7.16 fail
Fixes: openwrt#19841 Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Link: https://github.com/openwrt/openwrt/pull/20305 Signed-off-by: Robert Marko <robimarko@gmail.com>
Kenneth Kasilag [Fri, 17 Oct 2025 02:07:25 +0000 (02:07 +0000)]
kernel: rtl8261n: allow selection as package
Previously, devices would have to select `CONFIG_RTL8261N_PHY=Y` in the
whole target's kernel config. Now that this driver is becoming usable
for devices other than Realtek switches, allow packaging this driver
separately.
Magnus Kroken [Thu, 16 Oct 2025 14:11:11 +0000 (16:11 +0200)]
mbedtls: update to 3.6.5
This release includes fixes for security issues.
Mbed TLS 3.6 is a long-term support (LTS) branch. It will be supported
with bug-fixes and security fixes until at least March 2027.
The two issues fixed were timing side channels:
* Padding oracle through timing of cipher error reporting
(CVE-2025-59438) [1]
* Side channel in RSA key generation and operations (SSBleed, M-Step)
(CVE-2025-54764) [2]
Bug fixes:
* Fix potential CMake parallel build failure when building both the static and shared libraries.
* Fix a build error or incorrect TLS session lifetime on platforms where mbedtls_time_t is not time_t.
Hauke Mehrtens [Mon, 13 Oct 2025 22:32:26 +0000 (00:32 +0200)]
ltq-ptm: Fix unprivileged local user memory read and write
Use the copy_from_user() and copy_to_user() functions for accessing
memory provided by the user in the ptm netdev iotls.
In addition also check for root permission before executing ioctl.
Suggested-by: Stanislav Fort from Aisle Research Reported-by: Stanislav Fort from Aisle Research Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Felix Fietkau [Fri, 17 Oct 2025 11:28:52 +0000 (13:28 +0200)]
ubus: update to Git HEAD (2025-10-17)
b462895d3157 lua: CMakeLists: drop redundant cmake_minimum_required f247c18f8a55 examples: CMakeLists: drop redundant cmake_minimum_required 83a70399030d github: add CI build d31effb4277b ubusd: Fix out of bounds access in event register message d95837b1b143 ubusd: acl: compare uid/gid instead of user/group strings b81257bb20dd ubusd: load extra group IDs for a client process 7d7b45fea05b add debian/ directory aa4a7ee1d341 ubusd: fix more instances of missing length checks for patterns 60e04048a0e2 ubusd: fix ACL check for receiving events
Eric Fahlgren [Wed, 8 Oct 2025 16:42:21 +0000 (09:42 -0700)]
targetwide: imagebuilder: add explicit guards around initramfs rules
The imagebuilder is not intended to build initramfs images. Some
profiles attempt to do this and succeed, due to buildroot leaking
the initramfs-kernel into staging_dir; others attempt it, but fail
due to not having initramfs binaries present in the imagebuilder.
Fix this by adding an explict guard around the unsupported generation
of the initramfs images. This saves space and time during imagebuilder
runs, fixes those that are currently broken and protects against future
breakage for profiles that inadvertently work now.
Fixes: https://github.com/openwrt/openwrt/issues/20151 Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20347 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Thu, 16 Oct 2025 09:06:08 +0000 (11:06 +0200)]
realtek: dsa: rtl931x: Fix port L2 table flushing
The DSA driver must flush the HW FDB when a port changes from
learning/forwarding to disabled/blocking/listening.
But the implementation for RTL931x was writing the port information
starting at bit 11 (bit 11 of the second 32-bit L2_TBL_FLUSH_CTRL
register). But this offset is the AGG_VID and not the port. The actual
position is 43 (bit 11 of the first register).
As result, the FDB was always only flushed for the port 0 and not for the
selected port.
Fixes: 9ed609705481 ("realtek: Add HW support for RTL931X for PIE, L2 and STP aging") Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20422 Signed-off-by: Robert Marko <robimarko@gmail.com>
Andrew Sim [Mon, 6 Oct 2025 04:58:44 +0000 (06:58 +0200)]
mediatek: filogic: rename eth1 to wan in led setup for zyxel-ex5601-t0
the eth1 interface was renamed to wan so also reflect that change in
the leds setup script
Fixes: f26260c7e751 ("mediatek: filogic: Add label wan and cpu for Zyxel EX5601-T0") Signed-off-by: Andrew Sim <andrewsimz@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20120 Signed-off-by: Nick Hainke <vincent@systemli.org>
Harshal Gohel [Fri, 8 Aug 2025 15:31:03 +0000 (17:31 +0200)]
realtek: rtl93xx: Trap BPDU management frames
BPDU frames like STP must be processed by each switch (bridge) which
supports STP. It must not be forwarded to avoid confusing the STP state of
other STP participants. It is essential to be an active participant of STP.
The software bridge automatically takes care of forwarding the BPDUs to
other ports when STP is disabled and the hardware switch should not
interfere.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20414 Signed-off-by: Robert Marko <robimarko@gmail.com>
ksmbd.mount will give each interfaces list and bind_interfaces_only flags
to ksmbd server. Previously, the interfaces list was sent only
when bind_interfaces_only was enabled.
ksmbd server browse only interfaces list given from ksmbd.conf on
FSCTL_QUERY_INTERFACE_INFO IOCTL.
I've experienced the LAN port failing to initialize from a cold boot and
after a reboot. Other users have reported this issue on
https://forum.openwrt.org/t/nanopi-r4s-rk3399-is-a-great-new-openwrt-device/79143.
The NanoPI R4S has its LAN port connected to the RK3399 via PCIE. Since the
PCIE lanes don't initialize correctly after reboot, the LAN port
doesn't initialize.
Christoph Krapp [Thu, 25 Sep 2025 07:30:27 +0000 (09:30 +0200)]
ath79: add calibtation variant for TP-Link Archer C59 v1
Now that we have a board file, add calibration variant for TP-Link
Archer C59 v1 and add ipq-wifi package for it.
Tested-by: Mateusz Jończyk <matjon@users.noreply.github.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20401 Signed-off-by: Robert Marko <robimarko@gmail.com>
apk-tools: fix compilation warning from downstream full print patch
Fix trivial compilation warning caused by downstream full print patch.
../src/app_list.c: In function 'print_full':
../src/app_list.c:85:35: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
85 | printf("Installed-Size: %zu\n", pkg->installed_size);
| ~~^ ~~~~~~~~~~~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:86:25: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
86 | printf("Size: %zu\n", pkg->size);
| ~~^ ~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:58:31: warning: unused variable 'd' [-Wunused-variable]
58 | struct apk_dependency d;
Remove unused variable and use PRIu64 to handle uint64_t type.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
tools/meson: add pending patch to improve binary reproducibility
Add 3 pending patch that improve binary reproducibility. The first
address a problem with RPATH string not getting cleared on removal of
RPATH entry from ELF section. The other 2 skip including external shared
library in RPATH in meson build phase.
This follows the logic that on cross-compiling we can't run the binary
anyway as it does target a different arch hence it doesn't make sense to
include those extra path in RPATH causing reproducibility problems (as
path for those external library will depend on the build system path)
George Moussalem [Tue, 14 Oct 2025 09:36:17 +0000 (13:36 +0400)]
qualcommax: ipq50xx: fix XO board clock rate for Yuncore AX850
Commit 468975a985ab changed the XO board clock definition from a fixed
clock to a fixed rate clock in the dtsi.
As such, boards must use clock dividers and multipliers to calculate
the clock rate based on the referenced parent clock.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://github.com/openwrt/openwrt/pull/20405 Signed-off-by: Robert Marko <robimarko@gmail.com>
Add pending patch to address PCI sysfs creation entry race observed on
ipq806x. This is to handle a kernel warning on creating the same sysfs
entry multiple times.
Shiji Yang [Wed, 18 Jun 2025 11:50:39 +0000 (19:50 +0800)]
ipq806x: migrate wifi configuration device paths for 6.12 kernel
The device tree PCIe host node names have been changed in the new
6.12 kernel[1]. Hence we have to update the wifi device path to
make sure it can work properly.
This script is based on:
target/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/ieee80211/05-wifi-migrate
These devices' reg cell[0] is equal to 0x10000, hence the correct
node unitname should be "0,0". This patch fixes the following dtc
warnings on 6.12 kernel:
qcom-ipq8065-tr4400-v2.dts:482.11-487.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-tr4400-v2.dts:499.11-504.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:584.11-589.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:601.11-606.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:291.11-295.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:303.11-307.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:525.11-530.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:539.11-544.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:235.11-239.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:251.11-255.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:261.11-264.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:275.11-278.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:362.11-367.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:78.18-81.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:89.18-92.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:100.18-103.4: Warning (pci_device_reg): /soc/pcie@1b900000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:464.11-469.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:478.11-483.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:404.11-410.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:419.11-426.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:210.11-215.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:227.11-232.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:213.11-218.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:230.11-235.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:546.18-549.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:559.18-562.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:202.11-206.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:218.11-222.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:319.11-324.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:333.11-338.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:361.11-366.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
Shiji Yang [Sun, 1 Jun 2025 04:56:09 +0000 (12:56 +0800)]
ipq806x: dts: rework PCIe nodes for Chromium OnHub
- Reuse the bridges node defined on "qcom-ipq8064.dtsi".
- Rename PCIe device nodes to unified "wifi@0,0".
- Add the missing "qcom,ath10k" compatibles.
- Remove unseless property "interrupt-controller". There are no
consumers use these PCIe devices as interrupt controllers.
- Change bus number from 0 to 1, just like other ipq806x devices.
The valid PCIe bus range on this platform is 1 - 255.
Shiji Yang [Sat, 31 May 2025 16:41:31 +0000 (00:41 +0800)]
ipq806x: fix build errors on 6.12 kernel
- Replace "strlcpy()" with "strscpy()".
- Convert platform driver .remove() to .remove_new().
This patch fixes the following compile errors:
drivers/of/fdt.c:1064:17: error: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit-function-declaration]
1064 | strlcpy(cmdline, p, min((int)l, COMMAND_LINE_SIZE));
| ^~~~~~~
| strncpy
drivers/devfreq/krait-cache-devfreq.c:171:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
171 | .remove = krait_cache_remove,
| ^~~~~~~~~~~~~~~~~~
drivers/devfreq/ipq806x-fab-devfreq.c:145:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
145 | .remove = ipq806x_fab_remove,
| ^~~~~~~~~~~~~~~~~~
Shiji Yang [Sat, 31 May 2025 15:09:58 +0000 (23:09 +0800)]
ipq806x: refresh kernel symbol configs
This is a preparation for introducing the 6.12 kernel support.
All configs are automatically refreshed. In theory, they will
generate the same .config files in the kernel build directory
as before.
sdk: set package as the root directory for base feed
To produce consistent source entry for package compiled from non-SDK and
SDK build, set the "--root=package" flag for the base feed.
This will set the root directory for the base feed to the OpenWrt
core repository "package" directory.
This fix the reproducible problem of package build from SDK that have
the source entry set to "feeds/base/package/..." for every package
coming from the base feed.
scripts/feeds: implement support for --root option
Some feeds might need to set the source for their packages in a
different directory than the cloned one.
For example a feed "test" might be an entire repository and the relevant
packages that wants to be included are in the directory "foo".
In such scenario the source info in the package will result in something
like "feeds/test/foo/network/dnsmasq" instead of an expected entry like
"feeds/test/network/dnsmasq".
To give a more real-world example, this problem is currently present
with OpenWrt SDK where the SDK clone the entire OpenWrt core repository
as "base" feeds but the package are present in the "package" directory.
This cause every package to have the source entry set to
"feeds/base/package/..." conflicting with what a non-SDK build do with
setting the source entry to "feeds/base/..."
To solve this, actually enable support for "flags" in the feeds script
and implement a new option "--root" to set the root directory for the
defined feed to an inner directory.
The "flags" in the feed script are no more than argument option that can
be defined right after the "src-" type in the feed.conf file.
This feature was partially implemented but never actually used for
anything keeping it dormant with all the core piece there (the pattern
regex always accounted for these extra option but they were never passed
to the relevant functions)
An example of the "--root" flag is the following:
src-git --root=package base https://git.openwrt.org/openwrt/openwrt.git;main
With "--root" defined, the script will append "_root" to the feed name
clone directory and will create a symbolic link named with the feed name
and pointing to the feed name clone directory + the value in root.
From the previous example:
feed name: base -> clone directory: base_root
symbolic link: base -> base_root/package
The script internally reference the "_root" directory for every update
operation and OpenWrt build system transparently use the feed name
directory to reference feed packages producing consistent source info
entry.
Zhi-Jun You [Wed, 8 Oct 2025 06:55:06 +0000 (14:55 +0800)]
wifi-scripts: ucode: fix airtime_mode with hostapd-mini
Currently wifi-scripts ucode appends airtime_mode to hostapd config file
unconditionally.
However this breaks bringing up interface with hostapd-mini
because the mini variant doesn't support airtime policy.
Fix this by changing the script to append airtime_mode only when
airtime_mode is set to greater than zero value in /etc/config/wireless.
Fixes: #20136 Fixes: #20314 Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Lorenz Brun [Fri, 10 Oct 2025 21:11:38 +0000 (23:11 +0200)]
realtek: fix SFP ports on RTL83xx
Right now the phylink capability function enables 2.5G and 10G modes on
Maple and Cypress, which they mostly (other than two SERDES on Cypress)
don't support. This causes these modes to be selected and break the link
as they are not supported by hardware.
I looked into doing this properly, but it cannot just be done based on
SoC, but needs to take the whole topology into account as a given MAC
might have very different capabilities depending on what SERDES are
assigned to it. So for now just use 1G and QSGMII for RTL83xx and 10G
for RTL93xx. This mostly works, except it will downgrade some 10G links
on RTL839x, but since there are also 1G SFPs on these this cannot be
solved without fully accounting for the global MAC and SERDES
configuration.
So this makes all of the 1G SFP slots work again, while keeping most of
the 10G SFP+ slots working at 10G with minimal changes.
Sven Eckelmann [Mon, 29 Sep 2025 16:30:12 +0000 (18:30 +0200)]
realtek: Skip auto-MAC assignment for devices with MACs in DT
If the devicetree contains the appropriate nodes to configure the MAC
addresses for each physical DSA port, then these MAC addresses must be used
in OpenWrt and not some automatically generated ones. Otherwise the device
often ends up with addresses which are locally administered and not
matching any expected port-to-MAC scheme.
Devices which only get the MAC address for eth0 must still auto-generate
these MAC addresses until the devicetree was updated to also include the
correct ones.
Sven Eckelmann [Sun, 5 Oct 2025 07:00:08 +0000 (09:00 +0200)]
realtek: Avoid empty lan mac in initial network setup
If the lan_mac cannot be found, it is still used (as empty string) in
various operations. This is not valid and other 02_network scripts checking
for a non-empty string before using it. This should also be adopted for the
realtek 02_network.
Sven Eckelmann [Sun, 5 Oct 2025 06:55:49 +0000 (08:55 +0200)]
realtek: Split initial network setup in functions
Having everything in a big script without any structure makes it
unnecessary hard to get an overview or modify it without triggering
unexpected side effects.
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Adjust prefix for bridge member functions
The preferred prefix for the Realtek DSA driver code is "rtldsa" and no
longer "rtl83xx". This makes sure that the different drivers have
non-conflicting prefixes and because of this non-conflicting function
names.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Fix name of RTL93xx switch_ops
The RTL930x and the RTL931x SoC families share the same struct
dsa_switch_ops. This should be represented in the name of the object.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Thu, 9 Oct 2025 12:59:16 +0000 (14:59 +0200)]
realtek: dsa: Add support for port isolation
If two ports are in isolation mode then these ports are not supposed to be
able to communicate between each other. This can be achieved in the realtek
switch by removing the other isolated port(s) from the port list of an
isolated port.
Sven Eckelmann [Thu, 9 Oct 2025 13:01:06 +0000 (15:01 +0200)]
realtek: dsa: Drop unused traffic_get helpers
The realtek driver is now in full control of the port matrix. It doesn't
need to rely on the current state of the HW to adjust it. The new port
matrix is calculated automatically using rtldsa_update_port_member() and
then written to the registers/tables.
Sven Eckelmann [Thu, 9 Oct 2025 14:28:47 +0000 (16:28 +0200)]
realtek: dsa: Simplify port member handling
It is not necessary to read the back the current port members for a
specific port for enabling/disabling a port. All these members which are
expected to be in the HW port matrix of an active port are already stored
in the port specific member "pm".
And when a port is disabled, the port must no longer forwarding traffic to
any other port. Just writing 0 to the members is therefore good enough and
no read-back of the old HW state is necessary.
Sven Eckelmann [Thu, 9 Oct 2025 12:56:39 +0000 (14:56 +0200)]
realtek: dsa: Share port member configuration code
The leave and join callbacks for DSA were using their own implementation of
the port member handling code. This makes the implementation of additional
functionality based on the port member matrix complicated because it needs
to be implemented in both places and also in the new code path for the
introduced feature.
By sharing this code, it is much easier to guarantee that all code paths
behave the same. This approach is already implemented by other DSA drivers
like qca8k, mt7530 or ksz.
Sven Eckelmann [Thu, 9 Oct 2025 11:56:19 +0000 (13:56 +0200)]
realtek: Switch booleans in rtl838x_port to single bits
In upstream kernel, it is not well received to use a lot of simple booleans
in structs. It is preferred to use 1-bit bitfields [1] and consolidate the
booleans together.
Robert Marko [Sun, 12 Oct 2025 09:59:34 +0000 (11:59 +0200)]
ipq-wifi: add Yuncore AX850
It seems that adding Yuncore AX850 was missed during the board support,
and this breaks buildbots for ipq50xx with:
ERROR: unable to select packages:
ipq-wifi-yuncore_ax850 (no such package):
required by: world[ipq-wifi-yuncore_ax850]
make[4]: *** [/builder/shared-workdir/build/include/image.mk:396: target-dir-90b51871] Error 1
make[4]: *** Waiting for unfinished jobs....
So, add the required meta package.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: Robert Marko <robimarko@gmail.com>
projects / thirdparty / openwrt.git / log
