This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
(This was a real problem I encountered with a nanopi R6S device and
an external rtl8152 usb3 network controller - the USB controller would
claim the eth1 name, causing much confusion).
rockchip: set network IRQ affinity to fast CPU cores
The nanopi R6S, R6C and nanopc T6 platforms are based on rk3588(s) SoC,
which has fast and slow CPU cores. Set up network interrupt affinity to be
on the fast CPU cores by default. This is similar to the way this was
already configured on nanopi R4S.
rockchip: show boot stages on nanopi R6 system LED
Set up openwrt to show boot progress on the nanopi R6S or R6C system LED.
The LED blinking states indicate the boot stage. The LED is defined as
a power LED, but can still be set to heartbeat in /etc/config/system
after the system is done booting.
Rename 852-stable-bus-mhi-host-pci_generic-constify-modem_telit_fn980_.patch
to 852-v6.9-stable-bus-mhi-host-pci_generic-constify-modem_telit_fn980.patch
because it is used since kernel 6.9-rc1 (https://lore.kernel.org/lkml/Zfwv2y7P7BneKqMZ@kroah.com/).
Mauri Sandberg [Thu, 30 Jan 2025 16:08:25 +0000 (18:08 +0200)]
ramips: Cleanup Genexis EX400 upgrade script
The code can be made more efficient by not extracting the sysupgrade.tar but
rather just querying for the filesize within the archive. Resorting to
manual update of UBI volume is extra work too, setting CI_KERNPART=rootfs_0
is enough.
Suggested-by: Andreas Gnau <andreas.gnau@iopsys.eu> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi> Link: https://github.com/openwrt/openwrt/pull/17806 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
local access.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel disclosed
that some processor models were already fixed by a previous
microcode update.
- Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Added mitigations for more processor models.
* Updated Microcodes:
sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
* source: update symlinks to reflect id of the latest release, 20241112
* Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
some processor models.
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 15:37:40 -0300
* New upstream microcode datafile 20241029
- Not relevant for operating system microcode updates
- Only when loaded from firmware, this update fixes the critical,
potentially hardware-damaging errata RPL061: Incorrect Internal
Voltage Request on Raptor Lake (Core 13th/14th gen) Intel
processors.
* Updated Microcodes:
sig 0x000b0671, pf_mask 0x32, 2024-08-29, rev 0x012b, size 211968
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 14:49:03 -0300
* New upstream microcode datafile 20240910 (closes: #1081363)
- Mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Fixes for unspecified functional issues on several processor models
- The processor voltage limit issue on Core 13rd/14th gen REQUIRES A
FIRMWARE UPDATE. It is present in this release for sig 0xb0671, but
THE VOLTAGE ISSUE FIX ONLY WORKS WHEN THE MICROCODE UPDATE IS LOADED
THROUGH THE FIT TABLE IN FIRMWARE. Contact your system vendor for a
firmware update that includes the appropriate microcode update for
your processor.
* Updated Microcodes:
sig 0x00090672, pf_mask 0x07, 2024-02-22, rev 0x0036, size 224256
sig 0x00090675, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f2, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f5, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000906a3, pf_mask 0x80, 2024-02-22, rev 0x0434, size 222208
sig 0x000906a4, pf_mask 0x80, 2024-02-22, rev 0x0434
sig 0x000a06a4, pf_mask 0xe6, 2024-06-17, rev 0x001f, size 137216
sig 0x000b0671, pf_mask 0x32, 2024-07-18, rev 0x0129, size 215040
sig 0x000b06a2, pf_mask 0xe0, 2024-02-22, rev 0x4122, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06a8, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06e0, pf_mask 0x19, 2024-03-25, rev 0x001a, size 138240
* Update changelog for 3.20240813.1 with new information
* Update changelog for 3.20240514.1 with new information
* source: update symlinks to reflect id of the latest release, 20240910
* New upstream microcode datafile 20240813 (closes: #1078742)
- Mitigations for INTEL-SA-01083 (CVE-2024-24853)
Incorrect behavior order in transition between executive monitor and SMI
transfer monitor (STM) in some Intel Processors may allow a privileged
user to potentially enable escalation of privilege via local access.
- Mitigations for INTEL-SA-01118 (CVE-2024-25939)
Mirrored regions with different values in 3rd Generation Intel Xeon
Scalable Processors may allow a privileged user to potentially enable
denial of service via local access.
- Mitigations for INTEL-SA-01100 (CVE-2024-24980)
Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel
Xeon Processors may allow a privileged user to potentially enable
escalation of privilege via local access.
- Mitigations for INTEL-SA-01038 (CVE-2023-42667)
Improper isolation in the Intel Core Ultra Processor stream cache
mechanism may allow an authenticated user to potentially enable
escalation of privilege via local access. Intel disclosed that some
processor models were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01046 (CVE-2023-49141)
Improper isolation in some Intel Processors stream cache mechanism may
allow an authenticated user to potentially enable escalation of
privilege via local access. Intel disclosed that some processor models
were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel released this
information during the full disclosure for the 20241112 update.
Processor signatures 0x606a6 and 0x606c1.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Intel released this information during the full disclosure
for the 20240910 update. Processor signatures 0x5065b, 0x606a6,
0x606c1.
- Fix for unspecified functional issues on several processor models
- Fix for errata TGL068/ADL075/ICL088/... "Processor may hang during a
microcode update". It is not clear which processors were fixed by this
release, or by one of the microcode updates from 2024-05.
- Mitigations for INTEL-SA-01213 (CVE-2024-36293)
Improper access control in the EDECCSSA user leaf function for some
Intel Processors with Intel SGX may allow an authenticated user to
potentially enable denial of service via local access. Intel released
this information during the full disclosure for the 20250211 update.
Processor signature 0x906ec (9th Generation Intel Core processor).
* Updated microcodes:
sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936
sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720
sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224
sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032
sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688
sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640
sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328
sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448
sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472
sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496
sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480
sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472
sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496
sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496
sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496
sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304
sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280
sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544
sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216
* source: update symlinks to reflect id of the latest release, 20240813
* postinst, postrm: switch to dpkg-trigger to run update-initramfs
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 15 Aug 2024 14:41:50 -0300
Andreas Gnau [Tue, 7 Jan 2025 22:55:12 +0000 (23:55 +0100)]
ramips: Add support for Genexis / Inteno Pulse EX400
Add support for Genexis Pulse EX400 / Inteno Pulse EX400. A branded
variant for the Finnish ISP DNA has already been added in fea2264d9fdd
(ramips: mt7621: Add DNA Valokuitu Plus EX400, 2023-07-31). This commit
adds support for the generic variants with Inteno and Genexis branding.
Inteno changed its name to Genexis and both brandings exist.
In terms of electronics, there is no difference between the DNA-branded
version and other brandings. LED markings on the case are different,
though. While the DNA-version has a "software-update" LED, the other
versions have a WPS LED. To reduce user confusion, create a separate
image.
Add the different device-tree with the different LED and rename things
to work the same way for both variants.
Firmware:
The vendor firmware is a fork of OpenWrt (Reboot) with a kernel version
4.4.93. The flash is arranged as below and there is a dual boot
mechanism alternating between rootfs_0 and rootfs_1.
In OpenWrt rootfs_0 will be used as a boot partition that will contain the
kernel and the dtb. The squashfs rootfs and overlay are standard OpenWrt
behaviour.
U-boot:
With proper serial access, booting can be halted to U-boot by pressing
any key. TFTP and flash writes are available, but only the first one has
been tested.
NOTE: Recovery mode can be accessed by holding down the reset button while
powering on the device. The led 'Update' will show a solid green light
once ready. A web server will be running at 192.168.1.1:80 and it will
allow flashing a firmware package. You can cycle between rootfs_0 and
rootfs_1 by pressing the reset button once.
Root password:
With the vendor web UI create a backup of your settings and download the
archive to your computer. Within the archive in the file
/etc/shadow replace the password hash for root with that of a password you
know. Restore the configuration with the vendor web UI and you will have
changed the root password.
SSH access:
You might need to enable the SSH service for LAN interface as by default
it's enabled for WAN only.
Installing OpenWrt:
With the vendor web UI, or from the U-Boot recovery UI, install the
OpenWrt factory image. Alternatively, ssh to the device and use
sysupgrade -n from cli.
Finalize by installing the OpenWrt sysupgrade image to get a fully
functioning system.
Reverting to the vendor firmware:
Boot with OpenWrt initramfs image
- Remove volumes rootfs_0, rootfs and rootfs_data and create vendor
volumes.
Andreas Gnau [Tue, 7 Jan 2025 22:04:30 +0000 (23:04 +0100)]
ramips: mt7621: Move common DNA EX400 defs to dtsi
Move common definitions for DNA Valokuitu Plus EX400 to a dtsi include.
This is in preparation of adding the non-branded variant of the device
produced by Genexis / Inteno in the next commit. The device with DNA
branding differs in the LED labling on the device.
Hauke Mehrtens [Wed, 12 Mar 2025 22:54:38 +0000 (23:54 +0100)]
armsr: Fix kmod-fsl-dpaa2-net build
The build failed because the CONFIG_FSL_DPAA2_ETH_DCB option was not
set. Activate this option to build the driver with DCB support when it
is available.
Dávid Benko [Mon, 24 Feb 2025 10:01:19 +0000 (11:01 +0100)]
hostapd/RADIUS_server: enhance logging
Currently, logging level of the RADIUS server is a constant corresponding
to the highest verbosity (EXCESSIVE, ALL), but when running as a system
service, the output is discarded.
This commit makes logging verbosity configurable by `log_level` option
and redirects all logs to `logd`. Possible levels are defined in hostap
sources:
https://w1.fi/cgit/hostap/tree/src/utils/wpa_debug.h?id=012a893c469157d5734f6f33953497ea6e3b0169#n23
Their reference is inlined in `radius.config` file.
Default value for logging verbosity is INFO (even if the `-l` flag isn't
specified).
Nick Hainke [Sat, 8 Mar 2025 19:17:19 +0000 (20:17 +0100)]
libnl: update to 3.11.0
Changes: c7edc38f libnl-3.11.0 release b75e27de lib/route: add support for bridge msti 8a73b245 lib/route: add support for bridge info boolopts 3b284a11 lib/route: extend bridge info support a43a41cd lib/route: add missing bridge info getter functions 756d5161 lib/route: add missing entry in libnl-route-3.sym file 014c33a6 lib/route: add rtnl_neigh ext flags support acf572b5 route: add support for getting permanent mac address of link afafe78a lib/route: extend bridge flags 11597b73 xfrm: remove redundant check in xfrm_sa_update_cache() 2abfb089 xfrm: use the new _nl_auto_nl_object helper 831e9868 cache: use the new _nl_auto_nl_object helper 4b9daa6d add _nl_auto_nl_object helper 379a1405 black: fix "target-version" in "pyproject.toml" 8460c9b7 link/bonding: implement parsing link type d60535c9 link/bonding: implement comparing bond links 22b6cf5c link/bonding: implement io_clone() e1c75bff link/bonding: add getters for attributes ee4612ca link/bonding: rename bn_mask to ce_mask 81c40cbb tests: optimize _nltst_assert_route_list_permutate() to short cut search through permutations 9f5fac78 tests: in _nltst_assert_route_list() accept arbitrary order 01f06b57 base: add _nl_swap() helper macro 5b570259 tests: ensure that there are all expected routes in _nltst_assert_route_list() 1aa16ea9 tests: print route list before failure in _nltst_assert_route_list() 7f099cf0 tests: add _nltst_objects_to_string() helper e76d5697 tests: add _nltst_malloc0() and _nltst_sprintf() helpers d94a3e81 tests: move definition of asserts in "tests/nl-test-util.h" 798278ea tests: use _nl_ptrarray_len() helper in _nltst_assert_route_list() def89a2c base: add _nl_ptrarray_len() helper 64fad14b link: link_msg_parser(): keep link info instead of release and reacquire b8d3cfb2 lib/attr: add nla functions for variable-length integers 2ae88c48 lib/attr: add NLA_{SINT|UINT} attribute types
Rui Salvaterra [Sat, 1 Feb 2025 18:51:42 +0000 (18:51 +0000)]
kernel: usb: simplify r8152 dependencies
It doesn't depend on either usb-net or usb-net-cdc-ncm. It does, however, depend
on mii. Fix thusly, and make it depend explicitly on usb, not usb-net.
While at it, add a conditional dependency on libphy, for future kernel versions.
Rui Salvaterra [Sat, 1 Feb 2025 18:38:37 +0000 (18:38 +0000)]
generic: enable CONFIG_USB_NET_DRIVERS
This is only relevant for devices with USB support, and in itself changes
nothing in the kernel build. However, it is useful to further simplify the
dependencies of some USB network devices.
Coia Prant [Fri, 3 Jan 2025 18:43:17 +0000 (02:43 +0800)]
ramips: add support for Hongdian H8922 v30
This is an industrial 4G router equipped with OpenWrt 14.07 OEM
customized version
WARNING: The original firmware device tree is common to multiple
boards, and the device tree name is H9350. This submitted device
tree is a modified version, which deletes the non-this-device parts
and adds GPIO watchdog.
Issue:
- No factory partition, eeprom is located
at /lib/firmware/mt7620a.eeprom
Flash instruction:
Using UART:
1. Configure PC with a static IP address and setup an TFTP server.
2. Put rootfs into the tftp directory.
3. Connect the UART line as described on the PCB.
4. Power up the device and press Ctrl+C to break auto boot.
5. Use `system 6` command and follow the instruction to set device
and tftp server IP address and input the rootfs file name.
U-boot will then load the rootfs and write it into
the flash.
6. Use `system 1` command and follow the instruction to set device
and tftp server IP address and input the firmware file name.
U-boot will then load the firmware once.
7. Login to LuCI and use LuCI upgrade firmware.
Original Firmware Dump / More details:
https://blog.gov.cooking/archives/research-hongdian-h8922-and-flash.html
Coia Prant [Mon, 17 Feb 2025 06:22:59 +0000 (14:22 +0800)]
mac80211: rt2x00: load the eeprom data from devicetree embedded data on Ralink SoCs
It will allow loading eeprom from eeprom-data embedded in device tree.
Ported from mediatek mt76 wireless driver (drivers/net/wireless/mediatek/mt76/eeprom.c)
Amber LAN LED appears hardwired to ethernet port. Power LED is green
only. Other LEDs are amber/green.
**MAC addresses:**
1 MAC Address in flash at end of uboot
ASCII encoded, no delimiters
Labeled as "MAC Address" on case
**Serial Access:**
Pinout: (arrow) VCC GND RX TX
Pins are populated with a header and traces not blocked.
Bootloader is set to 9600 baud, 8 data, 1 stop.
**Console Access:**
Bootloader:
Interrupt boot with Ctrl+C
Press "k" and enter password "1"
OR
Hold reset button for 5 sec during power on
Interrupt the TFTP transfer with Ctrl+C
to print commands available, enter "help"
OEM:
default username is "admin", password blank
telnet is available at default address 192.168.1.2
serial is available with baud 9600
to print commands available, enter "help"
or tab-tab (busybox list of commands)
**Installation:**
Use factory.bin with OEM upgrade procedures
OR
Use initramfs.bin with uboot TFTP commands.
Then perform a sysupgrade with sysupgrade.bin
**TFTP Recovery:**
Using serial console, load initramfs.bin using TFTP
to boot openwrt without touching the flash.
**Return to OEM:**
The best way to return to OEM firmware
is to have a copy of the MTD partitions
before flashing Openwrt.
Backup copies should be made of partitions
"fwconcat0", "loader", and "fwconcat1"
which together is the same flash range
as OEM's "rootfs" and "uimage"
by loading an initramfs.bin
and using LuCI to download the mtdblocks.
It is also possible to extract from the
OEM firmware upgrade image by splitting it up
in parts of lengths that correspond
to the partitions in openwrt
and write them to flash,
after gzip decompression.
After writing to the firmware partitions,
erase the "reserved" partition and reboot.
Eric ZHANG [Sun, 2 Mar 2025 07:54:37 +0000 (15:54 +0800)]
dnsmasq: fix handlers for options `filter_rr` and `cache_rr`
According to:
- https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js#L700
- https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/dhcp.js#L402
These two options should be of type `MultiValue` but here there're used as single value. This results in dnsmasq crashes when either of these options are set with multiple values, which leads to an invalid space-separated value.
As these options are designed to take multiple values, I think it's better to use list format eg. `list filter_rr 'AAAA'`, instead of `option filter_rr 'AAAA,HTTPS'`.
Hauke Mehrtens [Sun, 19 Jan 2025 18:49:38 +0000 (19:49 +0100)]
kernel: Add KERNEL_DCB (Data Center Bridging)
The kmod-mlxsw-spectrum driver activated CONFIG_DCB indirectly already
on all targets which are building this driver. All other DCB capable
driver did not activate their DCB support.
CONFIG_DCB increases the uncompressed kernel size by about 7.8KB.
CONFIG_DCB is only needed some data center Ethernet cards and not used
on normal routers. Activate it only on the x86_64 and the armsr_arm64
target which are used on normal servers or in VMs.
MAC Addresses:
- There is one on the label, e.g. xx:xx:xx:xx:xx:1C
- LAN (bottom connector) is the same as the label, e.g. xx:xx:xx:xx:xx:1C
- WAN (top connector) is label +2, e.g. xx:xx:xx:xx:xx:1E
- WLAN (2.4G) is the same as the label, e.g. xx:xx:xx:xx:xx:1C
- WLAN (5G) is the same as WAN, e.g. xx:xx:xx:xx:xx:1E
UART:
- is available via the pin holes on the board
- From inner to outer pin: TX, RX, GND, VCC
- Do NOT connect VCC
- Settings: 3.3V, 115200, 8N1
GPIO:
- There are two LEDs: Red (GPIO 3) and White (GPIO 4)
- There are two buttons: Reset (GPIO 8) and WPS (GPIO 10)
Migration to OpenWrt:
- Download the migration image from the Cudy website (it should be available as soon as OpenWrt officially supports the device)
- The migration image is also available here until a image is provided by Cudy: https://github.com/RolandoMagico/openwrt-build/releases/tag/M1300_Build_20240222
- File: openwrt-ramips-mt7621-cudy_m1300-v2-squashfs-flash-signed.bin
- Connect computer to LAN (bottom connector) and flash the migration image via OEM web interface
- In the migration image, LAN and WAN are swapped. Computer must be connected to the other port after flashing
- OpenWrt is now accessible via 192.168.1.1
- After flashing an up to date OpenWrt image, LAN and WAN settings are again the same as in the OEM firmware
- So use the other connector again
Revert back to OEM firmware:
- Set up a TFTP server on IP 192.168.1.88 and connect to the LAN port (lower port)
- Provide the Cudy firmware as recovery.bin in the TFTP server
- Press the reset button while powering on the device
- Recovery process is started now
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
General information:
- No possibility to load a initramfs image via U-Boot because there is no option to interrupt U-Boot
Felix Fietkau [Sun, 9 Mar 2025 15:43:58 +0000 (16:43 +0100)]
unetd: update to Git HEAD (2025-03-09)
d8b43985e4d7 ubus: fix token_create policy 7326459bd743 ubus: dump service information on network_get 6c9c8fbd8128 service: add @all as alias for all members, unless defined differently
Tianling Shen [Sun, 2 Mar 2025 12:06:49 +0000 (20:06 +0800)]
ramips: fix reading mac address for hiwifi hc5962
The spaces in variables have been stripped since commit 551e04f3c9c0
("base-files: strip space and tab characters from ASCII mac address"),
resulting "Vfac_mac " matches nothing. Fix the issue by removing the
space at end.
Tianling Shen [Wed, 26 Feb 2025 13:52:53 +0000 (21:52 +0800)]
mediatek: add support for CMCC A10
This board is also as known as SuperElectron ZN-M5 and ZN-M8. However,
for ZN-M5 and ZN-M8, there's another version uses ZX279128 as CPU
chip, which is unsupported.
You can check it in "高级设置" > "系统日志" > "内核日志" page from webUI.
Stock layout flash instructions:
Login into webUI and upload sysupgrade firmware in "系统管理" > "升级固件" page.
Remember to unselect "保留配置" ("Keep configurations") first before doing that.
OpenWrt U-Boot layout flash instructions:
1. Flash stock layout firmware first.
2. Connect to the device via SSH, and backup everything,
especially 'Factory' partition.
3. Unlock MTD partitions:
apk update && apk add kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
4. Write new BL2 and FIP:
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-preloader.bin BL2
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-bl31-uboot.fip FIP
5. Set static IP on your PC:
IP 192.168.1.254/24, GW 192.168.1.1
6. Serve OpenWrt initramfs image using TFTP server.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt has booted, perform sysupgrade.
Quoting the kconfig description for CONFIG_PCPU_DEV_REFCNT:
network device refcount are using per cpu variables if this option is
set. This can be forced to N to detect underflows (with a performance
drop).
This was introduced from kernel 5.13 and was wrongly set as disabled.
Some target actually enables it but this should be always enabled unless
refcount needs to be debugged (unlikely for production images)
Enable in generic and drop the entry in every other target.
Weikai Kong [Thu, 6 Mar 2025 23:58:40 +0000 (18:58 -0500)]
qualcommax: fap650: fix dtc warnings on partitions
This commit adds the missing properties to address the following warnings:
Warning (reg_format): /soc@0/spi@78b5000/flash@0/partitions/partition@x:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)"
Signed-off-by: Weikai Kong <priv@pppig236.com>
Link: #18180 Signed-off-by: Robert Marko <robimarko@gmail.com>
Qingfang Deng [Fri, 7 Mar 2025 12:33:06 +0000 (20:33 +0800)]
kernel: Mediatek: set default EEE Tx LPI timer
Due to API changes during the backport, the default value of Tx LPI
timer is accidentally left unset, breaking the network if EEE is on.
Set the default timer to 1ms on init, and fix an incorrect condition.
Martin Schiller [Thu, 6 Mar 2025 08:38:12 +0000 (09:38 +0100)]
mediatek: Refresh kernel configuration
I selected one subtarget after the other and refreshed their
configuration using this command:
make kernel_oldconfig CONFIG_TARGET=subtarget
For MT7629 I had to re-add CONFIG_LEDS_SMARTRG_LED manually.
Otherwise, building MT7629 with ALL_KMODS we get prompted for
LEDS_SMARTRG_LED and this will break CI and in future buildbot
compilation. See commit 6bdea8c7bd85 ("mediatek: mt7629: 6.6: disable
LEDS_SMARTRG_LED by default") for more details.
Ahmed Naseef [Tue, 28 Jan 2025 07:28:31 +0000 (11:28 +0400)]
kernel: usbnet: Restore usb%d naming for cdc-ethernet devices with local MAC
Prior to commit https://github.com/torvalds/linux/commit/8a7d12d674ac6f2147c18f36d1e15f1a48060edf,
cdc-ethernet USB LTE modems (e.g. Quectel EC200A) were consistently named
usb0. After 8a7d12d67, devices began renaming to eth1 due to an assumption
that local MAC addresses originate exclusively from the kernel. Some
devices provide driver-assigned local MACs, causing point-to-point
interfaces with driver-set MACs to adopt eth%d names instead of usb%d.
Restore the naming exception for point-to-point devices: interfaces
without driver MACs or with driver-provided local MACs will retain the
usb%d convention. This addresses issues reported in [1] and fixed in [2].
Tested-by: Ahmed Naseef <naseefkm@gmail.com> Signed-off-by: Ahmed Naseef <naseefkm@gmail.com> Link: https://github.com/openwrt/openwrt/pull/17757 Signed-off-by: Robert Marko <robimarko@gmail.com>
Daniel Golle [Mon, 3 Mar 2025 13:27:15 +0000 (13:27 +0000)]
libpcap: backport support for various DSA tags
Trying to tcpdump DSA conduits results in errors such as
"unsupported DSA tag: mtk".
Backport two commits adding support for various DSA tags to libpcap.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Matthew Cather [Mon, 3 Mar 2025 21:46:03 +0000 (15:46 -0600)]
hostapd: get reference to object before removal
`ucv_array_set` releases the array's reference to the object being cleared.
If this is the last reference to the object, it will be freed, making our
pointer `val` invalid.
To avoid this, we need to obtain our own reference to the object so we
can safely return `val`.
Signed-off-by: Matthew Cather <mattbob4@gmail.com>
Matthew Cather [Mon, 3 Mar 2025 20:00:35 +0000 (14:00 -0600)]
hostapd: consistent reference counting for registry
Since `wpa_ucode_registry_add` collects its own reference to the values added, the
two functions `hostapd_ucode_bss_get_uval` and `hostapd_ucode_iface_get_uval` would
sometimes return a referenced object (from `uc_resource_new`) and sometimes return
an unreferenced object (from `wpa_ucode_registry_get`). Now, both functions always
return a referenced object.
This change also indirectly fixes `hostapd_ucode_bss_get_uval`, ensuring it now
always returns a referenced object.
Signed-off-by: Matthew Cather <mattbob4@gmail.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Matthew Cather [Mon, 3 Mar 2025 19:22:11 +0000 (13:22 -0600)]
hostapd: fix ucode memory leak with strings
This fixes a common reference counting bug typically along the lines of:
```
uc_value_push(ucv_get(ucv_string_new(...)));
```
This would leave our new string with a reference count of 2, one from
the construction of the string, the other from `ucv_get`. This would
prevent the strings from being correctly cleaned up when it goes out
of scope.
Signed-off-by: Matthew Cather <mattbob4@gmail.com>
Drop Airoha MTD parser patch as a better solution was agreed with a
fixed partition table.
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # tested on Quantum W1700k Link: https://github.com/openwrt/openwrt/pull/18112 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Cleanup kernel config and drop all unrelated configs. This have the side
effect of fixing the port not going up automatically due to Bridge VLAN
Filtering disabled.
Cedric CHEDALEUX [Mon, 17 Feb 2025 09:44:36 +0000 (10:44 +0100)]
scripts/feeds: shallow clone submodules
When a feed has submodules, all its submodules are fully cloned whereas
the feed itself is shallowed. Let's be consistent and perform shallow clones
as well for the submodules.
Cedric CHEDALEUX [Mon, 17 Feb 2025 09:41:32 +0000 (10:41 +0100)]
scripts/feeds: shallow clone for specific commit update
When a feed is referenced with a specific commit (i.e. <git_url>^<sha1>),
a full clone was performed and a branch was created from the sha1
and named with the sha1. Other git clones operations are shallowed.
As Git does not support clone at a specific commit, let's first perform
a shallow clone to latest commit, then fetch the relevant commit and
finally checkout it (no more 'pseudo' branch).
It saves bandwith and significantly speeds up the feed update process.
apk: backport patch fixing broken apk update with wget fetch
APK update is currently broken if wget is used as a tool. This wasn't
correctly tested and cause seg fault. Backport the patch fixing this to
restore original functionality.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
George Moussalem [Thu, 13 Feb 2025 05:54:44 +0000 (09:54 +0400)]
qualcommax: ipq50xx: Add support for Linksys MR5500
Add support for Linksys MR5500 (Hydra 6 Pro).
Speficiations:
* SoC: Qualcomm IPQ5018 (64-bit dual-core ARM Cortex-A53 @ 1.0Ghz)
* Memory: Kingston D2516ECMDXGJD (512 MiB)
* Serial Port: 3v3 TTL 115200n8
* Wi-Fi: IPQ5018 (2x2 2.4 Ghz 802.11b/g/n/ax)
QCN9024 (4x4:4 5 Ghz 802.11an/ac/ax)
* Ethernet: IPQ5018 integrated virtual switch connected to an external
QCA8337 switch (4 Ports 10/100/1000 GBASE-T)
* Flash: Gigadevice GD5F2GQ5REYIH (256 MiB)
* LEDs: 1x multi-color PWM LED
1x blue led for USB (GPIO 19 Active High)
* Buttons: 1x WPS (GPIO 27 Active Low)
1x Reset (GPIO 28 Acive Low)
5x ethernet port LEDs (amber for activity & green for link up)
* Peripherals: 1x USB2 (powered by GPIO 17 Active Low)
support for USB3 will be added in a separate PR
* FCC ID: 2AYRA-03734
Flash instructions:
1. On OEM firmware, login to the device (typically at http://192.168.1.1) and click 'CA'
in the bottom right corner -> Connectivity -> Manual Upgrade. Alternatively, browse to
http://<router IP>/fwupdate.html.
Upgrade firmware using openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin image.
Optionally install on second partition, after first boot check actual partition:
fw_printenv -n boot_part
and install firmware on second partition using command in case of 2:
mtd -r -e kernel -n write openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin kernel
and in case of 1:
mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin alt_kernel
2. Installation using serial connection from OEM firmware (default login: root, password: admin):
fw_printenv -n boot_part
In case of 2:
flash_erase /dev/mtd12 0 0
nandwrite -p /dev/mtd12 openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin
or in case of 1:
flash_erase /dev/mtd14 0 0
nandwrite -p /dev/mtd14 openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin
After first boot install firmware on second partition:
mtd -r -e kernel -n write openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin kernel
or:
mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq50xx-linksys_mr5500-squashfs-factory.bin alt_kernel
3. Back to the OEM firmware.
Download firmware from OEM website:
MR5500: https://support.linksys.com/kb/article/207-en/
From serial or SSH:
fw_printenv boot_part
in case of 1:
mtd -r -e alt_kernel -n write FW_MR5500_1.1.2.209598_prod.img alt_kernel
else in case of 2:
mtd -r -e kernel -n write FW_MR5500_1.1.2.209598_prod.img kernel
4. Boot from USB
This allows you loading an OpenWrt image into RAM and is meant for recovery scenarios only.
Enable loading image from USB in u-boot. From serial or SSH:
fw_setenv bootusb 'usb start && usbboot &loadaddr && bootm $loadaddr'
fw_setenv bootcmd 'run bootusb; if test $auto_recovery = no; then bootipq; elif test $boot_part = 1; then run bootpart1; else run bootpart2; fi'
Copy OpenWrt initramfs image to USB:
dd bs=1M if=openwrt-qualcommax-ipq50xx-linksys_mr5500-initramfs-uImage.itb of=/dev/sda
Felix Fietkau [Fri, 28 Feb 2025 15:27:36 +0000 (16:27 +0100)]
unetd: update to Git HEAD (2025-02-28)
75a236be122a service: add missing null pointer check f5341f327539 ubus: add api for generating and validating security tokens 3fab99eab4d5 add udebug support 28d86bd30e97 pex: only respond to update requests when we have network data 8e6f37cc361e pex-msg: ignore no-data responses if version is zero 12e6cf7f63e1 pex: create pex host from update responses edc8fdae463a ubus: show the local addresses in network status
Robert Marko [Thu, 27 Feb 2025 10:05:26 +0000 (11:05 +0100)]
libpcap: add missing PKG_CONFIG_DEPENDS entries
Currently, enabling USB, BT or Netfilter support after initial compilation
will not trigger a rebuild, so add the missing PKG_CONFIG_DEPENDS so
that rebuild gets triggered.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Bjørn Mork [Wed, 12 Feb 2025 07:56:48 +0000 (08:56 +0100)]
realtek: rtl930x: sgmii support
This makes sgmii work for 1000Base-T SFPs by stupidly adding the sgmii mode
wherever 1000base-x is accepted. No intelligence has been used in the
process. But it "works for me".
There is an obvious need for refactoring this code to make it more obvious
how and why we configure the mac/phy link like we do for different modes.
Bjørn Mork [Thu, 6 Feb 2025 16:51:48 +0000 (17:51 +0100)]
realtek: rtl93xx: support SFPs with phys
This driver use "phy-handle" as a placeholder for mac configuration
data. Such handles are therefore required for all ports - even those
connected directly to SFP slots and having a managed property set to
"in-band-status".
The DSA core will register these nodes as if they are real phys. This
prevents later attachment of pluggable phys with errors like
sfp sfp-p8: sfp_add_phy failed: -EBUSY
Replace the virtual SFP slot handles with "pseudo-phy-handle" to keep
the driver logic as-is but hide the node from the DSA core.
Bjørn Mork [Wed, 5 Feb 2025 06:19:10 +0000 (07:19 +0100)]
realtek: i2c-rtl9300: fix crash on block transfers
Fix a typo which resulted in wrong .read hooks and unset .write
hooks. This made I2C_SMBUS_BLOCK_DATA transfers dereference the
NULL .write hook and Oops.
Bjørn Mork [Tue, 4 Feb 2025 07:43:58 +0000 (08:43 +0100)]
realtek: dsa: silence debug log noise
The log noise emmitted by this driver is overwhelming, even for developers
looking at specific issues. Demoting to debug allows individual messages
to be dynamically enabled instead.
Bjørn Mork [Wed, 5 Feb 2025 06:27:02 +0000 (07:27 +0100)]
realtek: dsa: silence log noise on route offload
Adding a static IPv4 route made the driver repeatedly print
rtl83xx_l3_nexthop_update: Setting up fwding: ip 192.168.1.42, GW mac 0000001b21a7xxxx
Route with id 3 to 192.168.99.0 / 24
rtl83xx_l3_nexthop_update: total packets: 0
Warning: TEMPLATE_FIELD_RANGE_CHK: not configured
These messages are only useful to developers while debugging offloading.
Demote to debug level, which in general is more useful for developers
by allowing precise dynamic control.
LuaJIT support that is included in 2024.10.16 was supposed to be optional
but unfortunately, it seems that there is a bug[1] and its now breaking FRR
host builds and more.
projects / thirdparty / openwrt.git / log
