OpenWrt 23.05.2 - Service Release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 23.05 stable series. It improves device support and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=23.05.2 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.2/targets/ Main changes between OpenWrt 23.05.0 and OpenWrt 23.05.2 23.05.1 was tagged, but not official release because we found a severe bug between tagging and announcing the release. Device support == * Support for the following devices was added: * bcm53xx: ASUS RT-AC3100 * mediatek: CMCC RAX3000M * mediatek: MT7981 RFB * ramips: ComFast CF-E390AX * ramips: ComFast CF-EW72 V2 * ramips: MeiG SLT866 4G CPE * realtek: HPE 1920-8g-poe+ (65W) * apm821xx: Netgear WNDR4700: Fix broken sysupgrade, factory images * armsr: Preserve configuration during sysupgrade * ath79: Compex wpj563: Enable 2nd USB controller * ath79: TP-Link Archer C7 v2: Fix wifi shutdown and "irq 23: nobody cared" error * bcm53xx: Make Linux use correct switch ports again * bcm53xx: Linksys EA9200: nvram and 02_network fixes * ipq40xx: Switch to performance governor by default * lantiq: xrx200: Build target again * mediatek: Xiaomi Redmi Router AX6000: Fix Ethernet in U-Boot * realtek: HPE 1920-8g-poe: Rename to match hardware * ramips: HiWiFi HC5861: Fix Gigabit Ethernet port * ramips: ZyXEL NR7101: Fix bricking typo Various fixes and improvements == * Fix assignment of default MAC addresses on some targets * build: Hide kmod-zram config unless enabled * build: Fix lto build * build: Fix glibc build * build: Fix pkg-config detection when inside of a nix-shell * build: Add CycloneDX SBOM JSON support * hostapd: Do not trim trailing whitespace, except for newline * hostapd: Fix OWE association with mbedtls * hostapd: Fix broken WPS on broadcom-wl and ath11k * hostapd: Fix broken noscan option * wifi: Fix applying mesh parameters when wpa_supplicant is in use * iptables: backport patch fixing bug with string module * mbedtls: Activate secp521r1 curve by default * px5g-mbedtls: Fix permission of private key * px5g-wolfssl: Fix permission of private key * netifd: Fixed race condition in default gateway configuration Core components update == * Update mbedtls from 2.28.4 to 2.28.5 * Update openssl from 3.0.11 to 3.0.12 * Update wolfssl from 5.6.3 to 5.6.4 * Update Linux from 5.15.134 to 5.15.137 * Update ipq-wifi from 2023-06-03 to 2023-11-10 * Update uqmi from 2022-05-04 to 2022-10-20 * Update umdns from 2023-01-16 to 2023-10-19 * Update urngd from 2023-07-25 to 2023-11-01 * Update ucode from 2023-06-06 to 2023-11-07 * Update firewall4 from 2023-03-23 to 2023-09-01 * Update odhcpd from 2023-06-24 to 2023-10-24 * Update netifd from 2023-10-20 to 2023-11-10 Upgrading to 23.05.2 Sysupgrade can be used to upgrade a device from 22.03 to 23.05, and configuration will be preserved in most cases. * Sysupgrade from 21.02 to 23.05 is not officially supported. * ipq40xx EA6350v3, EA8300, MR8300 and WHW01 require tweak to the U-Boot environment on update from 22.03 to 23.05. Refer to the Device wiki or the instruction on sysupgrade on how to do this change. Config needs to be reset on sysupgrade. Known issues * lantiq/xrx200 target shows error messages in DSA switch configuration of the integrated GSWIP switch. (see: https://github.com/openwrt/openwrt/pull/13200) * OpenWrt 23.05.2 was signed with the wrong signing keys. The keys from OpenWrt snapshot were used for OpenWrt 23.05.2 including the release candidates. A later OpenWrt 23.05 service release will use a different key. See up to date information here: https://openwrt.org/releases/23.05/notes-23.05.2#known_issues - Full release notes and upgrade instructions are available at https://openwrt.org/releases/23.05/notes-23.05.2 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.2#known_issues For a detailed list of all changes since 23.05.0, refer to https://openwrt.org/releases/23.05/changelog-23.05.2 To download the 23.05.2 images, navigate to: https://downloads.openwrt.org/releases/23.05.2/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.2 As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters. Have fun! The OpenWrt Community --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important
Re: [PATCH 06/20] kernel: remove drivers marked as modules
On Wed, Nov 15, 2023 at 11:29:23AM +0100, Bjørn Mork wrote: > Elliott Mitchell writes: > > > Previously these would get built, then simply omitted from the > > resultant image. > > A kernel image built with a config symbol set to 'm' is sometimes > deliberately differerent from an image built with the same symbol set > to 'n'. The kernel is sprinkled with IS_ENABLED() or similar open coded > tests. Some of the symbols you are removing are tested. > > Did you verify that all these changes still produce the same kernel > images as before? No, I haven't. I would tend to look at the git log to find out why those were added (no mention would suggest accident), but the git log is rather troublesome for the config files. I'll try to take a look, but right now I'm spending time testing the split of kernel source and kernel build. OpenWRT appears to have quite a number of issues there. If enabling those as modules helps then something is very wrong. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
On Wed, Nov 15, 2023 at 10:36:21AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: > > > I don't know the future, but enabling kernel support is the first step. > > If you wanted to add it to Debian (with working a multi-arch > implementation and organically grown repositories (which aren't > rebuild aside from sourceful uploads or targeted binNMUs), you would > be right - for OpenWrt, no, there really is no need to enable it, > before you have the rest of the x32 subtarget ready to be merged (and > I can't imagine any reason to enable it for the current OpenWrt x86_64 > subtarget at all). So you would be against enabling the kernel support before userspace is ready? Meanwhile everyone else would be against working on userspace without it being enabled in the kernel... That doesn't really work too well. > For OpenWrt, I could imagine only two approaches to this: > - make the x86_64 subtarget x32-only > - add a new x32-only subtarget and leave x86_64 as it is > Neither would really be 'sensible', but the only workable approach > would imho be the later, even if the intention was (I hope not to > witness that) to kill off the old x86_64 target. I agree with this. One comment though, I suspect OpenWRT VM installations will remain below 4GB of memory for quite some time. As such x32 would be a "free" performance boost/memory reduction if upstream sources support x32 (yeah, this is a big if). > So I really don't see any reason to enable x32 for the x86_64 subtarget, > there's nothing to be gained, just major disadvantages. > While I'm not a proponent for a pure-x32 subtarget either (at all), this > would be the only workable approach to introduce it. At a glance it looks like some useful gains for not too much cost. >From my perspective though this isn't a crucial part of my goal. So I'm likely to drop further discussion as this the cost:benefit isn't there. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 06/20] kernel: remove drivers marked as modules
Elliott Mitchell writes: > Previously these would get built, then simply omitted from the > resultant image. A kernel image built with a config symbol set to 'm' is sometimes deliberately differerent from an image built with the same symbol set to 'n'. The kernel is sprinkled with IS_ENABLED() or similar open coded tests. Some of the symbols you are removing are tested. Did you verify that all these changes still produce the same kernel images as before? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 11/11] kernel/x86: enable x32 support for amd64
Hi On 2023-11-14, Elliott Mitchell wrote: > On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-14, Elliott Mitchell wrote: [...] > > What would be the reason for enabling x32? > > There is very little upstream buy-in for x32, when this question came > > up for Debian, it was rejected to be enabled for -among other reasons- > > concerns about the the system call ABI and its security hardening, as > > well as concerns about the long term ABI compatibility (the later of > > which probably not that relevant for OpenWrt, the former however is). > > What I see seems like x32 is still making progress on Debian. I note > musl has a x32 target. While it still isn't a release architecture for > Debian, I could see it becoming one. I wouldn't really consider this to be very likely, if at all, it has become even less likely than it was over a decade ago. > > I do understand that this is a pet peeve among the high-density > > virtualization crowd, but anywhere else, x32 as a concept is dead (and > > never took off in the first place). > > In my view x32 has some substantial use cases. Have you ever seen `ls`, > `rm`, `grep`, `find`, or `test` needing more than 4GB of memory? Any > of these needing that much memory would suggest something was wrong > (or perhaps someone was trying to abuse them in an impressive way). For > quite a number of shell utilities being able to use more than 4GB of > memory is pointless. The counter question would be, does it hurt? Yes, the x32 proponents (mostly from the high-density virtualization crowd and, as Linus called it "extreme benchmarking" environments) will point out that pure-x32 uses slightly less disk space and slightly less RAM than pure64, but we are talking about very little in today's world. > This is speculation, but I suspect there would be substantial value in > having mixed systems where some utilities were x32 and some were amd64. Please point out what exactly those would be, especially in the context of OpenWrt. If you really want to mix x32 and amd64 binaries, you will need a full library set (binary packages - co-installable) for both x32 and x86_64 installed and in RAM - which is completely detrimental to any of the gains promised above. x32 only works, if you have (aside from the kernel itself) a pure-x32 userspace, or your losses in terms of additional disk space and RAM usage outweigh your gains by an order of magnitude. In a general purpose distribution you might ignore that by claiming that 'only' your big database management system (and its dependencies) would have to be a 64 binary (or some other -very isolated, compared to the rest of the running system- big component), but the situation for OpenWrt is different. This kind of mixed userspace would be a nightmare for complexity on the source side - and/or would require Debian-style multiarch support. Neither of which is very likely to succeed for OpenWrt (let alone for opkg). > > *If* (and imho, again purely my own irrelevant opinion, that is a > > big IF) x32 would really be deemed worthwhile for OpenWrt, it still > > doesn't make sense to enable this whole userspace ABI for the x86_64 > > kernel now, before your desired additional patches are available > > (and even then, you'd probably want a dedicated x32 subtarget instead > > of killing off the pure64 target for OpenWrt - something I'd > > personally be even less in favour of). > > Enabling the kernel support is always the first step. How does one test > userspace if the kernel won't even load the executables? In a general purpose distribution one might say that, however even there one would expect quite a lot of testing having happened before enabling a complete new/ additional ABI to userspace (duplicate to the native one), something akin to the semi-official debian-ports infrastructure, used for bootstrapping of new ports or retiring old ones that still have some form of interest. But in this case there is nothing to test in isolation, as there are no x32 binaries compatible with OpenWrt (you could only test inside a non-OpenWrt x32 chroot, but that's barely grounds for enabling x32 in OpenWrt's kernel, just in case; otherwise float emulation would be enabled for mips, to facilitate Debian chroots - spoiler, it's not). In contrast to the changes necessary (buildsystem, image generation, kernel configs, etc.) to test an OpenWrt x32 subtarget, a lazy-man's two-line patch of enabling X86_X32 && X86_X32_ABI would be trivial in comparison to anything of the rest that would be needed. Given that OpenWrt doesn't have any binary compatibility between major versions and needs to get rebuilt in total for each new revision, there is no need to stage- and phase in additions like this, add the new sub-target in its entirety (or not). [...] > On Wed, Nov 15, 2023 at 05:41:54AM +0100, Stefan Lippers-Hollmann wrote: > > On 2023-11-15, Stefan Lippers-Hollmann wrote: > > > What would be the reason for enabling
[PATCH] kernel: drop "mac-address-increment-byte" DT property support
From: Rafał Miłecki
This downstream DT property is not used by any DTS file anymore.
Signed-off-by: Rafał Miłecki
---
...net-add-mac-address-increment-support.patch | 18 --
...683-of_net-add-mac-address-to-of-tree.patch | 2 +-
...et-do-mac-address-increment-only-once.patch | 9 -
...net-add-mac-address-increment-support.patch | 18 --
...683-of_net-add-mac-address-to-of-tree.patch | 2 +-
...et-do-mac-address-increment-only-once.patch | 9 -
6 files changed, 18 insertions(+), 40 deletions(-)
diff --git
a/target/linux/generic/pending-5.15/682-of_net-add-mac-address-increment-support.patch
b/target/linux/generic/pending-5.15/682-of_net-add-mac-address-increment-support.patch
index f6ae9f31f1..73eabf4f37 100644
---
a/target/linux/generic/pending-5.15/682-of_net-add-mac-address-increment-support.patch
+++
b/target/linux/generic/pending-5.15/682-of_net-add-mac-address-increment-support.patch
@@ -20,14 +20,12 @@ Signed-off-by: Ansuel Smith
--- a/net/core/of_net.c
+++ b/net/core/of_net.c
-@@ -119,28 +119,63 @@ static int of_get_mac_addr_nvmem(struct
+@@ -119,10 +119,19 @@ static int of_get_mac_addr_nvmem(struct
* this case, the real MAC is in 'local-mac-address', and 'mac-address' exists
* but is all zeros.
*
+ * DT can tell the system to increment the mac-address after is extracted by
+ * using:
-+ * - mac-address-increment-byte to decide what byte to increase
-+ * (if not defined is increased the last byte)
+ * - mac-address-increment to decide how much to increase. The value WILL
+ * overflow to other bytes if the increment is over 255 or the total
+ * increment will exceed 255 of the current byte.
@@ -38,19 +36,11 @@ Signed-off-by: Ansuel Smith
*/
int of_get_mac_address(struct device_node *np, u8 *addr)
{
-+ u32 inc_idx, mac_inc, mac_val;
++ u32 mac_inc, mac_val;
int ret;
-+ /* Check first if the increment byte is present and valid.
-+ * If not set assume to increment the last byte if found.
-+ */
-+ if (of_property_read_u32(np, "mac-address-increment-byte", _idx))
-+ inc_idx = 5;
-+ if (inc_idx < 3 || inc_idx > 5)
-+ return -EINVAL;
-+
if (!np)
- return -ENODEV;
+@@ -130,17 +139,33 @@ int of_get_mac_address(struct device_nod
ret = of_get_mac_addr(np, "mac-address", addr);
if (!ret)
@@ -75,7 +65,7 @@ Signed-off-by: Ansuel Smith
+ if (!of_property_read_u32(np, "mac-address-increment", _inc)) {
+ /* Convert to a contiguous value */
+ mac_val = (addr[3] << 16) + (addr[4] << 8) + addr[5];
-+ mac_val += mac_inc << 8 * (5-inc_idx);
++ mac_val += mac_inc;
+
+ /* Apply the incremented value handling overflow case */
+ addr[3] = (mac_val >> 16) & 0xff;
diff --git
a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
b/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
index f7ef06a14a..29144ce8b4 100644
---
a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
+++
b/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
@@ -45,7 +45,7 @@ property. This way, the MAC address can be accessed using
procfs.
/**
* of_get_mac_address()
* @np: Caller's Device Node
-@@ -175,6 +196,7 @@ found:
+@@ -165,6 +186,7 @@ found:
addr[5] = (mac_val >> 0) & 0xff;
}
diff --git
a/target/linux/generic/pending-5.15/684-of_net-do-mac-address-increment-only-once.patch
b/target/linux/generic/pending-5.15/684-of_net-do-mac-address-increment-only-once.patch
index 44d88e31a2..c37c451989 100644
---
a/target/linux/generic/pending-5.15/684-of_net-do-mac-address-increment-only-once.patch
+++
b/target/linux/generic/pending-5.15/684-of_net-do-mac-address-increment-only-once.patch
@@ -16,16 +16,15 @@ Signed-off-by: Will Moss
--- a/net/core/of_net.c
+++ b/net/core/of_net.c
-@@ -194,6 +194,12 @@ found:
+@@ -184,6 +184,11 @@ found:
addr[3] = (mac_val >> 16) & 0xff;
addr[4] = (mac_val >> 8) & 0xff;
addr[5] = (mac_val >> 0) & 0xff;
+
-+ /* Remove mac-address-increment and mac-address-increment-byte
-+ * DT property to make sure MAC address would not get
incremented
-+ * more if this function is stared again. */
++ /* Remove mac-address-increment DT property to make sure MAC
++ * address would not get incremented more if this function is
++ * stared again. */
+ of_remove_property(np, of_find_property(np,
"mac-address-increment", NULL));
-+ of_remove_property(np, of_find_property(np,
"mac-address-increment-byte", NULL));
}
of_add_mac_address(np, addr);
diff --git
