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> (commit: 2930c9d)
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> (commit: 84b7057)
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> (commit: f6e0f57)
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
Signed-off-by: Felix Fietkau <nbd@nbd.name> (commit: 4b907e6)
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> (commit: 2a76abc)
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.
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.
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> (commit: 9d531c0)
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.
Signed-off-by: Felix Fietkau <nbd@nbd.name> (commit: 0535d61)
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.
Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20441 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: deca8fd)
This adds led aliases for failsafe and upgrade. Before this change the leds stayed dark in both situations.
Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20441 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 1afe4ba)
whw01 was incorrectly placed below whw03 definitions.
Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20441 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 1fecbaf)
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" ```
* OpenWrt should now be installed on the device.
Signed-off-by: Hal Martin <hal.martin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/17026 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 60bbf46)
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" ```
* OpenWrt should now be installed on the device.
Signed-off-by: Hal Martin <hal.martin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/17026 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 11f7aa1)
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" ```
* OpenWrt should now be installed on the device.
Signed-off-by: Hal Martin <hal.martin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/17026 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 0304595)
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
Signed-off-by: Paul Donald <newtwen+github@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20438 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 217e332)
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.
Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20455 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: b442ca0)
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)
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
Signed-off-by: David Härdeman <david@hardeman.nu> Link: https://github.com/openwrt/openwrt/pull/20359 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: a660a07)
This makes the DHCPv4 client use the global DHCP DUID to generate a RFC4361-style client identifier.
Signed-off-by: David Härdeman <david@hardeman.nu> Link: https://github.com/openwrt/openwrt/pull/20359 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 9151c70)
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.
Signed-off-by: David Härdeman <david@hardeman.nu> Link: https://github.com/openwrt/openwrt/pull/20359 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 7dee632)
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
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.
ramips: add support for Zyxel NWA90AX access point
The NWA90AX is hardware-wise identical to the NWA50AX which is already supported.
The NWA90AX magic model code bytes are `77 E1`, and they are added to the DTS to mark the NWA50AX firmware as being compatible with the 90 model.
Without the compat-models change, uploading the OpenWrt NWA50AX firmware with the official Zyxel web interface yields an error: > errno: -25007 > errmsg: Firmware content error!
As described on the NWA50AX firmware page[1] on the wiki, the "current image" slot for firmware updates has to be "1". If it is 0, flashing will fail.
Vendor support page stating that the hardware is identical: https://support.zyxel.eu/hc/en-us/articles/4416989548178-Access-Point-NWA50-55AXEE-90AX-110AX-210AX-Differences-in-Hardware-and-Features > NWA90AX: Identical hardware as in NWA50AX, but with added features > like Captive portal for Guest access and WPA Enterprise for > AD/Radius (Credential) authentication.
airoha: drop unsupported fit image option with-initrd
This option will only take effect when the "separate_ramdisk" feature was enabled. However, this target does not support this feature. It is an obvious copy and paste issue.
ramips: drop unsupported fit image option with-initrd
This option will only take effect when the "separate_ramdisk" feature was enabled. However, this target does not support this feature. It is an obvious copy and paste issue.
realtek: pcs: rtl931x: import SerDes setup code from PHY driver
Let's start this transition with RTL931X.
Import all functions starting with 'rtl931x_' or 'rtsds_931x' from PHY driver into the PCS driver, rename all functions to match a common naming scheme and adjust signature, helper calls and function calls accordingly to make it work within the PCS driver.
This is just copy&paste and tries to do only mandatory adjustments. The code will be refactored in succeeding commits.
Also remove 'unused' attribute from helpers as they are used now.
realtek: pcs: rtl931x: use regmap for register access calls
Replaces the "old" way of accessing registers using the macros sw_r32/sw_w32 from mach-rtl83xx.h. The "new" way to access register is through the regmap API.
Adjust the SerDes page numbers to account for the different mapping used by 'mdio-realtek-otto' and 'mdio-realtek-otto-serdes' drivers.
While importing the SerDes configuration code from PHY driver to PCS driver, all helper calls to access the SerDes registers had to be adjusted to use the proper helpers within the PCS driver. However, there is one important implication of this: 'mdio-realtek-otto' and 'mdio-realtek-otto-serdes' use a slightly different page mapping.
While the old helpers in 'mdio-realtek-otto' used a page mapping of 0x00/0x100/0x200, 'mdio-realtek-otto-serdes' uses a mapping of 0x00/0x40/0x80 to provide consumers with the ability to only operate on frontend SerDes. Thus, all page numbers > 63/0x3f have to be adjusted like the following:
realtek: pcs: rtl931x: quit setup_serdes early on USXGMII mode
In rtpcs_931x_setup_serdes, quit early on USXGMII mode. This restores the behaviour introduced in c18476d0c5 to prevent the current buggy procedure to destroy a working configuration established by U-Boot before.
Also include the valuable comment from the code to keep the information.
realtek: dsa,pcs: rtl931x: let PCS driver setup SerDes
Remove SerDes initialization/configuration calls from the DSA driver in 'rtl931x_phylink_mac_config' and let our PCS driver setup the SerDes now that the driver is able to do that.
pcs_config of the PCS driver is automatically called by phylink, thus there's no need to call it on our own.
Note that in rtl931x_phylink_mac_config the MAC is enabled before pcs_config is called. While this seems to work, it isn't good and needs to be fixed.
realtek: dsa: rtl931x: remove enabling MAC from phylink_mac_config
Originally, phylink_mac_config first disabled the MAC, then triggered the SerDes setup and then re-enabled MAC. SerDes setup has been moved to the PCS driver now but pcs_config is called AFTER phylink_mac_config by phylink subsystem.
Thus, just disable the MAC in phylink_mac_config. After PCS has setup the SerDes, the MAC should be properly brought up in a mac_link_up call coming from the phylink subsystem.
ramips: mt7621: add support for D-Link DIR-X1860 B1 / DIR-X1550 A1
Both devices seem to be completely identical and D-Link doesnt even mention the DIR-X1550 A1 in the GPL source. Furthermore the supported devices header also just contains DIR-X1860 B1. The cherry on top is the FCC filing, which features the manual for DIR-X1550 A1 but the label info for DIR-X1860 B1. I guess someone at D-Link was just as confused as me.
MAC addresses ------------- LAN Label MAC (stored in config2 partition as ASCII (entry factory_mac=xx:xx:xx:xx:xx:xx)) WAN LAN + 3 2.4G LAN + 1 5G LAN + 2
Installation ------------ Vendor UI --------- 1. Browse to http://192.168.0.1 and login. 2. Navigate to "Management" -> "Upgrade". 3. Press the "Select File" button and upload openwrt-ramips-mt7621-dlink_dir-x1860-b1-squashfs-factory.bin 4. Confirm the security questions, wait for a reboot and enjoy OpenWrt.
Recovery UI ----------- 1. Set your IP address to 192.168.0.101, subnet 255.255.255.0. 2. Power on the device while holding reset. 3. Release reset once the status led starts to blink orange. 4. Open a chrome- or firefox based browser and browse to https://192.168.0.1 5. Upload openwrt-ramips-mt7621-dlink_dir-x1860-b1-squashfs-recovery.bin wait for a reboot and enjoy OpenWrt.
Back to stock ------------- 1. Set your IP address to 192.168.0.101, subnet 255.255.255.0. 2. Power on the device while holding reset. 3. Release reset once the status led starts to blink orange. 4. Open a chrome- or firefox based browser and browse to https://192.168.0.1 5. Upload a decrypted vendor image, wait for a reboot and regret your decision.
Decrypt vendor image -------------------- 1. Download dlink-sge-image.c and dlink-sge-image.h from the firmware-utils openwrt repository. 2. Compile a binary from the downloaded file e.g. gcc dlink-sge-image.c -lcrypto -o dlink-sge-image 3. Run ./dlink-sge-image DIR-X1860-B1 <vendor_image> <decrypted_image> -d
mac80211: ath11k: backport of the latest changes applied for ath11k in 6.16.12
This includes the following commits from upstream Linux between 6.16 and 6.16.12:
wifi: ath11k: clear initialized flag for deinit-ed srng lists wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() wifi: ath11k: fix dest ring-buffer corruption wifi: ath11k: fix source ring-buffer corruption wifi: ath11k: fix dest ring-buffer corruption when ring is full wifi: ath11k: fix group data packet drops during rekey [1] wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()
[1] The patch "940-ath11k-Revert-clear-the-keys-properly-when-DISABLE_K.patch" has been removed, as it has been fixed upstream in "wifi: ath11k: fix group data packet drops during rekey" and is added in 945 patch. Related: https://github.com/openwrt/openwrt/pull/18705 Related: https://github.com/openwrt/openwrt/issues/9555 Related: https://github.com/openwrt/openwrt/issues/14117
This is a useless property on ath79 target. Both spi-ar934x and spi-ath79 drivers don't check num-cs property. They always set chip select number to 3.
The SPI chip select GPIO polarity is active low by default. We must use "spi-cs-high" dts property to toggle the polarity. The polarity on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml ``` device node | cs-gpio | CS pin state active | Note ================+===============+=====================+===== spi-cs-high | - | H | - | - | L | spi-cs-high | ACTIVE_HIGH | H | - | ACTIVE_HIGH | L | 1 spi-cs-high | ACTIVE_LOW | H | 2 - | ACTIVE_LOW | L |
Notes: 1) Should print a warning about polarity inversion. Here it would be wise to avoid and define the gpio as ACTIVE_LOW. 2) Should print a warning about polarity inversion because ACTIVE_LOW is overridden by spi-cs-high. Should be generally avoided and be replaced by spi-cs-high + ACTIVE_HIGH. ```
The SPI chip select GPIO polarity is active low by default. We must use "spi-cs-high" dts property to toggle the polarity. The polarity on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml ``` device node | cs-gpio | CS pin state active | Note ================+===============+=====================+===== spi-cs-high | - | H | - | - | L | spi-cs-high | ACTIVE_HIGH | H | - | ACTIVE_HIGH | L | 1 spi-cs-high | ACTIVE_LOW | H | 2 - | ACTIVE_LOW | L |
Notes: 1) Should print a warning about polarity inversion. Here it would be wise to avoid and define the gpio as ACTIVE_LOW. 2) Should print a warning about polarity inversion because ACTIVE_LOW is overridden by spi-cs-high. Should be generally avoided and be replaced by spi-cs-high + ACTIVE_HIGH. ```
These devices only have one SPI peripheral. And the chip select pin is directly controlled by the SPI host hardware. Hence we don't need to assign empty GPIO phandle for them. This patch also adjust the reg address of the SPI peripheral node to follow the cs-gpios changes.
The SPI chip select GPIO polarity is active low by default. We must use "spi-cs-high" dts property to toggle the polarity. The polarity on "cs-gpios" won't take effect at all[1]. Fix these incorrect GPIO polarities to silence the kernel warnings.
[1] Refer to Linux/Documentation/devicetree/bindings/spi/spi-controller.yaml ``` device node | cs-gpio | CS pin state active | Note ================+===============+=====================+===== spi-cs-high | - | H | - | - | L | spi-cs-high | ACTIVE_HIGH | H | - | ACTIVE_HIGH | L | 1 spi-cs-high | ACTIVE_LOW | H | 2 - | ACTIVE_LOW | L |
Notes: 1) Should print a warning about polarity inversion. Here it would be wise to avoid and define the gpio as ACTIVE_LOW. 2) Should print a warning about polarity inversion because ACTIVE_LOW is overridden by spi-cs-high. Should be generally avoided and be replaced by spi-cs-high + ACTIVE_HIGH. ```
wifi-scripts: ucode: export HE and EHT operation in scan results
Export WiFi 6E (HE) and WiFi 7 (EHT) operation data in scan results. These additional data can be useful to check wifi channel utilization by nearby stations.
Example: Cell 32 - Address: xx:xx:xx:xx:xx:xx Mode: Master Frequency: 6.115 GHz Band: 6 GHz Channel: 33 Signal: -14 dBm Quality: 70/70 Encryption: SAE (CCMP) HE Operation: Center Frequency 1: 39 Center Frequency 2: 47 Channel Width: 160 MHz EHT Operation: Center Frequency 1: 47 Center Frequency 2: 63 Channel Width: 320 MHz
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://github.com/openwrt/openwrt/pull/19208 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: 1035615)
3. Download the sysupgrade firmware at openwrt.bin. 4. The firmware size should be 7995392 bytes. Fix the size of your firmware putting zeros to the end, with:
