OpenWrt 23.05.3 - Service Release

[Hauke Mehrtens]

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 including security fixes.


Download firmware images using the OpenWrt Firmware Selector:
  * https://firmware-selector.openwrt.org/?version=23.05.3
Download firmware images directly from our download servers:
  * https://downloads.openwrt.org/releases/23.05.3/targets/

Main changes between OpenWrt 23.05.2 and OpenWrt 23.05.3


Security fixes
==

  * CVE-2023-36328: dropbear: Integer Overflow vulnerability in mp_grow
in libtommath
  * CVE-2023-48795: dropbear: The SSH transport protocol with certain
OpenSSH extensions, found in OpenSSH before 9.6 and other products,
allows remote attackers to bypass integrity checks such that some
packets are omitted
  * CVE-2023-50868: dnsmasq: The Closest Encloser Proof aspect of the
DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows
remote attackers to cause a denial of service (CPU consumption for
SHA-1 computations) via DNSSEC responses in a random subdomain
attack


Device support
==

  *  Support for the following devices was added:
 * ath79: UniFi UK-Ultra
 * mediatek: Acelink EW-7886CAX
 * mediatek: ASUS RT-AX59U
 * mediatek: ASUS TUF AX6000
 * mediatek: Buffalo WSR-3200AX4S
 * mediatek: Cetron CT3003
 * mediatek: Confiabits MT7981
 * mediatek: Cudy RE3000 v1
 * mediatek: D-Link EAGLE PRO AI M32
 * mediatek: GL.iNet GL-MT6000
 * mediatek: JCG Q30 PRO
 * mediatek: Routerich AX3000
 * mediatek: TP-Link EAP225v5
 * mediatek: Ubiquiti UniFi 6 Plus
 * mediatek: Zbtlink ZBT-Z8102AX
 * mediatek: ZyXEL EX5700 (Telenor)
 * ramips: Cudy WR1300 v3
 * ramips: D-Link COVR-X1860 A1
 * ramips: Rostelecom RT-FE-1A
 * ramips: Rostelecom RT-FL-1 (Serсomm RT-FL-1)
 * ramips: Rostelecom S1010 (Serсomm S1010.RT)
 * ramips: TP-Link EX220 v1
 * ramips: YunCore G720
 * ramips: Z-ROUTER ZR-2660
  * ath79: Nanostation Loco M5 XW: Fix read only jffs2 partition
  * ath79: TP-Link TL-WDR3600 and TL-WDR4300: Fix spurious reboot hangs
  * ath79: ubnt-bullet-m-xw: fix Ethernet PHY traffic
  * ipq807x: edgecore EAP102: fix lan/wan
  * kirkwood: Ctera C200 V1: fix ubi part name
  * lantiq: xway: disable SMP: fix boot on some Danube boards and NAT
performance
  * mediatek: MT7981/MT7986: fix Ethernet rx hang issue
  * meidatek: Mercusys MR90X v1: fix eeprom loading
  * mpc85xx: Extreme Networks WS-AP3825i: increase available RAM
  * mvebu: IEI-World Puzzle M90x: fix RTC
  * ramips: improve mtk_eth_soc resets
  * ramips: rt305x: Use default uart in lzma-loader
  * ramips: Sercomm NA502: Fix bootup problem
  * ramips: Unielec u7621-01: Correct the PCIe port number
  * realtek: d-link dgs-1210-10p: improve sfp support
  * realtek: Netgear GS110TPP: fix OEM install
  * rockchip: Orange Pi R1 Plus LTS: improve Ethernet stability


Various fixes and improvements
==

  * mt76: Add mt7922 firmware
  * mwlwifi: Add support for WPA3
  * dropbear: Increase scp transfer speed
  * kernel: fix bridge proxyarp issue with some broken DHCP clients
  * mac80211: fix min_tx_power setting
  * kernel: add Aquantia PHY firmware loader patches
  * hostapd: fix FILS AKM selection with EAP-192
  * hostapd: fix 11r defaults when using SAE
  * hostapd: fix 11r defaults when using WPA
  * hostapd: ACS: Fix typo in bw_40 frequency array on channel 118


Core components update
==

  * Update Linux from 5.15.137 to 5.15.150
  * Update mwlwifi from 2023-04-29 to 2023-11-20
  * Update mt76 from 2023-08-14 to 2023-09-11
  * Update netifd from 2023-11-10 to 2024-01-04
  * Update jsonfilter from 2018-02-04 to 2024-01-23
  * Update bcm27xx-gpu-fw from 2022-05-16 to 2024-01-11
  * Update mbedtls from 2.28.5 to 2.28.7
  * Update openssl from 3.0.12 to 3.0.13
  * Update wireless-regdb from 2023.09.01 to 2024.01.23
  * Update intel-microcode from 20230808 to 20240312
  * Update dnsmasq from 2.89 to 2.90


Upgrading to 23.05.3


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.3 was signed with the wrong signing keys. The keys
from OpenWrt snapshot were used for OpenWrt 23.05.3, OpenWrt
23.05.2, 

Re: [PATCH] scripts: create kernel configuration upgrade script

[Elliott Mitchell]

On Sat, Mar 23, 2024 at 07:56:01PM +0100, Stijn Segers wrote:
> 
> Op zondag 3 maart 2024 om 15:24:50 -08:00:00 schreef Elliott Mitchell 
> :
> > Date: Tue, 6 Feb 2024 17:16:41 -0800
> > 
> > Create a script for automating kernel version changes.  This
> > generates a pair of commits which cause history to remain attached to
> > all versioned configuration files.
> > 
> > Crucially this makes `git blame` work without needing
> > --find-copies-harder, which is too slow for routine use.  This also
> > updates *everything*, which greatly simplifies rebasing patches
> > which effect multiple devices.
> > 
> > Credit to Christian Marangi who knew of the technique:
> > 
> > 
> > Signed-off-by: Elliott Mitchell 
> 
> 
> Is there a way to bump a specific target to a new kernel with your 
> script? It doesn't look like it, but I might be mistaken. Would it be a 
> lot of work to integrate that? With the shell equivalent being merged, 
> I can understand any reluctance to adding this functionality, but it's 
> worth asking.

As originally written, no.  I see significant advantages to that approach
and it really is starting to look like the best balance.

To add the ability to handle a single target, near trivial.  To add the
ability to do multiple target(s), very simple.  To do this efficiently,
still fairly simple.

It does seem this list has become useless for patch submission, so it has
been brought onto GitHub:

https://github.com/openwrt/openwrt/pull/14907


-- 
(\___(\___(\__  --=> 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

[sdwalker/sdwalker.github.io] b18f65: This week's update

[Stephen Walker via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: b18f65e421bfe651cf8db3531beca1e8a7eeb61d
  
https://github.com/sdwalker/sdwalker.github.io/commit/b18f65e421bfe651cf8db3531beca1e8a7eeb61d
  Author: Stephen Walker 
  Date:   2024-03-24 (Sun, 24 Mar 2024)

  Changed paths:
M uscan/index-22.03.html
M uscan/index-23.05.html
M uscan/index.html

  Log Message:
  ---
  This week's update



To unsubscribe from these emails, change your notification settings at 
https://github.com/sdwalker/sdwalker.github.io/settings/notifications

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] scripts: create kernel configuration upgrade script

[Stijn Segers]

Hi Elliott,

Op zondag 3 maart 2024 om 15:24:50 -08:00:00 schreef Elliott Mitchell 
:

Date: Tue, 6 Feb 2024 17:16:41 -0800

Create a script for automating kernel version changes.  This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.

Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use.  This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.

Credit to Christian Marangi who knew of the technique:


Signed-off-by: Elliott Mitchell 



Is there a way to bump a specific target to a new kernel with your 
script? It doesn't look like it, but I might be mistaken. Would it be a 
lot of work to integrate that? With the shell equivalent being merged, 
I can understand any reluctance to adding this functionality, but it's 
worth asking.


Thanks

Stijn



---
v3:
Dust off knowledge of PerlOO.  Confine the fast-importer interface
to an object.

Better layer the lowest I/O layer.  If fast-import grows a \0 command
separation mode, we should be mostly ready (issue will be the commit
message).

Switch to SPDX.  Try to match what the other scripts have.

I was kind of hoping for more review activity, the near-silence is
almost deafening.  Using a script to handle this job seems best.  I
feel what this script produces is rather easier for most developers
to handle.

v2:
Major tweaking.  No longer try to do `git merge --ff-only `,
but instead advise user to do so.

Add usage message.

Add statement about strategy.

Adjust commit messages.  Add advice to run `git bisect skip` if
someone ends up on that commit.
---
 scripts/kernel_upgrade.pl | 280 
++

 1 file changed, 280 insertions(+)
 create mode 100755 scripts/kernel_upgrade.pl

diff --git a/scripts/kernel_upgrade.pl b/scripts/kernel_upgrade.pl
new file mode 100755
index 00..c2e5fb6078
--- /dev/null
+++ b/scripts/kernel_upgrade.pl
@@ -0,0 +1,280 @@
+#!/usr/bin/env perl
+#
+# SPDX-License-Identifier: GPL-3.0-or-later#
+#  #
+# Copyright (C) 2024 Elliott Mitchell  #
+#
+
+use warnings;
+use strict;
+
+#
+# I'm not certain the technique originated here, but this comes from:
+# 
+#
+# Problem is copying a file in git causes the new file to be created
+# without any history.  Files can move around without losing their
+# history, but that only leaves the history on the new location.
+#
+# As such this can be solved with two commits.  The first commit 
moves

+# files from their old name to their new name.  The second merges the
+# original commit with the rename commit.  The merge commit then has
+# files in both locations with the full history.
+#
+#
+# Note, git handles discarded data by garbage collection.  When doing
+# development on this script, beware this script is an excellent
+# garbage generator.  Frequent use of `git gc` and `git prune` may be
+# needed.
+#
+
+
+sub gethead()
+{
+   open(my $fd, '-|', 'git', 'rev-parse', 'HEAD');
+   $_=<$fd>;
+   chop;
+   return $_;
+}
+
+sub getlist($$)
+{
+   my ($target, $from)=@_;
+   my $ret=[];
+
+   local $/="\0";
+	open(my $fd, '-| :raw :bytes', 'git', 'ls-tree', '-trz', 
'--full-name',
+'--name-only', 'HEAD', '--', $target)||die("failed to read git 
tree");

+
+   while(<$fd>) {
+   chop($_);
+   push(@$ret, substr($_, 0, -length($from)))
+if(substr($_, -length($from)) eq $from);
+   }
+
+   @$ret=sort({length($b)-length($a)} @$ret);
+
+   return $ret;
+}
+
+{ # start of interface to git fast-import
+package GitImporter;
+
+# git fast-import's protocol uses *linefeeds*
+local $/="\n";
+
+sub new()
+{
+   my $class=shift;
+   my $self={};
+   my @child;
+   (pipe($child[0], $self->{out})&($self->{in}, $child[1])) ||
+die("pipe() failed");
+   binmode($self->{out});
+   binmode($self->{in});
+
+   $self->{pid}=fork();
+   if($self->{pid}==0) {
+   close($self->{out});
+   close($self->{in});
+
+   open(STDIN, '<&', $child[0]);
+   close($child[0]);
+
+   open(STDOUT, '>&', $child[1]);
+   close($child[1]);
+
+   exec('git', 'fast-import', '--done');
+   die('exec() of git failed');
+   } elsif(!$self->{pid}) {
+   die('fork() failed');
+   }
+   close($child[0]);
+   close($child[1]);
+   $self->{out}->autoflush(1);
+
+   return bless($self, $class);
+}
+
+sub send($)
+{
+   my $self=shift;
+  

Re: Purpose of openwrt-devel?

[Olliver Schinagl]

On 24-03-2024 06:35, Elliott Mitchell wrote:

On Sat, Mar 23, 2024 at 10:02:39PM +0100, Olliver Schinagl wrote:

On 23-03-2024 18:51, Elliott Mitchell wrote:

On Sat, Mar 23, 2024 at 03:15:44AM +0100, Olliver Schinagl wrote:


Odd thing about what you put in parentheses.  I've been trying to get a
discussion going about that for months, yet seems no one notices the
suggestion.  This was a distinct goal of the script, to hopefully get
that discussion going.


To update all targets at once? How is that useful?!


Taking the unusual step of splitting a paragraph since that is needed
in this case.

I've cited two specific reasons in a recent message.  I keep citing those
reasons again and again and again.  Yet get no response.

This makes it *much* easier to change defaults in "generic".  Instead of
needing to touch a bunch of configurations with different versions, you
can simply touch all configurations with one version.  If you're unlucky
and a new kernel cycle starts before approval or rejection, you can
rebase one copy onto the rename commit and another onto the merge commit.
You then rebase these on top of each other and then squash, the result is
you're onto the latest with minimal trouble.  Without this trying to
modify values effecting multiple devices is an absolute nightmare
(believe me, I know!).


Hmm, afaik this is what openwrt does right now, the generic config is
applied to all targets, and you put your device specific configuration
in your platform config. This makes sense, because you don't want to
compile all drivers for all targets into your tiny router image, that is
restricted to 4MiB.

So if there's something I'm missing, I do appologize :)


Uh huh.  If we were playing horseshoes with thermonuclear handgrenades,
that response would get 0 points.  You completely missed the point.


Let me add another advantage of doing everything at once.  The generated
commits do not properly rebase.  Rebasing retains much of the advantage,
but degrades things.


But we neve rebase master? So this would only affect the local changes 
for the developer? I do admit 'rebasing the local tree to get the latest 
status' is something needed for sure ... I'll check what happens if I do 
that as I'm curious how and what breaks.




As such doing all the duplication in one event allows someone who can
directly commit do the task for everyone *once* per update cycle
(presently once per year).  Device maintainers can then base off of that
point and not worry about having non-rebasable commits.



Then there are the things `kernel_upgrade.pl` can do which
`kernel_bump.sh` has no equivalent.


But what are they. And how are they relevant?


You've been typing about how yours could upgrade everything by being
called multiple times.  Since I was aiming to get the above issue
discussed `scripts/kernel_upgrade.pl` has featured the capability to
update everything all at once, from the start.


The kitchen sink :) But honestly, have that discussion first with the
maintainers. Hauke is already much against it; which I get. Having
worked on a few targets, they are so diverse, bumping two at once just
doesn't make sense (today!).


I will not fully type up my viewpoint.  Bisecting inherently involves
heuristics.  There may be an even number of changes between any two
points, so bisecting involves arbitrarily choosing from a set.  The
`git bisect skip` command exists because it *cannot* be perfect.

Meanwhile --find-copies-harder is sufficiently slow to call `git blame`
effectively broken on OpenWRT.  It is too slow to be used for most of its
intended use cases.



In fact only upgrading a single board was a feature which had to be
added.  Since I added fewer assumptions, mine makes no distinction
between upgrading targets versus subtargets.  It can do multiple of both
at the same time without any restrictions and a single invocation.

In the process, only 2 commits are generated.  The under .5s is for
updating *everything*.


I have no idea how long it would take to update everything, but again,
the time factor is so irrelevant, it doesn't atter. Also, I too only
have 2 commits now, which until we get `git cp` will remain the minimum,
but more then a 'cp && git add'.


I haven't tested, but isn't that simply abandoning the approach of
having history on everything and resorting to only having history on the
up to date version?

I did think that was a viable approach, but it isn't what seemed to gain
concensus.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel