OpenWrt 23.05.0-rc4 - Fourth Release Candidate
Hi, The OpenWrt community is proud to announce the fourth release candidate of the upcoming OpenWrt 23.05 stable series. OpenWrt 23.05.0-rc4 incorporates over 4200 commits since branching the previous OpenWrt 22.03 release and has been under development for over one year. This is just a release candidate and not the final release yet. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=23.05.0-rc4 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.0-rc4/targets/ Changes between OpenWrt 23.05.0-rc3 and 23.05.0-rc4 === Changes in this release candidate since the previous 23.05.0-rc3 release candidate are: * New devices * ipq4019: ZTE MF287 Pro aka DreiNeo Pro * mediatek: Ubiquiti UniFi 6 LR v3 * ramips: ALFA Network AX1800RM * Updated components: * kernel: Update from 5.15.127 to 5.15.132 * mt76: Updated from 2023-07-26 to 2023-08-14 * hostapd: Update from 2023-06-22 to 2023-09-08 * ucode: Update from 2023-04-03 to 2023-06-06 * ubus: Update from 2022-06-15 to 2023-06-05 * netifd: Update from 2023-06-04 to 2023-09-19 * wireless-regdb: update from 2023.05.03 to 2023.09.01 * openssl: Update from 3.0.10 to 3.0.11 * mediatek: lots of backports from master * ipq806x: Fix traffic speed regression * mac80211: rework MT7620 PA/LNA RF calibration * kernel: enable vfio and vfio-pci for armsr-armv8 * ath11k: Revert back ath11k firmware to fix IPv6 multicast problems * kernel: allow adding devices without hw offload to a hw flowtable * kernel: backport support for renaming netdevs while up * hostapd: backport from master, including ucode based reload support * packages: Add many PKG_CPE_ID attributes Many other changes in all parts of OpenWrt, see Changelog for details. Highlights in OpenWrt 23.05.0: == Many new devices added == OpenWrt 23.05 supports over 1794 devices. Support for over 200 new devices was added in addition to the device support by OpenWrt 22.03. * The ipq807x target for the Qualcomm IPQ807x Wifi 6 SoCs was added * The mediatek/filogic subtarget for the Mediatek Filogic 830 and 630 SoCs was added * The sifiveu target for the HiFive RISC-V Unleashed and Unmatched boards Highlights of device support * Switched ipq40xx target to DSA * VDSL support on AVM FRITZ!Box 7530 * Support for devices with 2.5G PHYs * Acer Predator W6 (MT7986A) * Mercusys MR90X v1 (MT7986BLA) * Netgear WAX206 (MT7622) * Netgear WAX220 (MT7986) * ZyXEL NWA50AX Pro (MT7981) * Asus (TUF Gaming) AX4200 (MT7986A) * Netgear WAX218 (IPQ8074) * Xiaomi AX9000 (IPQ8074) * Dynalink DL-WRX36 (IPQ8074) * 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices * Improved DSL statistics on ubus and in LuCI Switch from wolfssl to mbedtls as default = OpenWrt switched the default cryptographic library from wolfssl to mbedtls. This library is used for HTTPS/TLS in the Webserver providing LuCI and for the cryptographic operations in hostapd. mbedtls provides security updates in their LTS branch without changing the application binary interface (ABI) of the library. wolfssl provides a stable ABI only for a very limited subset of functions. mbedtls allows us to update only mbedtls without the need to recompile and upgrade all users of mbedtls. Core components update == Core components have the following versions in 23.05.0-rc4: * Updated toolchain: * musl libc 1.2.4 * glibc 2.37 * gcc 12.3.0 * binutils 2.40 * Updated Linux kernel * 5.15.132 for all targets * Network: * hostapd master snapshot from September 2023 * dnsmasq 2.89 * dropbear 2022.82 * cfg80211/mac80211 from kernel 6.1.24 * System userland: * busybox 1.36.1 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/23.05/notes-23.05.0-rc4 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.0-rc4#known_issues For a detailed list of all changes since 23.05.0-rc3, refer to https://openwrt.org/releases/23.05/changelog-23.05.0-rc4 To download the 23.05.0-rc4 images, navigate to: https://downloads.openwrt.org/releases/23.05.0-rc4/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.0-rc4 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 announcements:
[PATCH v3] bmips: bcm6368-enetsw: Bump max MTU
The max frame size for this ethernet switch is 1536 bytes, excluding the VLAN headers, which is 1536 - VLAN_ETH_HLEN - VLAN_HLEN = 1536 - 18 - 4 = 1514 not ETH_DATA_LEN + ENETSW_TAG_SIZE = 1500 + 4 + 6 = 1510 as it is right now. The available overhead is needed when using the DSA switch with a cascaded Marvell DSA switch, which is something that exist in real products, in this case the Inteno XG6846. Before this patch (on the lan1 DSA port in this case): dsa_slave_change_mtu: master->max_mtu = 9724, dev->max_mtu = 10218, DSA overhead = 8 dsa_slave_change_mtu: master = extsw, dev = lan1 dsa_slave_change_mtu: master->max_mtu = 1510, dev->max_mtu = 9724, DSA overhead = 6 dsa_slave_change_mtu: master = eth0, dev = extsw dsa_slave_change_mtu new_master_mtu 1514 > mtu_limit 1510 mdio_mux-0.1:00: nonfatal error -34 setting MTU to 1500 on port 0 My added debug prints before the nonfatal error: the first switch from the top is the Marvell switch, the second in the bcm6368-enetsw with its 1510 limit. After this patch the error is gone. OpenWrt adds a VLAN to each port so we get VLAN tags on all frames. So when we ping with ping -s 1472 -M do 192.168.1.220 this first turns into a 1500 byte ICMP package, when it reaches the Marvell switch it adds VLAN_ETH_HLEN + VLAN_HLEN 1500 + 18 + 4 = 1522 and then 6 more bytes for DSA tag ending up with 1528 bytes. Then the Broadcom switch adds another DSA tag of 8 bytes, resulting in 1536 bytes reaching Linux, the maximum. tcpdump (on the target eth0) gives this confirming the suspicion: 00:05:03.678271 AF Unknown (1429722180), length 1532: 0x: 3d93 bcae c56b a83d 8874 02fd 0004 8100 =k.=.t.. 0x0010: dada c000 0fff 0800 4500 05dc E... 0x0020: 4000 4001 b146 c0a8 0189 c0a8 0101 ..@.@..F 0x0030: 0800 1fd0 0068 001f 7231 1b65 .h..r1.e 0x0040: f6ef 0600 1011 1213 1415 1617 0x0050: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 .!"#$%&' 0x0060: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./01234567 0x0070: 3839 3a3b 3c3d 3e3f 4041 4243 4445 4647 89:;<=>?@ABCDEFG 3d93 = First four bytes are the last two bytes of the destination ethernet address I don't know why the first four are missing, but it sure explains why the paket is 1532 bytes and not 1536. bcae c56b a83b = source ethernet address 8874 02fd 0004 = Broadcom enetsw DSA tag 8100 = VLAN 802.1Q header dada c000 0fff 0800 = EDSA tag for the Marvell (outer) switch, 0800 is the ethertype obviously Next follows the contents of the ping packet as it appears if we dump it on the DSA interface such as tcpdump -i lan1 etc, there we get the stripped out packet. At the end 4 bytes of FCS. Tests with larger MTUs have not been successful so this is likely the actual hardware max MTU. Cc: Álvaro Fernández Rojas Cc: Jonas Gorski Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Make a more believable case for the max MTU with tcpdump example. ChangeLog v1->v2: - Do some better research after help on IRC, did some ping tests. --- .../files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c index 321e95dbbb3d..01e4723c176d 100644 --- a/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c +++ b/target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c @@ -22,7 +22,8 @@ #include #include -/* MTU */ +/* The max frame size is 1536 including VLAN headers but excluding the 6 byte DSA tag */ +#define ENETSW_MAX_MTU (1536 - VLAN_ETH_HLEN - VLAN_HLEN) #define ENETSW_TAG_SIZE(6 + VLAN_HLEN) #define ENETSW_MTU_OVERHEAD(VLAN_ETH_HLEN + VLAN_HLEN + \ ENETSW_TAG_SIZE) @@ -1067,7 +1068,7 @@ static int bcm6368_enetsw_probe(struct platform_device *pdev) ndev->netdev_ops = _enetsw_ops; ndev->min_mtu = ETH_ZLEN; ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE; - ndev->max_mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE; + ndev->max_mtu = ENETSW_MAX_MTU; #if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0) netif_napi_add(ndev, >napi, bcm6368_enetsw_poll); #else -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] bmips: bcm6368-enetsw: Bump max MTU
On Mon, Oct 2, 2023 at 12:25 AM Linus Walleij wrote: > Test with ping from host: > > PING 192.168.1.220 (192.168.1.220) 1472(1500) bytes of data. > 1480 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.723 ms > 1480 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.562 ms > 1480 bytes from 192.168.1.220: icmp_seq=3 ttl=64 time=0.555 ms > > When this ping reaches the device, the Marvell switch adds 8 bytes of DSA > overhead, > and the Broadcom enetsw adds 6 bytes, resulting in exactly 1514 bytes which > is what > the switch can handle. No wait this isn't correctly stated. I was too tired. OpenWrt adds a VLAN to each port so we get VLAN tags on all frames. So when I ping with ping -s 1472 -M do 192.168.1.220 (command missing) this first turns into a 1500 byte ICMP package (as seen), when it reaches the Marvell switch it adds VLAN_ETH_HLEN + VLAN_HLEN 1500 + 18 + 4 = 1522 and then 6 more bytes for DSA tag ending up with 1528 bytes. Then the Broadcom switch adds another DSA tag of 8 bytes, resulting in 1536 bytes reaching Linux, the maximum. tcpdump (on the target) gives this confirming the suspicion: 00:05:03.678271 AF Unknown (1429722180), length 1532: 0x: 3d93 bcae c56b a83d 8874 02fd 0004 8100 =k.=.t.. 0x0010: dada c000 0fff 0800 4500 05dc E... 0x0020: 4000 4001 b146 c0a8 0189 c0a8 0101 ..@.@..F 0x0030: 0800 1fd0 0068 001f 7231 1b65 .h..r1.e 0x0040: f6ef 0600 1011 1213 1415 1617 0x0050: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 .!"#$%&' 0x0060: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./01234567 0x0070: 3839 3a3b 3c3d 3e3f 4041 4243 4445 4647 89:;<=>?@ABCDEFG 3d93 = First four bytes are the last two bytes of the destination ethernet address I don't know why the first four are missing, but it sure explains why the paket is 1532 bytes and not 1536. bcae c56b a83b = source ethernet address 8874 02fd 0004 = Broadcom enetsw DSA tag 8100 = VLAN 802.1Q header dada c000 0fff 0800 = EDSA tag for the Marvell (outer) switch, 0800 is the ethertype obviously Next follows the contents of the ping packet as it appears if we dump it on the DSA interface such as tcpdump -i lan1 etc, there we get the stripped out packet. At the end 4 bytes of FCS. I will add this to the commit so it's clear how this works... Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] mac80211: compile kconf with host gcc
On Mon, Oct 2, 2023 at 1:52 PM Christian Marangi wrote: > > On Fri, Sep 29, 2023 at 09:26:48PM -0400, Zeyu Dong wrote: > > Fix the building issue setting CC to KERNEL_CC in kernel.mk. The > > kernel backports by default uses CC to compile kconf. A new patch is > > added to mac80211 to compile kconf with host gcc. > > > > Signed-off-by: Zeyu Dong > > Can you run this under packages/mac80211/refresh ? Thanks for your reminder. This should be the correct way to format a patch. Here is the patch after I run `make package/mac80211/refresh`. Looks like it remains unchanged as V2. --- Fix the building issue setting CC to KERNEL_CC in kernel.mk. The kernel backports by default uses CC to compile kconf. A new patch is added to mac80211 to compile kconf with host gcc. Signed-off-by: Zeyu Dong --- .../build/004-fix-kconf-compiling.patch | 37 +++ 1 file changed, 37 insertions(+) create mode 100644 package/kernel/mac80211/patches/build/004-fix-kconf-compiling.patch diff --git a/package/kernel/mac80211/patches/build/004-fix-kconf-compiling.patch b/package/kernel/mac80211/patches/build/004-fix-kconf-compiling.patch new file mode 100644 index 00..b1036b5310 --- /dev/null +++ b/package/kernel/mac80211/patches/build/004-fix-kconf-compiling.patch @@ -0,0 +1,37 @@ +--- a/Makefile.real b/Makefile.real +@@ -6,6 +6,8 @@ else + export BACKPORTS_GIT_TRACKER_DEF= + endif + ++HOSTCC=gcc ++ + # disable built-in rules for this file + .SUFFIXES: + +@@ -24,21 +26,21 @@ listnewconfig oldaskconfig oldconfig \ + silentoldconfig olddefconfig oldnoconfig \ + allnoconfig allyesconfig allmodconfig \ + alldefconfig randconfig: +- @$(MAKE) -C kconf conf ++ @$(MAKE) -C kconf CC=$(HOSTCC) conf + @./kconf/conf --$@ Kconfig + + .PHONY: usedefconfig + usedefconfig: +- @$(MAKE) -C kconf conf ++ @$(MAKE) -C kconf CC=$(HOSTCC) conf + @./kconf/conf --defconfig=defconfig Kconfig + + .PHONY: savedefconfig + savedefconfig: +- @$(MAKE) -C kconf conf ++ @$(MAKE) -C kconf CC=$(HOSTCC) conf + @./kconf/conf --savedefconfig=defconfig Kconfig + + defconfig-%:: +- @$(MAKE) -C kconf conf ++ @$(MAKE) -C kconf CC=$(HOSTCC) conf + @./kconf/conf --defconfig=defconfigs/$(@:defconfig-%=%) Kconfig + + .config: -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] mac80211: compile kconf with host gcc
On Fri, Sep 29, 2023 at 09:26:48PM -0400, Zeyu Dong wrote: > Fix the building issue setting CC to KERNEL_CC in kernel.mk. The > kernel backports by default uses CC to compile kconf. A new patch is > added to mac80211 to compile kconf with host gcc. > > Signed-off-by: Zeyu Dong Can you run this under packages/mac80211/refresh ? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
