CreatLentem CLT-R30B1 is a wireless WiFi 6 router.
This device uses the CLT-R30B1_0824_V1.1 board
shared by EDUP RT2980, Dragonglass DXG21,
and other diamond-shaped 5-antenna routers.
Important notes
---------------
The device is supplied in two variants.
The main difference is the size of the mtd5 (ubi)
partition in the flash layout: 64M or 112M.
112M version: Has ImmortalWrt firmware installed with LuCI WebUI.
64M version: Has stock firmware based on OpenWrt,
with the WaveLink/GL.iNet WebUI and older U-Boot
compared to the 112M version.
Flash instructions for 112M version
-----------------------------------
Follow the standard OpenWrt sysupgrade procedure without saving data.
Use the clt-r30b1-112m-squashfs-sysupgrade.bin image.
All checks should pass - don't proceed if a "not supported"
warning is issued.
Flash instructions for 64M version
----------------------------------
WebUI Method:
1. Prepare the upgrade image with clt-r30b1-squashfs-sysupgrade.bin
using the script: make_staged_upgrade_tar.sh
or use the prepared image: staged_openwrt_upgrade.bin
Downloaded from:
https://github.com/andros-ua/owrt-misc/tree/main/clt-r30b1
2. Install the prepared image using the stock WebUI update page.
3. Press and hold the reset button after reboot
to wipe the stock config and gain access.
SSH Method:
1. Connect via SSH using dg:ivanlee credentials.
2. Upload the clt-r30b1-squashfs-sysupgrade.bin image.
3. Use the command: sysupgrade -n
All checks should pass - don't proceed if a "not supported"
warning is issued.
Return to stock
---------------
Flash a backup of the ubi mtdblock (mtd5)
using the OpenWrt sysupgrade method.
Recovery
--------
Both variants:
Connect UART and use the U-Boot menu to flash the firmware image
or boot an OpenWrt initramfs image.
112M with newer U-Boot:
Power on the router while pressing the mesh button for 3 seconds.
The U-Boot Flash WebUI will be available at http://192.168.1.1
Thomas Richard [Fri, 27 Jun 2025 08:28:08 +0000 (10:28 +0200)]
kernel: usb: kmod-usb-dwc3: add gadget and dual-role modes support
Build DWC3 driver in the right mode:
- host mode if kernel have usb host support only.
- gadget mode if kernel have usbgadget support only.
- dual-role mode if kernel have both usb host and usbgadget support.
Thomas Richard [Fri, 27 Jun 2025 13:59:22 +0000 (15:59 +0200)]
kernel: usb: fix dependencies for kmod-usb-roles package
The usb role driver does not depend on the kernel config CONFIG_USB (host
side support). It only depends on the kernel config CONFIG_USB_SUPPORT.
Now it depends on the OpenWrt configurations USB_SUPPORT or
USB_GADGET_SUPPORT (usb and usbgadget features). We can assume that if usb
or usbgadget features are set, CONFIG_USB_SUPPORT has been set in the
target/subtarget kernel config.
Thomas Richard [Tue, 5 Aug 2025 07:32:48 +0000 (09:32 +0200)]
kernel: usb: add kmod-usb-common package
Move usb-common driver from usb-core package to a new usb-common package.
The usb-common driver is needed by usb-gadget driver which can be used
without host support.
The current variables tagged_ports and untagged_ports suggest that
these are distinct and describe only the ports in each of these
configuration types.
That is wrong. The hardware is configured via member ports and
untagged ports. The first one being a superset of the second.
Rename the variables to reflect that.
realtek: rtl93xx: Add learning and flooding enable/disable
Both RTL930x and RTL931x were missing the code to support enabling and
disabling MAC address learning and unknown unicast flooding on a per-port
basis.
* rtl93*x_enable_learning() allows toggling of dynamic MAC learning on
individual ports by modifying the L2 learning constraint control
register.
* rtl93*x_enable_flood() provides the ability to control unknown unicast
flooding behavior, disabling forwarding when set. If it is enabled, it
will just forward it. If it is disabled, packets will simply be dropped.
Installation via Webinterface
-----------------------------
1. Rename OpenWrt sysupgrade bin to wavlink_wl-wn551X3-squashfs-sysupgrade.bin
The uppercase chars 551X3 are essential and checked by web interface.
2. Logon to webinterface
3. Go to network configuration -> mode selection
4. Choose mode "LAN bridge/access point"
5. Save configuration (maybe network reconfig needed)
6. Go to system upgrade
7. Choose local upgrade and provide renamed sysupgrade file
8. Start upgrade and wait for completion
9. Logon to OpenWrt (network config is preserved during upgrade)
Boot initramfs via TFTP & console
---------------------------------
1. Connect switch to network via LAN1 or LAN2
2. Power on switch
3. Press ESC until prompt reached "MT7981>"
4. Set own IP "setenv ipaddr 192.168.x.y"
5. Set TFTP IP "setenv serverip 192.168.a.b"
6. Set memory address "setenv loadaddr 0x46000000"
7. Download image "tftpboot openwrt-mediatek-filogic-wavlink_wl-wn551x3-initramfs.itb"
8. Boot image "bootm"
Notes
-----
- The red/blue LEDs give a background illumination to the top of the
case. The red LED is totally disabled to avoid noisy blinking.
- Aside from the design and the different LED colors & placements
the hardware and partitioning matches the WAVLINK WL-WN586X3 Rev B.
Therefor a common DTSI was prepared.
MAC Addresses (same as stock)
-----------------------------
LAN : 80:3F:5D:xx:xx:B1 (hw, 0x44e(text))
WAN : 80:3F:5D:xx:xx:B2 (hw, 0x460(text))
2.4GHz: 80:3F:5D:xx:xx:B1 (Factory, 0x4 (hex))
5GHz : driver auto generated
Jan Taczanowski [Thu, 24 Jul 2025 21:19:34 +0000 (23:19 +0200)]
mpc85xx: HPE MSM460 add HPE MSM430 alias
Define MSM430 as alternative name, to explicitly show the device is
supported using existing image (MSM460).
I can confirm that the guide from
https://github.com/blocktrron/msm460-flashing works perfectly fine with
the HP MSM430 as well.
In fact, the MSM430 running the original firmware operates as
a 2x3:2 access point, but after flashing it with OpenWRT, it functions
as a 3x3:3 access point — just like the MSM460 model.
It seems that the MSM430 is essentially the same hardware as the MSM460,
with limitations imposed by the original (HP) software.
This commit adds support for a dual-band AC1200 wall plug
manufactured by Shenzhen Century Xinyang Tech Co., Ltd.
SoC: Mediatek MT7628AN (MIPS 24KEc single core, 580 MHz)
RAM: 128 MiB DDR2 (Hynix HY5PS1G1631C)
ROM: 8 MiB SPI NOR (Zbit ZB25VQ64ASIG)
Wired: one FE RJ45 port (+ an unpopulated footprint for a 2nd)
WiFi: Mediatek MT7612E
Ant.: four 2 dBi external antennas (two 2.4GHz, two 5 GHz)
LEDs: - Power (green, always on)
- 2.4G (green, controlled by MT7628)
- 5G (green, controlled by MT7612)
- Extender (green, GPIO 37, used as status LED)
- LAN (green/yellow, controlled by RT3050 ESW)
Buttons: WPS and reset (both connected to GPIO 38)
Power: 5V 2-pin JST-XH on main PCB
110/220V AC to 5V 1.5A DC on auxiliary PCB
UART: 57600 8n1 3.3v, holes available on the PCB as J5
pinout is (Gnd) (Tx) (Rx)
MAC: 1C:BF:CE:xx:xx:xx (2.4 GHz, label)
1C:BF:CE:xx:xx:xx + 1 (LAN)
1C:BF:CE:xx:xx:xx + 2 (WAN, not in use)
1C:BF:CE:xx:xx:xx + 3 (5 GHz)
Original firmware is Chaos Calmer 15.05.01 (kernel 3.10.108)
with a few custom packages and a non-LuCI web interface.
Telnet is enabled, requiring an unknown root password [1].
Root password is also needed to access the router via UART console,
but passwordless telnet can be enabled via a trivial web exploit [2]
and then the root password can be removed by editing `/etc/shadow`.
Installation: Upload `sysupgrade` binary via web interface at
`http://192.168.188.1/settings.shtml`. Alternatively, remove
root password and use u-boot menu to flash image via TFTP.
Notes:
- Device model in Chaos Calmer is "mtk-apsoc-demo".
- It is sold under several brands, e.g., Fenvi and Linkavenir.
It is available in two colors: white and black.
- PCB is marked "WD206AD v1.0".
- Instead of a standard ethernet transformer, the PCB has a few tiny
SMD coils.
- The housing is identical to the one used by a 2020 model,
WD-R1203U, which is RTL8812-based. The older model has an FCC
listing with external and internal images: ZNPWD-R1203U.
The FCC listing contains a letter [3] claiming WD-R1203U and
WD-R1208U are internally identical, but evidently they are not.
[1] root:$1$7rmMiPJj$91iv9LWhfkZE/t7aCBdo.0:18388:0:99999:7:::
This is the same hash as in Wodesys WD-R1802U.
There are other root password hashes in `/etc/shadow_sf` and
`/etc/shadow_yn`.
[2] curl -X POST http://192.168.188.1/cgi-bin/adm.cgi \
-d page=Lang -d langType="en;killall telnetd;telnetd -l /bin/sh"
[3] https://fcc.report/FCC-ID/ZNPWD-R1203U/4767033
realtek: rtl931x: Sync family parameters with RTL930x
Some of the parameters added to RTL9300_FAMILY_ID are missing for
RTL9310_FAMILY_ID. Simply add the missing ones to keep sharing code between
the two SoCs.
Harshal Gohel [Tue, 17 Jun 2025 12:46:42 +0000 (12:46 +0000)]
realtek: rtl931x: Fix VLAN tagging and untagging
* In RTL931x, bit 31 of the (4th column) of 802_1Q_VLAN_QINQ table
indicates the validity of l2 tunnel. Before bit 63 (3rd column)
was being checked for validity of l2 tunnel.
* The untagged_ports requires 64 bits to represent 56 ports. Do not
store u64 in u32 variable
* First 24 ports are represented in the 2nd register not just first 20
OpenFi 6C is a portable Wi-Fi 6 travel router based on MediaTek MT7981B+MT7976CN.
Two slightly different versions have been sold. The V1 board has a green color and lacks the modem LED. The V2 board is black and has a LED for the modem. The firmware should work on both of them.
Specifications:
- SoC: MediaTek MT7981B (Filogic 820) 1.3GHz dual-core ARM Cortex-A53
- RAM: 1GB DDR4
- Flash: 256MB SPI NAND
- Wireless: 2.4GHz/5GHz 802.11ax
- Ethernet: 1x 10/100/1000M LAN
- USB: 1x USB 3.0 Type-A port
- Expansion: M.2 slot for 5G modem
- Cooling: PWM-controlled fan
- Buttons: Reset, Mode switch
- LEDs: System, Ethernet, 5G WiFi, Modem status
**Installation via U-Boot web page**
1. Set static IP 192.168.21.2/255.255.255.0 on your computer.
2. Connect to the Ethernet port and hold the reset button while booting the device. Wait for 6-8 seconds, and release the reset button.
3. Open U-boot web page on your browser at http://192.168.21.1
4. Select the OpenWRT sysupgrade image, upload it, and start the upgrade.
5. Wait for automatic reboot.
**Installation via sysupgrade**
Flash the sysupgrade file via LuCI upgrade page without saving the settings.
TFTP Installation(recommend)
------------
1. Set local tftp server IP "192.168.1.254" and NetMask "255.255.255.0".
2. Rename initramfs-kernel.bin to "factory.bin" and put it in the root
directory of the tftp server. tftpd64 is a good choice for Windows.
3. Remove all Ethernet cables and WiFi connections from the PC, except
for the one connected to the SIMAX1800U. Start the TFTP server, plug
in the power adapter and wait for the OpenWrt system to boot.
4. Backup "firmware" partition and rename it to "firmware.bin". We need
it to back to the stock firmware.
5. Use "fw_printenv" command to list envs. If "firmware_select=2" is
observed then set u-boot env variable via command:
`fw_setenv firmware_select 1`
6. Apply sysupgrade.bin in OpenWrt LuCI.
Web UI Installation
------------
1. Apply update by uploading initramfs-factory.bin to the web UI.
2. Use "fw_printenv" command to list envs. If "firmware_select=2" is
observed then set u-boot env variable via command:
`fw_setenv firmware_select 1`
3. Apply squashfs-sysupgrade.bin in OpenWrt LuCI.
Return to Stock Firmware
----------------------------
Restore the backup firmware partition in the installation step 4.
MAC addresses
-------------
+---------+-------------------+
| | MAC example |
+---------+-------------------+
| LABEL | 98:xx:xx:xx:xx:b2 |
| LAN | 98:xx:xx:xx:xx:b5 |
| WAN | 98:xx:xx:xx:xx:b2 |
| WLAN2G | 98:xx:xx:xx:xx:b4 |
| WLAN5G | 9a:xx:xx:xx:xx:b4 |
+---------+-------------------+
Tips:
-----------
User can use `TFTP Installation` method to recover a brick device.
The vendor DTS defined incorrect GPIOs for the LEDs, which caused them
to not function properly. Initially, the WAN, WLAN LEDs appeared to
work, but further testing showed that they were non-functional.
This patch corrects the GPIO assignments in the DTS, restoring full LED
functionality including blinking, except the power LED which cannot be
software controlled.
Tested on a CF-EW71 v2 unit.
Fixes: ee3a6adc6c22 ("ath79: add support for Comfast CF-EW71 v2") Signed-off-by: Felix Golatofski <git@xdfr.de> Link: https://github.com/openwrt/openwrt/pull/19665 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Issam Hamdi [Thu, 20 Feb 2025 15:06:00 +0000 (16:06 +0100)]
realtek: dsa: rtl83xx: flush scheduled work on removal
The workqueue items don't need to be processed directly when they are
scheduled. It can happen that they are simply processed at a much later
time. It is therefore necessary to ensure that all workqueue items of a
driver are no longer being processed before the driver (or structures of
this driver) are destroyed.
When skipping this step, the driver driver can cause a kernel Oops on
reboot.
Unfortunately, it is not recommended [1] to flush items out of the system
workqueue - simply because this can cause deadlocks. The driver itself must
have a private workqueue which is then flushed.
Harshal Gohel [Thu, 6 Mar 2025 07:47:18 +0000 (07:47 +0000)]
realtek: rtl930x: Fetch link status for all ports in switch IRQ
Link status needs to be read twice, and a single register value is
enough for determining link status for all the ports
It is not necessary to go through each potential port separately and later
actually identify for which ports the interrupt actually was. The helper
for_each_set_bit() directly iterate through all set bits.
While at it, rename the function to a proper naming scheme.
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL93xx devices. Especially duplex and speed are shown even if
no link is up and running. That leads to confusion because the MAC
reports arbitrary values.
Enhance the readout by refactoring the pcs_get_state() function.
Calculate speed/duplex/pause only if link is detected.
Felix Fietkau [Thu, 7 Aug 2025 13:44:56 +0000 (15:44 +0200)]
procd: update to Git HEAD (2025-08-07)
84372dab89a8 hotplug: switch to using avl tree for hotplug subsystems 4d023b8a8c51 hotplug: send event notifications 467800980021 hotplug: ensure that the button subsystem is always registered
Steve Wavler [Sun, 3 Aug 2025 19:59:16 +0000 (15:59 -0400)]
x86: add board mapping for Sophos XG 210r3
Sophos XG 210r3 is a rackmounted x86 based firewall with 6 RJ-45 gigabit
ethernet ports (eth0-5) and 2 SFP gigabit ethernet ports (eth6, eth7)
all running Intel NICs supported by igb driver. This board update maps
eth0 (left most RJ-45 port) as wan and eth1-7 as lan.
Steve Wavler [Sun, 3 Aug 2025 13:02:55 +0000 (09:02 -0400)]
kernel: Add kmod-sfc-siena for Solarflare SFN5000/6000 series NICs
kmod-sfc should add support for Solarflare SFC9000 series based cards.
However after kernel 5.19, support for the 'Siena' subclass of
SFN5000/6000 devices has been separated out since they went EOL as they
are no longer being actively developed. As kmod-sfc no longer provides
driver support for these cards and hasn't since kernel 5.2, a new kernel
module is needed to support these 10Gb Ethernet cards. More info here:
https://cateee.net/lkddb/web-lkddb/SFC_SIENA.html and here:
https://www.phoronix.com/news/Solarflare-SFC-Siena-Linux-5.19
The module can be compiled in separately and works if kernel is custom
compiled;
OpenWRT has made these changes already with the SFC 'falcon' subclass of
drivers already. See 3c5d70a and e5ba6e9
This is building on excellent work by @ynezz and @nasbdh9
realtek: use consistent definition in DTS for SFP(+) ports
We are slowly getting to the point where the mdio driver will be
carved out from the ethernet driver. Since the beginning it had
the feature to hand out SFP serdes as phys. So one can access
them from the phy driver. This will be kept during the final
migration and it even will provide a consistent interface for the
phy/serdes registers.
With this being done we need to identify how to handle the affected
ports in a generic way for all targets. Doing first things first,
this starts with a consistent DTS. Currently we have:
for all other RTL93x devices:
phy-mode = "10gbase-r"
managed = "in-band-status"
pseudo-phy-handle = ...
Looking at the phylink kernel code one can see a nifty detail.
There is dynamic phy bringup depending on the mode.
int phylink_fwnode_phy_connect(struct phylink *pl,
const struct fwnode_handle *fwnode,
u32 flags)
{
struct fwnode_handle *phy_fwnode;
struct phy_device *phy_dev;
int ret;
/* Fixed links and 802.3z are handled without needing a PHY */
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
phy_interface_mode_is_8023z(pl->link_interface)))
return 0;
...
}
Where 802.3z means 1000base-x or 2500base-x. Aligning this with
IEEE specs it means essentially:
- 10gbase-r defined ports with phy-handle must statically bring up
a phylink from the beginning that immediately depends on a
phy read_status() implementation.
- 1000base-x/2500base-x defined ports will dynamically bringup a
phylink during link detection regardless of a phy-handle. So
it usually runs at the moment when a SFP has been plugged in.
We currently still rely on a phy-handle but do not want to bring
up the phy immediately. Commit 4457c1eee49 ("realtek: rtl93xx:
support SFPs with phys") tried to fix exactly that error for
10gbase-r definied ports. Kernel shows "sfp sfp-p8: sfp_add_phy
failed: -EBUSY" in that case.
But it did it in the wrong way. It implemented a workaround by
introducing a DTS property "pseudo-phy-handle". Instead it
should have simply converted the DTS nodes to 1000base-x.
Revert the commit and fix the DTS with wrong definitions. From
now on we have a consistent SFP definition throughout all DTS
and targets.
Aside from the positive effect this setting has it is more or
less an arbitrary speed definition. When plugging in the SFP the
real speed will be choosen dynamically.
Fixes: 4457c1eee49 ("realtek: rtl93xx: support SFPs with phys") Tested-By: Bjørn Mork <bjorn@mork.no> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19648 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
realtek: rtl930x: convert Hasivo S1100W to lzma only.
The current build recipe creates a lzma based initramfs and
a gzip based sysupgrade (installation) image. No need to
use different compression methods. Use lzma for both.
Tested-by: Andrew LaMarche <andrewjlamarche@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19669 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jan Hoffmann [Tue, 5 Aug 2025 00:41:32 +0000 (02:41 +0200)]
realtek: move and clean up CHIP_INFO register definitions
Move the definitions to mach-rtl83xx.h, so they can be used during init
to read more detailed SoC information. Also rename the RTL931X register,
as it has the same address on all RTL93xx.
Jan Hoffmann [Sat, 2 Aug 2025 18:28:50 +0000 (20:28 +0200)]
realtek: simplify SoC detection
Read model name from the register instead of using hard-coded values.
Also remove detection of the unsupported Realtek ESW/SSW SoCs. The Fast
Ethernet variants of the Maple and Cypress series stay for now, but are
moved to the RTL8380/RTL8390 families.
Felix Fietkau [Wed, 6 Aug 2025 09:09:57 +0000 (11:09 +0200)]
mac80211: estimate expected throughput if not provided by driver/rc
Estimate the tx throughput based on the expected per-packet tx time.
This is useful for mesh implementations that rely on expected throughput,
e.g. 802.11s or batman-adv.
Jonas Jelonek [Mon, 4 Aug 2025 09:17:55 +0000 (09:17 +0000)]
realtek: use lzma recipe for TP-Link TL-ST1008F v2.0
Use the lzma recipe for the device for both initramfs and sysupgrade to
save some flash space due to smaller image. U-Boot build on this device
has native lzma support.
realtek: rtl930x: move serdes functions over to mdio bus
The migration of the RTL930x mdio/serdes access functions over to the
mdio bus is a little more complicated than for RTL83xx. There are several
places where the serdes is accessed directly. So do it in two steps. With
this first step:
- use the rtmdio prefix for the serdes reader/writer functions
- move the functions over to the bus (inside the ethernet driver)
- Adapt all callers.
This is not only a copy/paste but the serdes access will be hardened too.
For this:
- put a mutex around the read/write functions because we have only
indirect register access through a mdio style bus.
- Verify input values to avoid data mess.
Tested-by: Bjørn Mork <bjorn@mork.no> Tested-by: Jan Hoffmann <jan@3e8.eu> Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19662 Signed-off-by: Robert Marko <robimarko@gmail.com>
Nick Hainke [Tue, 5 Aug 2025 16:21:55 +0000 (18:21 +0200)]
ead: replace legacy RETSIGTYPE with void in signal handler
The RETSIGTYPE macro was historically used for signal handler return types,
defaulting to int on some legacy systems. This is no longer needed,
so we now use void as the return type.
Fixes a compiler error:
error: assignment to 'void (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]
realtek: RTL839x: reorganize mdio functions and SerDes register layout
The RTL839x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver).
Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
Michael Pratt [Sat, 2 Aug 2025 08:12:17 +0000 (04:12 -0400)]
tools: gnulib: do not cache C standard option test results
After eliminating the possibility of automake having a bug
by testing a revert to the recent updates to automake,
the problems regarding autoreconf with some packages
was bisected to the gnulib update instead, through aclocal macros.
With the new module, std-gnu23, some packages are failing build
due to both the host compiler and cross compiler being tested for
availability of C23 standard features with the configure script.
The results of one is being cached and used for the other,
while the two compilers are different versions and may or may not
both support C23 options and would otherwise have conflicting results.
A similar patch may have to be done
for the next release of Autoconf
if upstream GNU does not accept this solution.
Reported-by: Georgi Valkov <gvalkov@gmail.com> Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19627 Signed-off-by: Nick Hainke <vincent@systemli.org>
Felix Fietkau [Sat, 2 Aug 2025 14:45:39 +0000 (16:45 +0200)]
netifd: update to Git HEAD (2025-08-02)
3a7878065829 system-dummy: add missing vrf functions 471d9d6abb6d CMakeLists.txt: bump minimum required version c3a0255e2150 scripts: fix dummy mode on systems where libubox is in /usr/local 7a3b281230e4 update example mac80211 script and wireless config d9f2dd2614f2 wireless: replace with ucode scripts 74c22601baad wireless: add MLO support to example scripts
realtek: mdio: RTL838x: create new SerDes phy register layout
When a SerDes directly drives a SFP module there is no clear rule of
how to handle its register set that consists of two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Provide a consistent phy interface that mixes the SerDes register
set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
Christian Korber [Wed, 21 May 2025 12:36:00 +0000 (14:36 +0200)]
hostapd: fix logging of configuration content
As discussed in openwrt#17517, there are contents of hostapd's configuration file logged in syslog.
This includes critical information like `passphrase`. To circumvent this condition,
this commit logs only "inline" if config_fname is inline data.
Michael Pratt [Fri, 1 Aug 2025 04:20:48 +0000 (00:20 -0400)]
tools: util-linux: allow building with 32-bit time
Similar to several GNU tools, util-linux when built using meson
is configured by default to error when 64-bit time is not supported.
To solve this in the same way as standard configure scripts,
check for 64-bit time support ahead of time,
and allow 32-bit time when not supported.
In the future, the YEAR_2038 variable
can be used as a build prerequisite
instead of being used for configuration.
Ref: 39e8ef33bf ("build: add test for 64-bit time support") Fixes: e15d5cf752 ("tools/util-linux: build with meson") Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19617 Signed-off-by: Nick Hainke <vincent@systemli.org>
Nick Hainke [Thu, 31 Jul 2025 16:05:07 +0000 (18:05 +0200)]
gettext-full: fix m4 path after gettextize update
Recent changes to gettextize altered the default path for .m4 files from
$datadir/aclocal to $datadir/gettext/m4 [0]. This caused build issues when
compiling gettext-full in OpenWrt.
This patch, originally provided by @nxhack [1], updates the OpenWrt
Makefile accordingly to ensure compatibility with the new path.
The DSA has a link to the MDIO bus and already uses the read/write functions
that are provided. In parallel the dsa_switch_ops structure provides an
interface for phy_read and phy_write. These are still open-coded and sadly
circumvent the bus. Simplify the implementation and avoid inconsistencies by
reusing the existing bus infrastructure.
Additionally, remove two unused MMD header definitions as a quick win.
Reported-by: Jan Hoffmann <jan@3e8.eu> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19548 Signed-off-by: Robert Marko <robimarko@gmail.com>
The function rtl93xx_setup() is called by both RTL930x and RTL931x. But
only the RTL930x specific function to print port matrix was called.
Unfortuntaly, RTL931x needs a different function to access the correct
registers to retrieve the port matrix information.
It is therefore necessary differentiate in rtl93xx_setup between the
SoC families before calling the appropriate function.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: rtl931x: Update irq mask to cover all ports
The RTL931x has 56 (0-55) non-CPU ports. To receive updates about the port
state, it is therefore necessary to enable the interrupts for all these
ports.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
Harshal Gohel [Wed, 18 Jun 2025 11:35:15 +0000 (11:35 +0000)]
realtek: rtl931x: Fix traffic on upper ports
* traffic isolation tables are different between rtl930x and rtl931x
* traffic_enable/disable/get/set functions span multiple columns in the
rtl931x as a result, previous implementation would only enable traffic
in some ports.
traffic_enable/disable and traffic_set/get should now work on all ports and
not just the initial 32
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
The commit d2108c2c5896 ("realtek: enhance RTL930x SerDes/PLL/CMU
interoperability") removed a couple of commands for the bringup code.
One of these commands was necessary to bring up SFP modules correctly. This
one can also be found in the RTLSDK [1].
It is currently not 100% clear what this command does. But if it works
similar to the RTL8295 [2,3] (RTL8295_SDS0_ANA_MISC_REG00_REG), we could
assume that it could be the RX_ON and RX_EN bits.
Daniel Golle [Thu, 31 Jul 2025 18:48:32 +0000 (19:48 +0100)]
kernel: add backport to fix broken PHY LEDs
A commit which broke netdev trigger LEDs offloaded to PHYs recently made
it all the way down to the Linux 6.6 stable branch. The revert has been
accepted to linux-next, however, a backport to the various -stable trees
is still pending.
Import the backported revert commit to fix in OpenWrt in the meantime
until the revert also gets picked to linux-stable.
Include the NAND specs into the DTS. It is unclear which devices
really need it. Keep it disabled for now. As the SoC register area
is defined too small until now, increase the size to an appropriate
value.
If enabled one can see the following log messages (e.g. Linksys
LGS328C or LGS352C).
[ 1.206600] spi-nand spi1.0: Macronix SPI NAND was found.
[ 1.212795] spi-nand spi1.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 1.222217] 3 fixed-partitions partitions found on MTD device spi1.0
[ 1.229466] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.236617] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.244164] Creating 3 MTD partitions on "spi1.0":
[ 1.249620] 0x000000000000-0x000004000000 : "ubifs"
[ 1.423593] 0x000004000000-0x000005e00000 : "firmware"
[ 1.738268] mtdsplit_uimage: no uImage found in "firmware"
[ 1.744577] 0x000005e00000-0x000007c00000 : "runtime2"
RTL93xx devices have a NAND controller built in. Upstream already
has a driver in place. Include it downstream. Activate it in the
RTL93xx builds and disable it for the RTL83xx builds.
Michael Pratt [Wed, 30 Jul 2025 18:44:16 +0000 (14:44 -0400)]
tools: bison: do not install or uninstall macros
There is a clobbering between bison and gnulib for installing
the macro file bison-i18n.m4 where gnulib has a newer version
while bison will replace it with an outdated version if built afterward.
Other builds depend on the changes made to the bison-i18n.m4 file and are
only included using aclocal unless other modifications are made in each case
in order to force imported macros from gnulib to override aclocal macros.
Gnulib is integrated within bison, however it is not with a bootstrap script
and there is already a reverse dependency between the two, where bison
is indirectly required for gnulib to start building. Therefore, do not allow
the building or cleaning of bison to install or uninstall m4 files.
Reported-by: Tianling Shen <cnsztl@immortalwrt.org> Fixes: d19f8bc199 ("tools/gnulib: update to branch stable-202501") Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19606 Signed-off-by: Nick Hainke <vincent@systemli.org>
projects / thirdparty / openwrt.git / log
