Verify and clean up client ID and global DUID config values before use, in
order to prevent DHCP client malfunction and loss of IPv4 and/or IPv6
connectivity.
- Accept common separators in the string (colon, dash, spaces/tabs, lf)
- Ignore invalid values (non-hex or odd-numbered length)
- Log a warning for invalid settings
The fall back mechanism is as follows:
If a (user-configured) network.<ifname>.clientid setting is found invalid,
ignore and fall back to using network.globals.dhcp_default_duid. In case
that's also invalid (e.g. has been tampered with), don't pass a client
ID to updhc/odhcpc. In that case, udhcpc/odhcpc will use their defaults,
which currently is the i/f MAC address resp. the i/f DUID-LL.
Only error handling is introduced, no behavior change for valid settings.
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/23662
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 9ba54d2d9e)
Previously PKG_SOURCE_DATE_EPOCH came from a git log on the OpenWrt
package directory. That fails in shallow feed clones and in the SDK
(no .git), collapsing to the script's mtime and breaking .apk
reproducibility across SDK rebuilds and between buildbot and SDK.
With this comment, PKG_UNPACK generates a version.date file, later used to
determine a reproducible SOURCE_DATE_EPOCH. Since unpack happens after
download, the evaluation of SOURCE_DATE_EPOCH is now lazy, invoking the
`get_source_date_epoch.sh` script on every use.
While at it, drop export of PKG_SOURCE_DATE_EPOCH and clean it from the
ipkg-build script.
Link: https://github.com/openwrt/openwrt/issues/21579
Link: https://github.com/openwrt/openwrt/pull/21587
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23576
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit e36c2946b7)
The mutex file via '/tmp/.config_pending' should prevent the command
'/sbin/wifi config' from being called in the ieee80211 hotplug when loading
the kernel modules [1]. Since the file '/etc/board.json' does not yet exist
and could be incomplete.
The '/etc/board.json' file is modified in the '/sbin/wifi config' script.
This is only generated during the first boot when '/bin/config_generate' is
called.
This whole handling is unclean. Therefore the creation of the default
configuration '/etc/config/network', '/etc/config/system' and
'/etc/board.json' via '/sbin/config_generate' is moved to the preinint
after the rootfile system has been mounted
The advantage now is that on an ieee80211 hotplug event, the
'/etc/board.json' is already present which simplifies the whole thing.
[1] https://github.com/openwrt/openwrt/blob/main/package/network/config/wifi-scripts/files/etc/hotplug.d/ieee80211/10-wifi-detect
Fixes: b993a00b82 ("base-files: fix duplicate wifi radio sections when using phy renaming")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
(cherry picked from commit ca54521988)
The Extreme Networks AP3935's LAN1 port (gmac0/RGMII to AR8035 at MDIO
addr 1) fails to acquire a link if no Ethernet cable is connected at
power-on; the port stays dead even after a cable is later inserted, and
only a network restart recovers it.
The AR803x family enables hibernation mode by default, this setting
overrides it.
Signed-off-by: Grische <github@grische.xyz>
Link: https://github.com/openwrt/openwrt/pull/23208
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 33ed49c948)
In commit d89cb72c23 , a new rootfs type "targz" was introduced, to correctly pack the rootfs AFTER `DEVICE_PACKAGES` installation (unlike the old simple `rootfs.tar.gz`) .
The expected release artifact shall be a single corresponding tar gz release accompanying or relacing the old simple `rootfs.tar.gz`.
However, if one take a look at the v25.12 series release download pages, e.g. [25.12.4/x86/64](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/), one could see that there're now four release artifacts related to rootfs targz:
- [generic-targz-combined-efi.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz)
- [generic-targz-combined.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined.img.gz)
- [generic-targz-rootfs.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz)
- [rootfs.tar.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-rootfs.tar.gz)
It's obvious the new `targz` release actually reuses the same `TARGET_ROOTFS_{TYPE}` handler same as `squashfs`, `ext4` and alike. And the three `generic-targz` img.gz contains the same expected tar gz either as their second partition, or as the whole image. This could be verified by the following script:
```bash
URL_PARENT=https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-
for TYPE in combined-efi combined rootfs; do
curl -L "${URL_PARENT}generic-targz-${TYPE}.img.gz" | gzip -cd > "${TYPE}.img"
done
for TYPE in combined-efi combined; do
INFO=$(sfdisk -d "${TYPE}.img" | sed -n 's/^'"${TYPE}.img"'2 : start= \+\([0-9]\+\), size= \+\([0-9]\+\),.\+.\+$/\1 \2/p')
dd if="${TYPE}.img" of="${TYPE}.tar.gz" bs=512 skip="${INFO%% *}" count="${INFO##* }"
done
cp rootfs.img rootfs.tar.gz
sha256sum combined-efi.tar.gz combined.tar.gz rootfs.tar.gz
file rootfs.tar.gz
```
Output:
```log
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13.12M 100 13.12M 0 0 194.6M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.93M 100 12.93M 0 0 190.9M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7.13M 100 7.13M 0 0 257.6M 0 0
GPT PMBR size mismatch (246304 != 246334) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device.
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.258064 s, 423 MB/s
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.261621 s, 417 MB/s
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined-efi.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 rootfs.tar.gz
rootfs.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 0
```
The checksum of the extracted, actually expected .tar.gz are all same. And if we peek inside its content, it's indeed what we expected:
```
> tar -tzf rootfs.tar.gz
./
./bin/
./bin/ash
./bin/board_detect
./bin/busybox
./bin/cat
./bin/chgrp
./bin/chmod
./bin/chown
./bin/config_generate
./bin/cp
./bin/date
...
```
A disk image with a `tar.gz` as its second partiton doesn't boot anyway and I doubt if there's any mechanic to make it bootable. So `generic-targz-combined-efi.img.gz` and `generic-targz-combined.img.gz` are not needed at all, and `generic-targz-rootfs.img.gz` shall be renamed to have a `tar.gz` suffix instead.
Therefore work around this by skipping creating images for fs `targz` in the general loop, and only create the rootfs.tar.gz later for `targz` "fs"
This affects both the real builder and imagebuilder. I've tested this with multiple imagebuilders.
Tested with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=generic
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
And with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=ripe_atlas-v5
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-sdcard.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
Signed-off-by: Guoxin Pu <pugokushin@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23570
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 246b216df5)
46f373b47f69 tplink-safeloader: add support for TP-Link Archer AX21 v4.6
7324b0ba8e05 tplink-safeloader: fix segfault when partition name is NULL
7593018845d8 asusuimage: Cleanup code and fix typo
caac8b133aca tplink-safeloader: fix soft_ver for Archer AX21
c0d7de851c9a ptgen: fix bug caused by not completely correct reverts
5b6ef84eaa74 ptgen: allow to specify index of gpt entries to be used
467685270cf0 ptgen: add an option to disable stub partition creation
a2c06c39b41b ptgen: add long option support
6a87eaf434cb ptgen: add support for marking multiple partitions as bootable
Fixes: https://github.com/openwrt/firmware-utils/issues/59
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 5f704e8b25)
Currently, sysupgrade will only upgrade the unused slot, however since the
whole dual firmware logic is in the bootscript U-boot will just use the
first bootscript it finds.
So, in a case that you are running slot A it will upgrade slot B, however
that means that slot B will be still booted by the old bootscript that came
with the previous firmware version.
This is an issue if you need to change anything, so lets add a custom
function that upgrades the active bootscript as well after flashing the
slot firmware.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit fb7787803c)
Methode uDPU and eDPU devices are one of the rare ones with a completely
custom image format being used with custom partition table with F2FS.
Instead of converting the boards to dual firmware (A/B style) and further
expand the already convoluted custom scripts, especially considering that
dual firmware conversion is a breaking change anyway, lets convert to using
the generic eMMC sysupgrade based images.
F2FS ZSTD compression is preserved thanks to fstools now supporting its use
on overlays.
Dual firmware support is implemented via U-Boot scripts so no U-Boot
upgrade is required.
Since there is a partition table layout change, eMMC must be wiped and
reflashed with the generated GPT image from OpenWrt initramfs.
Then on each sysupgrade the firmware slot will be altered.
Instructions:
1. Boot into OpenWrt initramfs
2. Copy openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img.gz to
the device into /tmp
3. Erase eMMC:
dd if=/dev/zero of=/dev/mmcblk0 bs=1M
4. Extract image
gzip -d /tmp/openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img.gz
5. Flash image
dd if=/tmp/openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img of=/dev/mmcblk0
6. Reboot
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit ada2753d6a)
7df188543e26 libfstools: enable f2fs overlay compression formatting
16718b6e3c0f libfstools: mount f2fs overlay with zstd compression
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 417df7debf)
1bf2d490484e libfstools: make get_var_from_file() reusable
0b6022439cad mount_root: add kernel parameter to specify the overlay storage name
e600d842ce81 mount_root: add kernel parameter to specify the overlay fileystem type
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit 920a382cb6)
Reuse Device/FitImage recipe instead of open coding it and
drop duplicate KERNEL_INITRAMFS recipe for eDPU.
While at it, lets clean up the boot script to drop uneeded console
setting, earlycon etc.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit f2a532ec09)
Move the Device/FitImage recipe to the generic image Makefile to avoid
duplicating it for other subtargets.
Will be used for uDPU/eDPU.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
(cherry picked from commit f03bb44a08)
he_phy_cap and he_mac_cap in phy_capabilities are only populated inside
the iftype_data loop. On 6GHz-only radios (e.g. QCN9074/ath11k_pci),
when capability bytes are unavailable they remain null, causing null
dereferences in device_htmode_append():
Reference error: left-hand side expression is null
if (!(he_phy_cap[3] & 0x80))
Initialise both to [] before the loop and guard the consumer side with
?? [] so bitwise checks conservatively disable beamformer/beamformee/twt
features rather than crashing.
Link: https://github.com/openwrt/openwrt/issues/23488
Signed-off-by: dastarothx <darkastalier@gmail.com>
(cherry picked from commit feca0b4507b9175b95a59701462d550eb0b855c0)
Link: https://github.com/openwrt/openwrt/pull/23503
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Airoha reported some bug in the TX/RX descriptor handling and PPE. Backport
the fix for such bug merged in net staging tree.
It's expected that these patch will be dropped in future minor kernel
version when submitted to stable staging tree.
All affected patch automatically refreshed.
(cherry picked from commit 1b9922d5e8)
Link: https://github.com/openwrt/openwrt/pull/23151
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix a long standing bug in the mediatek-cci-devfreq driver which leads
to the driver switching off the CPU power regulator in case of another
resource not being ready in time -- a classic probe-order race condition.
As a work-around it would of course just as well be possible to set the
CPU regulator as 'regulator-always-on' (and not just 'regulator-boot-on'),
but practically all MT7988 devices have copy&pasted the PMIC device tree
hunk which sets only 'regulator-boot-on').
Hence, in order not having to fix all device trees, a proper fix in the
driver is preferred.
Fixes: #683
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit a45ce4c788)
For the backport to U-boot 2025.10, the ethernet driver
(airoha_eth) supports an7581 however it is not declared
in the dtsi. Add the ethernet node for the built in
airoha ethernet controller.
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
Link: https://github.com/openwrt/openwrt/pull/22294
Signed-off-by: Robert Marko <robimarko@gmail.com>
The vendor firmware checks for a bmt header in the last 528 erase blocks
of flash. The OpenWrt partition table did not respect that requirement,
and therefore the vendor and openwrt chainloader fight over those blocks
on every boot, potentially corrupting data stored in UBI blocks there.
This commit increases the size of the reserved_bmt partition to avoid
that fight.
Although the vendor bootloader only seems to touch the final 250 erase
blocks[1], the original vendor firmware system partition ended at
0x1be00000[2], so to be conservative, the consensus is to use that as
the end of mtd2 (ubi) partition and leave the last 528 blocks for mtd3
(reserved_bmt).
From https://openwrt.org/toh/gemtek/mxf-w1700k:
[1] OEM bootlog: [ 5.324337] bmt pool size: 250
[2] OEM bootlog: [ 5.478927] 0x000008600000-0x00001be00000 : "system"
For the backport to OpenWrt 25.12, the device support has not yet been
committed, so revising the compat_version in this commit is not needed;
and instead will be handled by revising the pending device support
commit.
Reported-by: Loïc Yhuel <loic.yhuel@gmail.com>
Signed-off-by: Russell Senior <russell@personaltelco.net>
Link: https://github.com/openwrt/openwrt/pull/23061
(cherry picked from commit ee771d3dd0)
Link: https://github.com/openwrt/openwrt/pull/22294
Signed-off-by: Robert Marko <robimarko@gmail.com>
Due to issues surrounding the implementation of the vendor BMT/BBT
on Airoha, upstream ATF + uboot has switched to UBI flash partitions.
However, some devices shipped on this platform are bootloader locked,
and thus it is impossible to replace ATF + uboot.
During testing for the Gemtek W1700K (#17869), sysupgrades from Linux
(which is unaware of the underlying BMT/BBT) would occasionally write
data into blocks which were remapped by the vendor uboot when it was
read on the following reboot, causing a soft brick.
An acceptable workaround [1],[2] was discussed where an intermediate
uboot would be written by the vendor uboot (which is aware of Airoha
BMT/BBT). This chainloader would then ignore the regions of flash
used by the vendor uboot, and store all relevant data inside of UBI.
UBI would then be used to handle bad block management. As the vendor
ATF + uboot do not read or interact with the UBI region, we would avoid
unwanted remaps from BMT/BBT.
This commit introduces support for building such a chainloader, by
packaging u-boot and DTS into a FIT image; to be flashed like a kernel.
Configuration for the Gemtek W1700K is provided as an example of how the
chainloader is used.
[1] https://github.com/openwrt/openwrt/pull/17869#discussion_r2836066746
[2] https://github.com/openwrt/openwrt/pull/17869#discussion_r2838395671
Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me>
[ move FIP_COMPRESS to Build/Compile, wrap some long lines ]
Link: https://github.com/openwrt/openwrt/pull/22151
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 442e67d31f)
Link: https://github.com/openwrt/openwrt/pull/22294
Signed-off-by: Robert Marko <robimarko@gmail.com>
It was discovered that the internal PHY interrupt are not always connected
and PHY link up/down is not correctly detected.
This is the case of the Nokia Valyrian board that suffer from this problem.
To handle this, drop the internal PHY interrupt property from DTSI and add
it only to the Gemtek W1700K DTS where it was reported to work correctly.
(cherry picked from commit 89d8dc13d0)
[ drop Gemtek W1700K DTS ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
On 25.12.0 the device has not enough free blocks to initialize overlay.
Move the device to tiny target and consume backup with storage
partitions, which were previously unused. This operation will reclaim
~800 KiB of flash memory. OEM used storage partition for configuration,
while backup was used to store copy of U-Boot environment and copy of
calibration data.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit 15342a05bd)
Partially revert 5e3a602def. Unfortunately the ethaddr value in U-Boot
environment is enclosed in double quotes which makes it longer than
ETH_ALEN, thus nvmem returns EINVAL. Switch back to handling the MAC
addresses in user space.
Fixes: 5e3a602def ("ath79: sitecom,wlrx100: use nvmem")
Reviewed-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit a7f5fb4381)
Restore the lost band label.
Fixes: 502ac21e8f ("ipq40xx: drop redundant label with new LED color/function format")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit 873120b4ff)
Currently, moving from a port on one LAN8814 PHY package to another results
in a no traffic flowing on that new port.
It was tracked down to upstream change that fixed the issue that QSGMII
was soft reset on .config_init of each of 4 PHY-s in the package resulting
in a temporary traffic loss until QSGMII resynced.
However, it seems that the QSGMII soft reset timing is crucial and doing
the reset during probe only cause the QSGMII link to become partially
unsynced (Like 2 or 3 lanes are not synced).
So, add an upstream patch[1] to fix this, patch was modified as we
dont have the inband caps currently.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/net/phy/micrel.c?h=next-20260508&id=e027c218c482c6a0ae1948129ccda3b0a2033368
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Hauke Mehrtens
Andy Chiang
Paul Spooren
Zoltan HERPAI
Shiji Yang
John Audia
Sven Eckelmann
Shine
Florian Eckert
Grische
Guoxin Pu
Robert Marko
Robert Marko
dastarothx
Christian Marangi
Andrii Kuiukoff
Daniel Golle
Dirk Buchwalder
Kenneth Kasilag
Russell Senior
Tomasz Maciej Nowak
Hannu Nyman