Re: [PATCH 6/7] tegra: enable VDE driver
On 5/15/24 8:05 PM, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak This drives power domain responsible for clean reboot on at least Tegra 2 devices. Signed-off-by: Tomasz Maciej Nowak Hi, Could you explain this change a bit more. My do you deactivate the kmod-video-mem2mem and kmod-video-dma? Do you build it into the kernel and it was not automatically deactivated? Hauke --- package/kernel/linux/modules/video.mk | 4 ++-- target/linux/tegra/config-6.6 | 20 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/package/kernel/linux/modules/video.mk b/package/kernel/linux/modules/video.mk index dc1953279e43..0fae20b7700c 100644 --- a/package/kernel/linux/modules/video.mk +++ b/package/kernel/linux/modules/video.mk @@ -1157,7 +1157,7 @@ define KernelPackage/video-mem2mem SUBMENU:=$(VIDEO_MENU) TITLE:=Memory 2 Memory device support HIDDEN:=1 - DEPENDS:=+kmod-video-videobuf2 + DEPENDS:=@!TARGET_tegra_generic +kmod-video-videobuf2 KCONFIG:= \ CONFIG_V4L_MEM2MEM_DRIVERS=y \ CONFIG_V4L2_MEM2MEM_DEV @@ -1176,7 +1176,7 @@ define KernelPackage/video-dma SUBMENU:=$(VIDEO_MENU) TITLE:=Video DMA support HIDDEN:=1 - DEPENDS:=+kmod-video-videobuf2 + DEPENDS:=@!TARGET_tegra_generic +kmod-video-videobuf2 KCONFIG:= \ CONFIG_VIDEOBUF2_DMA_CONTIG \ CONFIG_VIDEOBUF2_DMA_SG diff --git a/target/linux/tegra/config-6.6 b/target/linux/tegra/config-6.6 index 4326326d3c89..c301dc6f 100644 --- a/target/linux/tegra/config-6.6 +++ b/target/linux/tegra/config-6.6 @@ -298,6 +298,12 @@ CONFIG_LZ4_COMPRESS=y CONFIG_LZ4_DECOMPRESS=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y +CONFIG_MEDIA_CONTROLLER=y +CONFIG_MEDIA_CONTROLLER_REQUEST_API=y +CONFIG_MEDIA_PLATFORM_DRIVERS=y +CONFIG_MEDIA_PLATFORM_SUPPORT=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_SUPPORT_FILTER=y CONFIG_MEMORY=y CONFIG_MEMORY_ISOLATION=y # CONFIG_MFD_ACER_A500_EC is not set @@ -494,6 +500,8 @@ CONFIG_SPI_TEGRA20_SFLASH=y CONFIG_SPI_TEGRA20_SLINK=y # CONFIG_SPI_TEGRA210_QUAD is not set CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y +CONFIG_SRAM=y +CONFIG_SRAM_EXEC=y CONFIG_SWP_EMULATE=y CONFIG_SYNC_FILE=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -544,10 +552,22 @@ CONFIG_USB_ULPI_BUS=y CONFIG_USB_ULPI_VIEWPORT=y # CONFIG_USB_XHCI_TEGRA is not set CONFIG_USE_OF=y +CONFIG_V4L2_H264=y +CONFIG_V4L2_MEM2MEM_DEV=y +CONFIG_V4L_MEM2MEM_DRIVERS=y +CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VFP=y CONFIG_VFPv3=y +CONFIG_VIDEOBUF2_CORE=y +CONFIG_VIDEOBUF2_DMA_CONTIG=y +CONFIG_VIDEOBUF2_DMA_SG=y +CONFIG_VIDEOBUF2_MEMOPS=y +CONFIG_VIDEOBUF2_V4L2=y CONFIG_VIDEO_CMDLINE=y +CONFIG_VIDEO_DEV=y CONFIG_VIDEO_NOMODESET=y +CONFIG_VIDEO_TEGRA_VDE=y +CONFIG_VIDEO_V4L2_I2C=y CONFIG_WATCHDOG_CORE=y # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set CONFIG_XPS=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 23.05.3 - 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 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: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On 2/5/24 11:35, Zoltan HERPAI wrote: On Sat, 3 Feb 2024, Enrico Mioso wrote: On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) wrote: Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic ha scritto: sob., 3 lut 2024 o 13:08 Hauke Mehrtens napisał(a): Hi, I track the status of the Linux kernel 6.1 migration in this github issue: https://github.com/openwrt/openwrt/issues/14546 There are still many targets on kernel 5.15 without testing support for kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get everything to 6.1 and more or less stable. Kernel 6.1 support is also missing for some important targets like lantiq, realtek and ramips. Which kernel should we use for the next major OpenWrt release? We have two options and I would like to get some feedback on these: 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most of the targets are on kernel 6.1 by default. 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt release which supports kernel 6.1. Doing a OpenWrt release with multiple kernels cases too much maintenance effort from my point of view based on previews experience. I think with kernel 6.1 we can branch off at around May 2024. With kernel 6.6 we could probably branch off around September 2024. The final release will be out about 2 to 4 months later. Currently OpenWrt releases are about 1.5 years behind the Linux LTS releases. When we use kernel 6.1 for the next release we will continue to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any release with kernel 6.1 we will probably only stay 10 months behind Linux LTS kernels. There is already a PR requiring kernel 6.6: https://github.com/openwrt/openwrt/pull/14357 Currently I would prefer to use kernel 6.6 to get closer to the recent Linux LTS releases. 6.6 for sure if possible. Just curious - any reason to not support both or even 5.15? And target could decide about it in mk? Eg. newest ATH/QCA that base a lot on newest kernel and backports just could choose it? For older one we already have work done - so just change generic patches directory into generic-kernel_ver? Or this is more work and problems? We usually try to stick to a common kernel across all target for stable release for consistency and to prevent and handle regression in the generic target. Also it's really a way to force target on getting updated... If it wasn't for this reason we would probably have stuff stuck at 4.19. Hello all, I would choose 6.1: to get more time for some things to stabilize out and because I am under the impression the kernel size is growing too fast and so we are accelerating hw obsolescence. The 6.1 kernel has also been choosen by the Civil Infrastructure Platform, so it would get some attention and maintenance still. However, my preference / decision is for 6.6 in the end: especially after having felt the pain of developers who need to backport lots of stuff and for which the challenge becomes harder over time. If we need more developers, making development less annoying is preferrable. That said, it would be nice to enable only the needed kernel features for a subtarget, just to incrase efficiency in general. Hi, I'm kind of biased here too. 6.1 due to CIP and vendors starting to pick 6.1 as their kernel of choice in SDKs, but 6.6 for moving with the targets and new stuff we're working on forward. I do not care much what vendors choose for their SDKs. If you want to consider this you probably have to look what vendors will choose next year when they look for an OpenWrt version and a kernel version. For example prplOS selected OpenWrt 22.03 and kernel 5.15, but OpenWrt 22.03 shipped with kernel 5.10. OpenWrt 23.05 was not stable when they made the decision, but they already selected kernel 5.15. I do not know how good the CIP people are at maintaining a LTS kernel. I do not see them working together with the upstream community. I personally only trust Greg Kroah-Hartman with the help of the full kernel community and RedHat with all their kernel developers on their payroll to be able to maintain a stable LTS kernel. I do not trust any hardware manufacturer to be able to maintain a stable LTS kernel. One thing I fully agree with Hauke is that we should pick one (and only one) kernel for the next release, whenever that is. If we need to drop targets to achieve it (no maintainer stepping up or lack of storage on the devices), so be it. Also: - riscv targets I'm working on are usually better off with 6.6, - we are unable to keep up with a standard release cycle anyway, so no one will tell us off if we delay a release by a few months. I think the biggest efforts in a kernel migration are the generic support and the MIPS targets with many deceives (ath79, ramips, ...). The modern ARM targets
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On 2/3/24 15:31, Paul D wrote: On 2024-02-03 13:06, Hauke Mehrtens wrote: Hi, I track the status of the Linux kernel 6.1 migration in this github issue: https://github.com/openwrt/openwrt/issues/14546 There are still many targets on kernel 5.15 without testing support for kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get everything to 6.1 and more or less stable. Kernel 6.1 support is also missing for some important targets like lantiq, realtek and ramips. Which kernel should we use for the next major OpenWrt release? We have two options and I would like to get some feedback on these: 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most of the targets are on kernel 6.1 by default. 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt release which supports kernel 6.1. Doing a OpenWrt release with multiple kernels cases too much maintenance effort from my point of view based on previews experience. I think with kernel 6.1 we can branch off at around May 2024. With kernel 6.6 we could probably branch off around September 2024. The final release will be out about 2 to 4 months later. Do a release using 6.6 - although from past experience this means no OpenWrt 24. 6.6 likely means carrying fewer patches also. Does this give rise to the potential that some older devices get dropped? Linux kernel 6.6 will probably be 5% to 10% bigger than Linux kernel 6.1 as I have seen it between other LTS kernel versions. Maintenance of kernel 6.6 will be easier because we have to carry less patches and we will be closer to upstream. I expect that using kernel 6.6 will push out the next release by about 4 months. I expect that the first target with kernel 6.6 testing support will be in master in less than 1 month after we decide to use kernel 6.6 for the next release. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
Hi, I track the status of the Linux kernel 6.1 migration in this github issue: https://github.com/openwrt/openwrt/issues/14546 There are still many targets on kernel 5.15 without testing support for kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get everything to 6.1 and more or less stable. Kernel 6.1 support is also missing for some important targets like lantiq, realtek and ramips. Which kernel should we use for the next major OpenWrt release? We have two options and I would like to get some feedback on these: 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most of the targets are on kernel 6.1 by default. 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt release which supports kernel 6.1. Doing a OpenWrt release with multiple kernels cases too much maintenance effort from my point of view based on previews experience. I think with kernel 6.1 we can branch off at around May 2024. With kernel 6.6 we could probably branch off around September 2024. The final release will be out about 2 to 4 months later. Currently OpenWrt releases are about 1.5 years behind the Linux LTS releases. When we use kernel 6.1 for the next release we will continue to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any release with kernel 6.1 we will probably only stay 10 months behind Linux LTS kernels. There is already a PR requiring kernel 6.6: https://github.com/openwrt/openwrt/pull/14357 Currently I would prefer to use kernel 6.6 to get closer to the recent Linux LTS releases. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
On 1/30/24 19:15, Christian Marangi (Ansuel) wrote: Robert is active in OpenWrt since 2017 and with some recent stats, he has more than 310 commits merged in OpenWrt. He also have uncounted Reviewed-by tag on various PR and merged commits and generally helps in everything related to IPQ (ipq806x, ipq40xx and ipq807x) and some mvebu targets. He did the conversion of ipq40xx target to DSA and made possible the introduction of the ipq807x target by sorting all the QSDK downstream patch and pushing them upstream. With his help, also the ipq60xx is very close on getting merged and actually used permitting support of even more device for OpenWrt. Also he is almost always reachable on IRC openwrt-devel and never had a problem in coordinating and collaborating with him. I think Robert is a good addition to our team and would massively help me (Ansuel) in maintaining each IPQ target and review all the related PR on github and patchwork. I would like to add Robert to the OpenWrt committers team. The vote shall be concluded within 14 days. (13/02/2024) +1 When Robert creates a pull request or added a reviewed by to an IPQ* pull request it is normally fine and I will apply it. Thank you Ansel for starting the vote. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Future of the broadcom-wl package?
On 1/26/24 18:45, Felix Fietkau wrote: Hi, does anybody still care about the broadcom-wl package in OpenWrt? I think it would be nice if we could get rid of it, along with the code support and abstraction for different wireless drivers. It would also allow us to rewrite iwinfo in ucode with nl80211 as the only supported API, which helps keep things simple. Would anybody be opposed to declaring 23.05 to be the last release to support broadcom-wl? - Felix +1, I support removing broadcom-wl. We should also do it because it uses a closed source binary we link into the kernel. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One vs. EU Cyber Resilience Act
The EU is working on a EU Cyber Resilience Act to improve the software security of (consumer) software and (consumer) hardware which contains software. This should be similar to the CE sign, but for software. https://en.wikipedia.org/wiki/Cyber_Resilience_Act After the successful lobbying of multiple open source organizations non commercial open source software developer would be exempt from this regulation. As far as I understood the OpenWrt project would not be affected by this regulation, but if a vendor uses OpenWrt on a router, this vendor has to make sure that his product including OpenWrt is compliant when selling onto the EU market. With the OpenWrt One we or Banana Pi could also get required to take care of this regulation. Did someone look into the requirements needed to make OpenWrt compliant to the EU Cyber Resilience Act for a commercial entity? Did someone look into this regulation with the OpenWrt One project in mind? I support the general idea of the EU to improve the security of software. I think the current draft is much better regarding open source than the first versions. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On 12/11/23 09:34, Robert Marko wrote: On Mon, 11 Dec 2023 at 06:55, Varadarajan Narayanan wrote: On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: Hi Robert, Adding John's correct e-mail to the loop. On 8.12.2023 11:02, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: Hi Robert, On 7.12.2023 12:52, Robert Marko wrote: On 07. 12. 2023. 12:20, Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: SoC : QCOM IPQ9574 RAM : 2GB DDR4 Flash : eMMC 8GB WiFi: 1 x 2.4GHz 1 x 5GHz 1 x 6GHz Signed-off-by: Varadarajan Narayanan Without even looking at the code, please split this up as its not reviewable at all currently. Also, I would strongly encourage using Github PR for this. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. Can you kindly guide on what kind of split is acceptable for the community. Thanks Varada Hi, I would at least split the target itself, patches and then the board itself for the start. Would it make sense to rename qualcommax to qualcomm and make ipq95xx just another subtarget of it (I'm aware of A53 vs. A73)? That depends on how much is shared between the AX SoC-s and the BE ones(IPQ95xx and IPQ53xx). I would say enough to keep them together. But, I would prefer that or qualcommbe target where new BE SoC-s will be subtargets. I'm personally more a fan of limiting number of top targets and deal with differences under subtargets. Same here, better than to add more targets especially since a lot is shared. Thanks for your inputs. Shall I rename target/linux/qualcommax/ -> target/linux/ipq/ (1st preference since it is IPQ product family) or target/linux/qualcomm/ and have ipq95xx as subtarget? I would prefer qualcomm and not ipq, and then ipq95xx as subtarget. Hi, It is probably easier if you add ipq95xx support to the existing qualcommax target first and rename it later in a separate step. Every few days something changes in the qualcommax target and if you rename it you probably have to rebase very often. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
On 12/11/23 06:29, Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 08:36:14PM +0800, Chuanhong Guo wrote: Hi! On Thu, Dec 7, 2023 at 7:24 PM Varadarajan Narayanan wrote: On Thu, Dec 07, 2023 at 11:11:03AM +0100, Robert Marko wrote: On 07. 12. 2023. 10:59, Varadarajan Narayanan wrote: SoC : QCOM IPQ9574 RAM : 2GB DDR4 Flash : eMMC 8GB WiFi: 1 x 2.4GHz 1 x 5GHz 1 x 6GHz Signed-off-by: Varadarajan Narayanan Without even looking at the code, please split this up as its not reviewable at all currently. Also, I would strongly encourage using Github PR for this. This patch just has the base SoC/board support and not drivers for WiFi/ethernet/USB etc. An OpenWrt target with only a serial console isn't really useful. It would be better to submit a complete patchset for a working target instead. Is there any plan for upstreaming support for basic functionalities like ethernet and/or WiFi? Yes, there is plan to post those functionalities in the coming weeks. Hi Varada, Could you share your current development tree already even if it is not ready yet. It would be helpful when you also tell us what you plan to change. Then we can already have a look and get a better understanding on how you expect this to look like in the end. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.6 sixth service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=22.03.6 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.6/targets/ OpenWrt 23.03 EOL in April 2024 The OpenWrt 22.03 series will be supported till April 2024 according to the OpenWrt security policy. The last release from the OpenWrt 22.03 series is planned for April 2024, after this date we will not provide any updates for OpenWrt 22.03, not even for severe security problems. We encourage everyone to upgrade to OpenWrt 23.05 which will be supported till 2025. Main changes between OpenWrt 22.03.5 and OpenWrt 22.03.6: Device support == * Support for the following devices was added: * ramips: Cudy X6 v2 * ramips: Keenetic Lite III rev. A * ramips: SNR-CPE-W4N-MT router * ath79: WLR-7100: fix packetloss * ath79: wpj563: enable 2nd USB controller * ath79: TP-Link Archer C7 v2: increase the rfkill debounce interval * bmips: NETGEAR DGND3700v2: fix boot loop * ipq40xx: switch to performance governor by default * ramips: Cudy X6: fixes / improvements Various fixes and improvements == * build: generate index.json * build: fix generation of large .vdi images * lua: fix integer overflow in LNUM patch * dropbear: add ed25519 for failsafe key * treewide: add PKG_CPE_ID to multiple packages * mac80211: fix not set noscan option for wpa_supplicant * hostapd: fix broke noscan option for mesh * hostapd: permit also channel 7 for 2.5GHz to be set to HT40PLUS Core components update == * Update Linux kernel from 5.10.176 to 5.10.201 * Update openssl from 1.1.1t to 1.1.1w * Update wolfssl from 5.5.4 to 5.6.4 * Update mbedtls from 2.28.2 to 2.28.5 * Update mt76 22.03 from 2022-09-06 to 2023-09-11 * Update wireless-regdb from 2023.02.13 to 2023.09.01 * Update linux-firmware from 20220411 to 20230804 * Update intel-microcode from 20220809 to 20230808 * Update ca-certificates from 20211016 to 20230311 * Update uhttpd from 2022-10-31 to 2023-06-25 * Update urngd from 2020-01-21 to 2023-11-01 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.6 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.6#known_issues For a detailed list of all changes since 22.03.5, refer to https://openwrt.org/releases/22.03/changelog-22.03.6 To download the 22.03.6 images, navigate to: https://downloads.openwrt.org/releases/22.03.6/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=22.03.6 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Battlemesh x OpenWrt meeting in Cyprus?
Hi Arınç and Paul, Thank you Arınç for organizing the Battlemesh in Cyprus. I will probably join the Battlemesh again, but I wont have much time to organize stuff. The following dates are currently proposed: May 15 - 19 May 22 - 26 Wednesday - Sunday, 5 days. Everyone who wants to join, please take part in the poll: https://framadate.org/M4I9AYvKYypQTmGB It is hard to get people together. I would suggest to plan an OpenWrt track on the last 2 days of Battlemesh in parallel. Who would like to join? Hauke On 11/25/23 12:59, Arınç ÜNAL wrote: Hello! I am the head organiser of the next Battlemesh. I will also be involved the most on organising the OpenWrt summit. Let me know if you've got any questions. My website from my email address includes the channels other than email to reach me more easily. Arınç On 23 November 2023 23:54:16 EET, Paul Spooren wrote: Hi all, While attending this years Battlemesh in Spain some fellow mesh people asked why there weren’t more OpenWrt people around. I’m guessing it was mostly due to the lack of communication in advance, so I’d like to raise the topic here: Are people from the OpenWrt community, specially members and maintainers interested in collaborating with and attending the Battlemesh next year? They’d do most of the heavy lifting and would offer us to take some slots/space to do our own little OpenWrt meeting (remember the good and productive days in Hamburg anno 2019). Ideally at least one OpenWrt member would join their organizing team, I could do it but would also be happy if someone else jumps in. The general idea is to have a week long Battlemesh event in Cyprus, the OpenWrt part could happen both within the week, before or after, the full length or only a weekend etc. To my knowledge Cyprus offers an easier VISA process so more folks could join, I remember last time people wouldn’t get a VISA in time. If we participate we should raise some donations to offer travel stipends and come up with some (lighting) talks and presentations. I think the timeframe is “somewhen in May 2024”, this will be further discussed on the Battlemesh mailing list. Looking forward to meet you all again! Sunshine, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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 ustream-ssl 1/2] ustream-mbedtls: Add compatibility with Mbed TLS 3.0.0
On 11/12/23 20:16, Rosen Penev wrote: On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote: This adds support for compiling the code against Mbed TLS 3.0.0. It still compiles against Mbed TLS 2.28. The following changes were needed: * DES and 3DES was removed * mbedtls_pk_context->pk_info is private, use mbedtls_pk_get_type() to check if it was initialized * mbedtls_pk_parse_keyfile() now gets a random callback * mbedtls/certs.h contains test data and is not installed any more and not needed. Signed-off-by: Hauke Mehrtens --- ustream-mbedtls.c | 12 +++- ustream-mbedtls.h | 1 - 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c index 7fc7874..1c70cac 100644 --- a/ustream-mbedtls.c +++ b/ustream-mbedtls.c @@ -110,9 +110,15 @@ static const int default_ciphersuites_client[] = AES_CBC_CIPHERS(ECDHE_ECDSA), AES_CBC_CIPHERS(ECDHE_RSA), AES_CBC_CIPHERS(DHE_RSA), +/* Removed in Mbed TLS 3.0.0 */ are these for Windows XP compatibility? No, This is for the TLS client. I assume this is for some legacy embedded webserver. Mbed TLS 3.0.0 also removes support for TLS 1.0 and 1.1, it only support TLS 1.2 and 1.3, this could cause some problems with older equipment and legacy WPA enterprise clients. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH ustream-ssl 2/2] cmake: Fail if undefined symbols are used
Make the linking of the shared library fail when undefined symbols are used. Linking undefined symbols in a shared library normally works and the linking of the binary using the shared library fails. We also compile some example applications and they failed already. Signed-off-by: Hauke Mehrtens --- CMakeLists.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index 2de6590..f4dca0d 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -10,6 +10,7 @@ ENDIF() ADD_DEFINITIONS(-Wno-unused-parameter -Wmissing-declarations) SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "") +SET(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined") IF(MBEDTLS) ADD_DEFINITIONS(-DHAVE_MBEDTLS) -- 2.39.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH ustream-ssl 1/2] ustream-mbedtls: Add compatibility with Mbed TLS 3.0.0
This adds support for compiling the code against Mbed TLS 3.0.0.
It still compiles against Mbed TLS 2.28.
The following changes were needed:
* DES and 3DES was removed
* mbedtls_pk_context->pk_info is private, use mbedtls_pk_get_type()
to check if it was initialized
* mbedtls_pk_parse_keyfile() now gets a random callback
* mbedtls/certs.h contains test data and is not installed any more and
not needed.
Signed-off-by: Hauke Mehrtens
---
ustream-mbedtls.c | 12 +++-
ustream-mbedtls.h | 1 -
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index 7fc7874..1c70cac 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -110,9 +110,15 @@ static const int default_ciphersuites_client[] =
AES_CBC_CIPHERS(ECDHE_ECDSA),
AES_CBC_CIPHERS(ECDHE_RSA),
AES_CBC_CIPHERS(DHE_RSA),
+/* Removed in Mbed TLS 3.0.0 */
+#ifdef MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
+#endif
AES_CIPHERS(RSA),
+/* Removed in Mbed TLS 3.0.0 */
+#ifdef MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA
MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA,
+#endif
0
};
@@ -171,7 +177,7 @@ static void ustream_ssl_update_own_cert(struct
ustream_ssl_ctx *ctx)
if (!ctx->cert.version)
return;
- if (!ctx->key.pk_info)
+ if (mbedtls_pk_get_type(>key) == MBEDTLS_PK_NONE)
return;
mbedtls_ssl_conf_own_cert(>conf, >cert, >key);
@@ -206,7 +212,11 @@ __hidden int __ustream_ssl_set_key_file(struct
ustream_ssl_ctx *ctx, const char
{
int ret;
+#if (MBEDTLS_VERSION_NUMBER >= 0x0300)
+ ret = mbedtls_pk_parse_keyfile(>key, file, NULL, _random, NULL);
+#else
ret = mbedtls_pk_parse_keyfile(>key, file, NULL);
+#endif
if (ret)
return -1;
diff --git a/ustream-mbedtls.h b/ustream-mbedtls.h
index e622e5e..7e7c699 100644
--- a/ustream-mbedtls.h
+++ b/ustream-mbedtls.h
@@ -21,7 +21,6 @@
#include
#include
-#include
#include
#include
#include
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] Deactivate _FORTIFY_SOURCE in jitterentropy-base.c
This fixes compilation with glibc.
_FORTIFY_SOURCE only works with compiler optimizations activated.
We have to deactivate it when we set -O0.
This fixes the following error message with glibc:
error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)
[-Werror=cpp]
musl libc does not show an error message in this case, but has the same
internal problems.
Signed-off-by: Hauke Mehrtens
---
CMakeLists.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Changelog:
v2: Use SET_PROPERTY and COMPILE_OPTIONS
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a1ee0c1..f415f87 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -22,8 +22,11 @@ ADD_EXECUTABLE(urngd
)
TARGET_LINK_LIBRARIES(urngd ${ubox})
-# jitter RNG must not be compiled with optimizations
-SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES
COMPILE_FLAGS -O0)
+# jitter RNG must not be compiled with optimizations, _FORTIFY_SOURCE needs
optimizations
+SET_PROPERTY(
+ SOURCE ${JTEN_DIR}/jitterentropy-base.c
+ APPEND PROPERTY COMPILE_OPTIONS -U_FORTIFY_SOURCE -O0
+)
INSTALL(TARGETS urngd RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR})
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] Deactivate _FORTIFY_SOURCE in jitterentropy-base.c
This fixes compilation with glibc.
_FORTIFY_SOURCE only works with compiler optimizations activated.
We have to deactivate it when we set -O0.
This fixes the following error message with glibc:
error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)
[-Werror=cpp]
musl libc does not show an error message in this case, but has the same
internal problems.
Signed-off-by: Hauke Mehrtens
---
CMakeLists.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a1ee0c1..78954c0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -22,8 +22,9 @@ ADD_EXECUTABLE(urngd
)
TARGET_LINK_LIBRARIES(urngd ${ubox})
-# jitter RNG must not be compiled with optimizations
+# jitter RNG must not be compiled with optimizations, _FORTIFY_SOURCE needs
optimizations
SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES
COMPILE_FLAGS -O0)
+SET_SOURCE_FILES_PROPERTIES(${JTEN_DIR}/jitterentropy-base.c PROPERTIES
COMPILE_FLAGS -U_FORTIFY_SOURCE)
INSTALL(TARGETS urngd RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR})
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: add support for rtw88_8822bu
On 10/22/23 12:31, Alexis Lothoré wrote: From: Alexis Lothoré Kernel 6.1 has introduced support for RTW8822BU network adapter, which is an USB variant of the rtw8822b 802.11ac chipset family. Build and install the corresponding module in the rtw88 package Signed-off-by: Alexis Lothoré --- This commit has been tested on Raspberry Pi 4 with an Archer T3U USB Nano Wifi dongle (8822BU). The resulting OpenWRT successfully acts as station or access point --- package/kernel/mac80211/realtek.mk | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/package/kernel/mac80211/realtek.mk b/package/kernel/mac80211/realtek.mk index 9c143583265e..4c618e6257c7 100644 --- a/package/kernel/mac80211/realtek.mk +++ b/package/kernel/mac80211/realtek.mk @@ -21,8 +21,8 @@ config-y += RTL8XXXU_UNTESTED config-$(call config_package,rtl8723bs) += RTL8723BS config-y += STAGING -config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI -config-y += RTW88_8822BE RTW88_8822CE RTW88_8723DE +config-$(call config_package,rtw88) += RTW88 RTW88_CORE RTW88_PCI RTW88_USB +config-y += RTW88_8822BE RTW88_8822BU RTW88_8822CE RTW88_8723DE config-$(CONFIG_PACKAGE_RTW88_DEBUG) += RTW88_DEBUG config-$(CONFIG_PACKAGE_RTW88_DEBUGFS) += RTW88_DEBUGFS @@ -168,18 +168,20 @@ endef define KernelPackage/rtw88 $(call KernelPackage/mac80211/Default) - TITLE:=Realtek RTL8822BE/RTL8822CE/RTL8723DE + TITLE:=Realtek RTL8822BE/RTL8822BU/RTL8822CE/RTL8723DE DEPENDS+= @(PCI_SUPPORT) +kmod-mac80211 +@DRIVER_11AC_SUPPORT FILES:=\ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822be.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822b.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822ce.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8822c.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723de.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_8723d.ko \ $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_core.ko \ - $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko - AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822ce rtw88_8723de) + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_pci.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtw88/rtw88_usb.ko + AUTOLOAD:=$(call AutoProbe,rtw88_8822be rtw88_8822bu rtw88_8822ce rtw88_8723de) endef define KernelPackage/rtl8723bs Currently this package only depends on PCI support, this also adds a dependency to USB. I think the beast approach is to split this into a core part with the rtw88_core.ko and the rtw88_88*.ko files, one package with rtw88_pci.ko and one with rtw88_usb.ko. Then you can install it on a system with only USB and on a system with only PCIe support. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 23.05.0 - First stable release
Hi, The OpenWrt community is proud to announce the first stable release of the OpenWrt 23.05 stable series. OpenWrt 23.05.0 incorporates over 4300 commits since branching the previous OpenWrt 22.03 release and has been under development for over one year. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=23.05.0 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.0/targets/ Highlights in OpenWrt 23.05.0: == Many new devices added == OpenWrt 23.05 supports over 1790 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) * GL.iNet GL-MT6000 (MT7986A) * Netgear WAX620 (IPQ8072A) * ZyXEL EX5700 (MT7986) * Support for Wifi 6E (6GHz) * Acer Predator W6 (MT7986A) * ZyXEL EX5700 (MT7986) * 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices (See OpenWrt forum) * Improved DSL statistics on ubus and in LuCI * Added Arm SystemReady (EFI) compliant target replacing the armvirt target Switch from wolfssl to mbedtls as default = OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls. This shift brings several changes and implications: * Size Efficiency: mbedtls is considerably smaller, making it an optimal choice for systems where storage space is paramount. * LTS and ABI Stability: mbedtls consistently provides updates via its Long Term Support (LTS) branch, ensuring both security and a stable application binary interface (ABI). In contrast, wolfssl does not offer an LTS release, and its stable ABI is limited to a specific set of functions. * TLS 1.3 Support: Users should be aware that mbedtls 2.28 no longer supports TLS 1.3. While mbedtls is now the default, users who have specific needs or preferences can still manually switch back to wolfssl or choose openssl. Rust Package Support This release introduces the ability to include rust-written programs into the OpenWrt package infrastructure. Examples are: bottom, maturin, aardvark-dns and ripgrep. Core components update == Core components have the following versions in 23.05.0: * Updated toolchain: * musl libc 1.2.4 * glibc 2.37 * gcc 12.3.0 * binutils 2.40 * Updated Linux kernel * 5.15.134 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 Upgrading to 23.05.0 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 is not build because the DSA driver for the integrated GSWIP switch shows some error messages. * bcm53xx: Netgear R8000 and Linksys EA9200 Ethernet is broken See up to date information here: https://openwrt.org/releases/23.05/notes-23.05.0#known_issues - Full release notes and upgrade instructions are available at https://openwrt.org/releases/23.05/notes-23.05.0 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.0#known_issues For a detailed list of all changes since 22.03.0, refer to https://openwrt.org/releases/23.05/changelog-23.05.0 To download the 23.05.0 images, navigate to: https://downloads.openwrt.org/releases/23.05.0/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.0 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
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:
Re: [PATCH 22.03] mt76: backport various mt7603 fixes to improve Wi-Fi stability
On 8/25/23 07:44, Shiji Yang wrote: From: Shiji Yang The SSID of MT7628 will disappear under heavy load, which makes wireless unusable. These patches can fix this critical issue. Since the mt76 mainline is no longer compatible with OpenWrt-22.03. So let's backport them separately. b14c2351dd wifi: mt76: mt7603: disable A-MSDU tx support on MT7628 85cc58378d wifi: mt76: mt7603: add missing register initialization for MT7628 c03d84c0d0 wifi: mt76: mt7603: improve stuck beacon handling a8d9553d8f wifi: mt76: mt7603: improve watchdog reset reliablity 80b8bcf0e3 wifi: mt76: mt7603: rework/fix rx pse hang check 7ef4dd12d9 wifi: mt76: mt7603: fix tx filter/flush function 53edfc7aaa wifi: mt76: mt7603: fix beacon interval after disabling a single vif 72b87836d3 Revert "mt76: use IEEE80211_OFFLOAD_ENCAP_ENABLED instead of MT_DRV_AMSDU_OFFLOAD" Fixes: https://github.com/openwrt/openwrt/issues/13283 Fixes: https://github.com/openwrt/openwrt/issues/10074 Fixes: https://github.com/openwrt/openwrt/issues/9219 Fixes: https://github.com/openwrt/openwrt/issues/8757 Fixes: https://github.com/openwrt/openwrt/issues/8314 Fixes: https://github.com/openwrt/openwrt/issues/8184 Signed-off-by: Shiji Yang --- package/kernel/mt76/Makefile | 2 +- ...211_OFFLOAD_ENCAP_ENABLED-instead-of.patch | 71 ...ix-beacon-interval-after-disabling-a.patch | 26 +++ ...-mt7603-fix-tx-filter-flush-function.patch | 134 ++ ...-mt7603-rework-fix-rx-pse-hang-check.patch | 74 ...03-improve-watchdog-reset-reliablity.patch | 73 ...mt7603-improve-stuck-beacon-handling.patch | 163 ++ ...-missing-register-initialization-for.patch | 28 +++ ...-disable-A-MSDU-tx-support-on-MT7628.patch | 36 9 files changed, 606 insertions(+), 1 deletion(-) create mode 100644 package/kernel/mt76/patches/130-Revert-mt76-use-IEEE80211_OFFLOAD_ENCAP_ENABLED-instead-of.patch create mode 100644 package/kernel/mt76/patches/131-wifi-mt76-mt7603-fix-beacon-interval-after-disabling-a.patch create mode 100644 package/kernel/mt76/patches/132-wifi-mt76-mt7603-fix-tx-filter-flush-function.patch create mode 100644 package/kernel/mt76/patches/133-wifi-mt76-mt7603-rework-fix-rx-pse-hang-check.patch create mode 100644 package/kernel/mt76/patches/134-wifi-mt76-mt7603-improve-watchdog-reset-reliablity.patch create mode 100644 package/kernel/mt76/patches/135-wifi-mt76-mt7603-improve-stuck-beacon-handling.patch create mode 100644 package/kernel/mt76/patches/136-wifi-mt76-mt7603-add-missing-register-initialization-for.patch create mode 100644 package/kernel/mt76/patches/137-wifi-mt76-mt7603-disable-A-MSDU-tx-support-on-MT7628.patch Felix updated mt76 which contains these changes, see: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=76b1e564d202c09d0035315eb6e958a9b0dd4491 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 23.05.0-rc3 - Third Release Candidate
Hi, The OpenWrt community is proud to announce the third release candidate of the upcoming OpenWrt 23.05 stable series. OpenWrt 23.05.0-rc3 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-rc3 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.0-rc3/targets/ Changes between OpenWrt 23.05.0-rc2 and 23.05.0-rc3 === Changes in this release candidate since the previous 23.05.0-rc2 release candidate are: * New devices * ath79: MikroTik RB951G-2HnD * ipq40xx: Teltonika RUTX50 * ipq40xx: ZTE MF287+ aka DreiNeo * layerscape: Traverse Ten64 NAND variant * mediatek: Acer Predator W6 * mediatek: H3C Magic NX30 Pro * mediatek: Mercusys MR90X v1 * mediatek: Netgear EX6250v2 series (no wifi support) * mediatek: Xiaomi WR30U * mediatek: ZyXEL NWA50AX Pro * ramips: Sercomm S1500 devices * ramips: TP-Link EAP613 v1 * realtek: HPE 1920-8g-poe+ * Updated components: * hostapd: update to 2023-06-22 * mt76: update to 2023-07-26 * ath11k-firmware: update to stable WLAN.HK.2.9.0.1-01837 * openssl: update to 3.0.10 * mbedtls: Update to 2.28.4 * wolfssl: update to 5.6.3 * intel-microcode: update to 20230808 * linux-firmware: update to 20230804 * kernel: bump 5.15 to 5.15.127 * ramips: mt7621: disable the cpufreq driver (performance increase) * ramips: mt7621: disable highmem support and remove highmem offset patch (performance increase) * uqmi: support split-APN IPv4 and IPv6 dual-stack * iwinfo/rpcd: update byte counter to 64bit * x86: Activate CONFIG_PCIEASPM * x86: Add virtualization time sync support * armsr: activate many new configuration options * kernel: modules: add xdp-sockets-diag support * ipq40xx: meraki: define DTB load address * ath79: move ubnt-xm 64M RAM boards back to generic * lua: fix integer overflow in LNUM patch Many other changes in all parts of OpenWrt, see Chnagelog 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-rc3: * Updated toolchain: * musl libc 1.2.4 * glibc 2.37 * gcc 12.3.0 * binutils 2.40 * Updated Linux kernel * 5.15.127 for all targets * Network: * hostapd master snapshot from June 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-rc3 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.0-rc3#known_issues For a detailed list of all changes since 23.05.0-rc2, refer to https://openwrt.org/releases/23.05/changelog-23.05.0-rc3 To download the 23.05.0-rc3 images, navigate to: https://downloads.openwrt.org/releases/23.05.0-rc3/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.0-rc3 As always, a big
Re: [PATCH v1 2/5] ixp4xx: Resurrect IXP4xx support using device tree
On 6/19/23 13:31, Linus Walleij wrote: This resurrects the support for IXP4xx using device tree rather than the old (deleted) board files. The final pieces of IXP4xx board files were deleted in Linux v5.19. Ext4 root filesystems on CF and USB are supported by the default config. We support these three initial targets: - The Gateworks Avila GW2348 reference design has 64MB of RAM and 32MB of flash and also supports USB and CompactFlash. - The Gateworks Cambria GW2358 reference design has 128MB of RAM and 32MB of flash and also supports USB and CompactFlash. - The old and stable Linksys NSLU2 works fine as well, albeit it only has 32MB of RAM so it has been marked as non-default. The 8MB of flash can only fit the kernel, so it has been patched to boot from exteral media on USB. I have used it successfully as a NAS with ksmbd and LUCI web API, see: https://dflund.se/~triad/krad/ixp4xx/ Signed-off-by: Linus Walleij --- package/firmware/ixp4xx-microcode/Makefile| 59 + .../ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +++ .../firmware/ixp4xx-microcode/src/LICENSE.IPL | 27 ++ target/linux/ixp4xx/Makefile | 28 ++ .../ixp4xx/base-files/etc/board.d/02_network | 21 ++ .../lib/preinit/05_set_ether_mac_ixp4xx | 45 target/linux/ixp4xx/config-6.1| 246 ++ target/linux/ixp4xx/image/Makefile| 73 ++ ...d-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++ ...dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++ 10 files changed, 745 insertions(+) create mode 100644 package/firmware/ixp4xx-microcode/Makefile create mode 100644 package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h create mode 100644 package/firmware/ixp4xx-microcode/src/LICENSE.IPL create mode 100644 target/linux/ixp4xx/Makefile create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/02_network create mode 100644 target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx create mode 100644 target/linux/ixp4xx/config-6.1 create mode 100644 target/linux/ixp4xx/image/Makefile create mode 100644 target/linux/ixp4xx/patches-6.1/0001-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch create mode 100644 target/linux/ixp4xx/patches-6.1/301-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch diff --git a/package/firmware/ixp4xx-microcode/Makefile b/package/firmware/ixp4xx-microcode/Makefile new file mode 100644 index ..78fedfd1aaf1 --- /dev/null +++ b/package/firmware/ixp4xx-microcode/Makefile @@ -0,0 +1,59 @@ +# +# Copyright (C) 2007 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# Please add a SPDX header and remove the OpenWrt copyright. + +include $(TOPDIR)/rules.mk + +PKG_NAME:=ixp4xx-microcode +PKG_VERSION:=2.4 > +PKG_RELEASE:=2 Start with pkg release 1 + +PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip +PKG_SOURCE_URL:=http://downloads.openwrt.org/sources +PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa + +PKG_FLAGS:=nonshared + +include $(INCLUDE_DIR)/package.mk + +define Package/ixp4xx-microcode + SECTION:=net + CATEGORY:=Network + TITLE:=Microcode for the IXP4xx network engines + DEPENDS:=@TARGET_ixp4xx +endef + +define Package/ixp4xx-microcode/description + This package contains the microcode needed to use the network engines in IXP4xx CPUs +endef + +define Build/Prepare + rm -rf $(PKG_BUILD_DIR) + mkdir -p $(PKG_BUILD_DIR) + unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE) + mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c $(PKG_BUILD_DIR)/ + rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw + $(CP) ./src/* $(PKG_BUILD_DIR)/ +endef + +define Build/Compile + (cd $(PKG_BUILD_DIR); \ + $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c -o IxNpeMicrocode; \ + ./IxNpeMicrocode -be \ + ) +endef + +define Package/ixp4xx-microcode/install + $(INSTALL_DIR) $(1)/lib/firmware + $(INSTALL_DIR) $(1)/usr/share/doc + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A-HSS $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/ Are all these FW files always needed, or do you need them depending on the use case or device? If they are not always needed maybe add them into seperate packages. + $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/ +endef + +$(eval $(call BuildPackage,ixp4xx-microcode)) diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile new file mode 100644 index ..546964a6a876 --- /dev/null +++ b/target/linux/ixp4xx/Makefile @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright (C) 2006-2023 OpenWrt.org +
Re: [PATCH 1/5] boot/apex: Restore the APEX boot loader
On 6/19/23 13:31, Linus Walleij wrote: This is a partial revert of the deletion of the IXP4xx target: we restore the APEX boot loader so we can use it for the NSLU2 and related targets. The APEX upstream is as dead as it gets so I have applied OpenWrts old patches on top of the never released v1.6.10 version and forked it into an OpenWrt variant on GitHub. If the upstream comes back alive I will happily switch over to it. The file refers to the external GitHub, I suppose when integrating this patch the file should be copied to OpenWrts file repository and the file link changed. Signed-off-by: Linus Walleij --- package/boot/apex/Makefile | 61 ++ 1 file changed, 61 insertions(+) create mode 100644 package/boot/apex/Makefile diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile new file mode 100644 index ..f4ce5811b024 --- /dev/null +++ b/package/boot/apex/Makefile @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright (C) 2006-2023 OpenWrt.org + +include $(TOPDIR)/rules.mk +include $(INCLUDE_DIR)/kernel.mk + +PKG_NAME:=apex +# This version was created from the stalled and unreleased v1.6.10 +# with some patches on top. +PKG_VERSION:=1.6.10-openwrt +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/ +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640 +PKG_TARGETS:=bin + +include $(INCLUDE_DIR)/package.mk + +export GCC_HONOUR_COPTS=s + +define Package/apex + SECTION:=boot + CATEGORY:=Boot Loaders + DEPENDS:=@TARGET_ixp4xx + DEFAULT:=y I do not like it when a package is default y. This will always activate it by default. Maybe should also also mark this none shared. + TITLE:=Boot loader for NSLU2, FSG3, NAS100D and others +endef + +define build_apex + $(MAKE) -C $(PKG_BUILD_DIR) \ + ARCH=arm \ + $(1)_config + $(MAKE) -C $(PKG_BUILD_DIR) \ + $(TARGET_CONFIGURE_OPTS) \ + KBUILD_HAVE_NLS=no \ + ARCH=arm \ + clean all + $(INSTALL_BIN) $(PKG_BUILD_DIR)/apex.bin $(PKG_BUILD_DIR)/out/apex-$(2).bin +endef + +define Build/Compile + $(INSTALL_DIR) $(PKG_BUILD_DIR)/out + $(call build_apex,openwrt-nslu2-armeb,nslu2-armeb) + $(call build_apex,openwrt-nslu2-16mb-armeb,nslu2-16mb-armeb) + $(call build_apex,openwrt-fsg3-armeb,fsg3-armeb) + $(call build_apex,openwrt-nas100d-armeb,nas100d-armeb) +endef + +define Package/apex/install + $(INSTALL_DIR) $(STAGING_DIR)/apex + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(1)/ +endef This will build a OpenWrt package with these files. Do you really need these files in the root file system? I do not know how the boot process works, this just looks strange to me. + +define Build/InstallDev + $(INSTALL_DIR) $(STAGING_DIR_IMAGE) + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(STAGING_DIR_IMAGE)/ +endef + +$(eval $(call BuildPackage,apex)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uci 2/2] remove internal usage of redundant uci_ptr.last
On 7/14/23 20:28, Jan Venekamp wrote:
In uci_lookup_ptr and uci_set the pointer uci_ptr ptr.last is set to
the element corresponding to the first of: ptr.o, ptr.s, ptr.p.
Thus, ptr.last is redundant and in case of uci_set is (and was) not
always consistently set.
In order to simplify the code this commit removes internal usage
of ptr.last, and remove setting it from uci_set (and from uci_add_list
that was never used anyway).
As it is part of the public C api ptr.last cannot be completely
removed though. A search on lxr.openwrt.org shows that it is used as
the output of uci_lookup_ptr in several packages.
So we leave setting ptr.last in uci_lookup_ptr intact.
Signed-off-by: Jan Venekamp
---
cli.c | 39 +++
delta.c | 10 ++
list.c| 6 --
lua/uci.c | 42 +++---
4 files changed, 32 insertions(+), 65 deletions(-)
..
@@ -349,20 +347,14 @@ static int package_cmd(int cmd, char *tuple)
cli_perror();
goto out;
}
- switch(e->type) {
- case UCI_TYPE_PACKAGE:
- uci_show_package(ptr.p);
- break;
- case UCI_TYPE_SECTION:
- uci_show_section(ptr.s);
- break;
- case UCI_TYPE_OPTION:
- uci_show_option(ptr.o, true);
- break;
- default:
- /* should not happen */
- goto out;
- }
+ if (ptr.o)
+ uci_show_option(ptr.o, true);
+ else if (ptr.s)
+ uci_show_section(ptr.s);
+ else if (ptr.p)
+ uci_show_package(ptr.p);
+ else
+ goto out; /* should not happen */
break;
How do we make sure that only one of these is set at a time?
Before the code would print the last element added.
}
@@ -475,7 +467,6 @@ done:
..
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uci] file: Fix uci -m import command
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 ---
Without this change we see the following error:
# uci -m import optic < /etc/optic-db/default
uci: Parse error (option/list command found before the first section) at line
4, byte 1
ptr.last is still a null pointer in case the uci_lookup_list() call
found a matching section and set ptr.s to it. The code expects that
uci_set() updates the ptr.last pointer, but this is not done any more.
If case uci_lookup_list() did not found a section ptr->s is a null
pointer and then uci_set() will allocate a new section.
Fixes: ae61e1cad4a1 ("uci: optimize update section in uci_set")
Fixes: 7e01d66d7bec ("uci: optimize update option in uci_set")
Signed-off-by: Hauke Mehrtens
---
file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/file.c b/file.c
index 93abfae..b01480c 100644
--- a/file.c
+++ b/file.c
@@ -449,6 +449,7 @@ static void uci_parse_config(struct uci_context *ctx)
e = uci_lookup_list(>package->sections, name);
if (e) {
ptr.s = uci_to_section(e);
+ ptr.last = >e;
if ((ctx->flags & UCI_FLAG_STRICT) &&
strcmp(ptr.s->type, type))
uci_parse_error(ctx, "section of different type
overwrites prior section with same name");
@@ -490,8 +491,10 @@ static void uci_parse_option(struct uci_context *ctx, bool
list)
uci_fill_ptr(ctx, , >section->e);
e = uci_lookup_list(>section->options, name);
- if (e)
+ if (e) {
ptr.o = uci_to_option(e);
+ ptr.last = >e;
+ }
ptr.option = name;
ptr.value = value;
--
2.17.1
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 23.05.0-rc2 - Second Release Candidate
Hi, The OpenWrt community is proud to announce the second release candidate of the upcoming OpenWrt 23.05 stable series. OpenWrt 23.05.0-rc2 incorporates over 4000 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-rc2 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ Changes between OpenWrt 23.05.0-rc1 and 23.05.0-rc2 === Changes in this release candidate since the previous 23.05.0-rc1 release candidate are: * Device support * New devices * ath79: Aruba AP-115 * bmips: Observa VH4032N * bmips: Netgear DGND3700 v1 * bmips: Netgear DGND3800B * bmips: Netgear EVG2000 * bmips: Comtrend VR-3025un * bmips: Comtrend WAP-5813n * bmips: Comtrend AR-5381u * bmips: Actiontec R1000H * bmips: Sercomm AD1018 * bmips: Comtrend VG-8050 * bmips: NuCom R5010UNv2 * bmips: Arcadyan AR7516 * filogic: Netgear WAX220 * ipq40xx: Buffalo WTR-M2133HP (converted to DSA) * ipq807x: prpl Foundation Haze board * ramips: mt7621: Zbtlink ZBT-WG1608 (32M) * ramips: Beeline SmartBox TURBO+ * rockchip: Orange Pi R1 Plus * rockchip: Orange Pi R1 Plus LTS * Fix lzma-loader for * ramips: ASIARF boards * ramips: TP-Link MR600v2: fix image generation for sysupgrade image * mvebu: Fix random crashes in mvneta * armvirt: Added EFI support and renamed to armsr * Add RISC-V support * Added sifiveu target for HiFive Unleashed and Unmatched boards Many other changes in all parts of OpenWrt, see Chnagelog for details. Highlights in OpenWrt 23.05.0: == Many new devices added == OpenWrt 23.05 supports over 1770 devices. Support for over 180 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 * Netgear WAX206 (MT7622) * 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-rc2: * Updated toolchain: * musl libc 1.2.4 * glibc 2.37 * gcc 12.3.0 * binutils 2.40 * Updated Linux kernel * 5.15.118 for all targets * Network: * hostapd master snapshot from March 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-rc2 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.0-rc2#known_issues For a detailed list of all changes since 23.05.0-rc1, refer to https://openwrt.org/releases/23.05/changelog-23.05.0-rc2 To download the 23.05.0-rc2 images, navigate to: https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.0-rc2 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds)
[PATCH] Make struct nla_policy and struct nlattr const
Make the struct nla_policy and the struct nlattr const in many places
like it is done in full libnl. This bringe our libnl-tiny closer to the
upstream version.
Signed-off-by: Hauke Mehrtens
---
attr.c | 14 +--
genl.c | 4 ++--
include/netlink/attr.h | 48 ++---
include/netlink/genl/genl.h | 4 ++--
include/netlink/msg.h | 6 ++---
msg.c | 6 ++---
6 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/attr.c b/attr.c
index fd10b25..2c1d354 100644
--- a/attr.c
+++ b/attr.c
@@ -443,10 +443,10 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
[NLA_S64] = sizeof(int64_t),
};
-static int validate_nla(struct nlattr *nla, int maxtype,
- struct nla_policy *policy)
+static int validate_nla(const struct nlattr *nla, int maxtype,
+ const struct nla_policy *policy)
{
- struct nla_policy *pt;
+ const struct nla_policy *pt;
int minlen = 0, type = nla_type(nla);
if (type <= 0 || type > maxtype)
@@ -500,7 +500,7 @@ static int validate_nla(struct nlattr *nla, int maxtype,
* @return 0 on success or a negative error code.
*/
int nla_parse(struct nlattr *tb[], int maxtype, struct nlattr *head, int len,
- struct nla_policy *policy)
+ const struct nla_policy *policy)
{
struct nlattr *nla;
int rem, err;
@@ -552,10 +552,10 @@ errout:
*
* @return 0 on success or a negative error code.
*/
-int nla_validate(struct nlattr *head, int len, int maxtype,
-struct nla_policy *policy)
+int nla_validate(const struct nlattr *head, int len, int maxtype,
+const struct nla_policy *policy)
{
- struct nlattr *nla;
+ const struct nlattr *nla;
int rem, err;
nla_for_each_attr(nla, head, len, rem) {
diff --git a/genl.c b/genl.c
index f1df3f0..d5a14e5 100644
--- a/genl.c
+++ b/genl.c
@@ -158,7 +158,7 @@ int genlmsg_valid_hdr(struct nlmsghdr *nlh, int hdrlen)
}
int genlmsg_validate(struct nlmsghdr *nlh, int hdrlen, int maxtype,
- struct nla_policy *policy)
+ const struct nla_policy *policy)
{
struct genlmsghdr *ghdr;
@@ -171,7 +171,7 @@ int genlmsg_validate(struct nlmsghdr *nlh, int hdrlen, int
maxtype,
}
int genlmsg_parse(struct nlmsghdr *nlh, int hdrlen, struct nlattr *tb[],
- int maxtype, struct nla_policy *policy)
+ int maxtype, const struct nla_policy *policy)
{
struct genlmsghdr *ghdr;
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 28fac87..994af4a 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -80,9 +80,9 @@ struct nla_policy {
extern int nla_ok(const struct nlattr *, int);
extern struct nlattr * nla_next(const struct nlattr *, int *);
extern int nla_parse(struct nlattr **, int, struct nlattr *,
- int, struct nla_policy *);
-extern int nla_validate(struct nlattr *, int, int,
-struct nla_policy *);
+ int, const struct nla_policy *);
+extern int nla_validate(const struct nlattr *, int, int,
+const struct nla_policy *);
extern struct nlattr * nla_find(struct nlattr *, int, int);
/* Unspecific attribute */
@@ -202,7 +202,7 @@ static inline int nla_len(const struct nlattr *nla)
*
* @return The number of bytes copied to dest.
*/
-static inline int nla_memcpy(void *dest, struct nlattr *src, int count)
+static inline int nla_memcpy(void *dest, const struct nlattr *src, int count)
{
int minlen;
@@ -275,9 +275,9 @@ static inline int nla_put_s8(struct nl_msg *msg, int
attrtype, int8_t value)
*
* @return Payload as 8 bit integer.
*/
-static inline int8_t nla_get_s8(struct nlattr *nla)
+static inline int8_t nla_get_s8(const struct nlattr *nla)
{
- return *(int8_t *) nla_data(nla);
+ return *(const int8_t *) nla_data(nla);
}
/**
@@ -300,9 +300,9 @@ static inline int nla_put_u8(struct nl_msg *msg, int
attrtype, uint8_t value)
*
* @return Payload as 8 bit integer.
*/
-static inline uint8_t nla_get_u8(struct nlattr *nla)
+static inline uint8_t nla_get_u8(const struct nlattr *nla)
{
- return *(uint8_t *) nla_data(nla);
+ return *(const uint8_t *) nla_data(nla);
}
/**
@@ -325,9 +325,9 @@ static inline int nla_put_s16(struct nl_msg *msg, int
attrtype, int16_t value)
*
* @return Payload as 16 bit integer.
*/
-static inline int16_t nla_get_s16(struct nlattr *nla)
+static inline int16_t nla_get_s16(const struct nlattr *nla)
{
- return *(int16_t *) nla_data(nla);
+ return *(const int16_t *) nla_data(nla);
}
/**
@@ -350,9 +350,9 @@ static inline int nla_put_u16(struct nl_msg *msg, int
attrtype, uint16_t
Re: [PATCH 1/9] kernel/generic: remove CONFIG_FB_NOTIFY
On 4/26/23 01:23, Elliott Mitchell wrote: I don't know what version of Linux this option disappeared at, but it is clearly gone now. Signed-off-by: Elliott Mitchell --- target/linux/generic/config-5.10 | 1 - target/linux/generic/config-5.15 | 1 - 2 files changed, 2 deletions(-) diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index cde0fdb0a0..f6f1fb0278 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -1892,7 +1892,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 index 239a645231..ac75a480a1 100644 --- a/target/linux/generic/config-5.15 +++ b/target/linux/generic/config-5.15 @@ -1979,7 +1979,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FB_MXS is not set # CONFIG_FB_N411 is not set # CONFIG_FB_NEOMAGIC is not set -CONFIG_FB_NOTIFY=y # CONFIG_FB_NVIDIA is not set # CONFIG_FB_OF is not set # CONFIG_FB_OMAP2 is not set Some targets are activating CONFIG_FB=y, for these targets we also want to activate CONFIG_FB_NOTIFY for some reason. If a target does not set CONFIG_FB, it will also not set CONFIG_FB_NOTIFY Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 23.05.0-rc1 first release candidate
Hi, The OpenWrt community is proud to announce the first release candidate of the upcoming OpenWrt 23.05 stable series. OpenWrt 23.05.0-rc1 incorporates over 3900 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-rc1 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/23.05.0-rc1/targets/ Highlights in OpenWrt 23.05.0: == Many new devices added == OpenWrt 23.05 supports over 1750 devices. Support for over 160 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 Highlights of device support * Switched ipq40xx target to DSA * VDSL support on AVM FRITZ!Box 7530 * Support for devices with 2.5G PHYs * Netgear WAX206 (MT7622) * Asus (TUF Gaming) AX4200 (MT7986A) * Netgear WAX218 (IPQ8074) * Xiaomi AX9000 (IPQ8074) * Dynalink DL-WRX36 (IPQ8074) * 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-rc1: * Updated toolchain: * musl libc 1.2.4 * glibc 2.37 * gcc 12.3.0 * binutils 2.40 * Updated Linux kernel * 5.15.114 for all targets * Network: * hostapd master snapshot from March 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-rc1 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/23.05/notes-23.05.0-rc1#known_issues For a detailed list of all changes since 22.03.0, refer to https://openwrt.org/releases/23.05/changelog-23.05.0-rc1 To download the 23.05.0-rc1 images, navigate to: https://downloads.openwrt.org/releases/23.05.0-rc1/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=23.05.0-rc1 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/1/23 21:28, Peter Naulls wrote: For those of you who track the small but very real OpenWrt job market, you may have seen there's a creep into Defense/Clearance jobs. Here's but one example: https://careers-bluehalo.icims.com/jobs/3844/job As a self-declared pacifist (and anyway, dual citizen which would limit my ability to get clearance), this is most certainly not for me, but I thought it should be something you guys might want to be aware of. I check from time to time which companies in the US are looking for OpenWrt experts [0] to get an overview who is using it. About 10% to 30% of these job offers require clearance. It looks like the US military and US intelligence community is using OpenWrt. Once I saw a job offer where someone was looking for a person who has experience in writing exploits for OpenWrt and DD-WRT in the Washington, D.C. area, this scared me a bit, normally I do not have the NSA in my thread model. Someone from BAE Systems (largest defence contractor in Europe) was also contacting us at OpenWrt some years ago with questions about the license. I hope that these companies use OpenWrt mostly to provide Internet access for their soldiers and it is not part of any real weapon system. As OpenWrt is now used by many vendors I think the intelligence agencies around the world are interested in exploits fro OpenWrt. I heard a rumor some years ago that one of the biggest OpenWrt installation was at the fence between the US and Mexico, but I have no prove that this is true. The GPL and the other licenses used by OpenWrt do not prevent the usage by any military or intelligence agency. OpenWrt does not do a background check on external contributors. We have contributions from people from many countries the US does not like. Hauke [0]: https://www.indeed.com/jobs?q=openwrt= ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.5 fifth service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=22.03.5 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.5/targets/ Main changes between OpenWrt 22.03.4 and OpenWrt 22.03.5: Security fixes == * CVE-2023-0464: openssl: Excessive Resource Usage Verifying X.509 Policy Constraints * CVE-2023-0465: openssl: Invalid certificate policies in leaf certificates are silently ignored Device support == * Archer AX23 / MR70X: Reduce SPI-frequency * Aruba AP-105: Create APBoot compatible image * Buffalo WSR-600DHP: Fix boot loop Various fixes and improvements == * Fix UBI (Unsorted Block Images) bug which prevented some devices from booting * Fix ccache compile with GCC 13 Core components update == * Update uclient from 2021-05-14 to 2023-04-13 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.5 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.5#known_issues For a detailed list of all changes since 22.03.4, refer to https://openwrt.org/releases/22.03/changelog-22.03.5 To download the 22.03.5 images, navigate to: https://downloads.openwrt.org/releases/22.03.5/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=22.03.5 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.7 seventh service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 21.02 stable version series. It fixes security issues and brings a bug fix. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=21.02.7 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/21.02.7/targets/ The OpenWrt 21.02 stable series is now end of life following the OpenWrt Security support guidelines. We encourage all users of the OpenWrt 21.02 stable series to upgrade to OpenWrt 22.03. We will not fix any security problems, even severe ones in the OpenWrt 21.02 release branch any more. https://openwrt.org/docs/guide-developer/security#support_status Main changes between OpenWrt 21.02.6 and OpenWrt 21.02.7: Security fixes == * CVE-2023-0464: openssl: Excessive Resource Usage Verifying X.509 Policy Constraints * CVE-2023-0465: openssl: Invalid certificate policies in leaf certificates are silently ignored Device support == * None Various fixes and improvements == * Fix UBI (Unsorted Block Images) bug which prevented some devices from booting Core components === * Update uclient from 2021-05-14 to 2023-04-13 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.7 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.7#known_issues For a detailed list of all changes since 21.02.6, refer to https://openwrt.org/releases/21.02/changelog-21.02.7 To download the 21.02.7 images, navigate to: https://downloads.openwrt.org/releases/21.02.7/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=21.02.7 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression in backport MEMREAD ioctl ? [Was: Re: mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow]
On 4/21/23 15:17, Michał Kępień wrote:
Hi Petr,
Since the crash happens right after snand driver initialization, I think the
most likely candidate is this one:
fa4dc86e9808 kernel: backport MEMREAD ioctl
Maybe there are still some stack declarations of struct mtd_oob_ops left
that aren't fully initialized.
thanks for looking into that Felix, Michał any idea what might be wrong here?
I remember looking for uninitialized fields in all existing instances of
struct mtd_oob_ops in version 5.15.98 of the Linux kernel source tree
while preparing the MEMREAD backports. However, it did not occur to me
to check OpenWRT-specific patches in the same way (sorry!) - and a naïve
search uncovers these two locations:
$ git grep -E 'struct mtd_oob_ops [^=*{}]+;' --
':!target/linux/generic/backport-5.15/'
package/boot/uboot-mediatek/patches/100-07-mtd-nmbm-add-support-for-mtd.patch:+
struct mtd_oob_ops ops;
package/boot/uboot-mediatek/patches/100-07-mtd-nmbm-add-support-for-mtd.patch:+
struct mtd_oob_ops ops;
package/boot/uboot-mediatek/patches/100-11-env-add-support-for-NMBM-upper-MTD-layer.patch:+
struct mtd_oob_ops ops;
These patches are applied to U-Boot and not the kernel. The
"fa4dc86e9808 kernel: backport MEMREAD ioctl" change only changes he
kernel.
Since the panic message includes mentions of a stack overflow, another
idea would be to backport this upstream patch as well:
https://lore.kernel.org/linux-mtd/20230417205654.1982368-1-a...@kernel.org/
This patch has been reviewed, but it has not yet been merged anywhere.
Please send a patch to the openwrt mailing list or create a pull request
on github.
hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
next OpenWrt 22.03 and 21.02 minor release
Hi, I would like to create a new OpenWrt 22.03 and 21.02 minor release in the next week. OpenWrt 21.02.6 would be the final release of the OpenWrt 21.02 series. On github the following pull requests are tagged for the releases: https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F22.03 https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 If we should backport more changes please create a pull request on github, send a patch with the 22.03 or 21.02 prefix to the mailing list or send a mail with a link to the master commit we should backport as an answer to this mail and I will have a look at the commit. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [libnl-tiny PATCH] attr: add NLA_S8
On 3/15/23 14:37, Nick Hainke wrote:
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
---
attr.c | 1 +
include/netlink/attr.h | 35 +++
2 files changed, 36 insertions(+)
diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,7 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
[NLA_U32] = sizeof(uint32_t),
[NLA_U64] = sizeof(uint64_t),
[NLA_STRING]= 1,
+ [NLA_S8]= sizeof(int8_t),
};
static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..3a5d53d 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,7 @@ enum {
NLA_FLAG, /**< Flag */
NLA_MSECS, /**< Micro seconds (64bit) */
NLA_NESTED, /**< Nested attributes */
+ NLA_S8,
__NLA_TYPE_MAX,
};
I think this has to match the kernel definitions of the same enum.
https://elixir.bootlin.com/linux/v6.1.20/source/include/net/netlink.h#L178
Please add the other definitions added in this commit too:
https://github.com/thom311/libnl/commit/6263a11bfcd033a88583faa719d3911850f0c4f5
I think you should also add all the nla_put_s* and nla_get_s*
definitions for s8, s16, s32 and s64. libnl-tiny adds them to the header
only so they do not make the binary bigger when they are not used.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reusable Github Actions and containers [Was: Re: [PATCH uci 2/2] CI: Add github action]
Hi Petr, thanks for the comments. These patches are my minimal version to get something running. I will try to extend it in the new few weeks. On 3/11/23 09:57, Petr Štetiar wrote: Hauke Mehrtens [2023-03-09 00:18:10]: Hi, thanks for taking care, LGTM for a start. I'll just provide my past experience, something to consider as we're likely going to bump into those in the long term, so ideally take them into the account in the long term. clang 14 generates debug information in DWARF 5 format, but valgrind 19.0 does not support that. Install valgrind 20.0 from experimental which supports it. IMO we should aim for reproducible results, thus we should likely provide tools containers with a known versions inside, so anyone is able to get same results using the source code Git hash and tool container version. Yes that is a good idea. Debian bookworm is now in code freeze phase so it should not change much any more, but having a stable container would be nice. Your current approach is highly dynamic, so if you're lucky enough, you might get a green CI light in the PR branch as the pipeline was run for example 7 days ago, so you're going to merge it into the upstream branch, but then it's going to fail as meanwhile Debian has bumped several packages and you're going to get a CI pipeline failure. IMO there should be a tools container Git repository, where we could build, test and provide versioned containers, for example: ghcr.io/openwrt/ci-tools/native-testing/clang14:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang15:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-8:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-11:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-12:20230305 I will look into this. We want to test with with multiple compiler versions as those tested changes might be backported into stable branches, we should even consider to have stable branches in every project so we could CI test them there as well, folks would simply create a backport PR in the respective project. Often we only create a stable branch when we really need it in OpenWrt, many of these repositories do not have one. If we create a stable branch we should also have CI on it. +++ b/.github/workflows/test.yml @@ -0,0 +1,83 @@ +name: 'Run tests' We've like 30+ C projects which we should likely cover in the end, thus considering possible additional 2 stable branches in each, it's around 60+ of similar workflow files duplicated in various repositories. I would consider this future maintenance overhead (imagine just a simple change or a fix being propagated into 60+ repositories/branches), so I would recommend to create a shareable Github Action instead: uses: openwrt/gh-actions-ci-native env: CI_NATIVE_TOOLCHAIN: clang14 uses: openwrt/gh-actions-ci-sdk env: CI_TARGET_SDK_RELEASE: master CI_TARGET_SDK: ath79-generic CI_TARGET_BUILD_DEPENDS: uci You can take a look at the ucode project for a very dated, but still working GitHub example, some bits are even present in uci repsitory in the .gitlab-ci.yml file. I agree with you that we will have a lot of code duplication in the way I proposed it now. I will have a look at this. + - name: Checkout libubox +uses: actions/checkout@v3 +with: + repository: openwrt/libubox + path: libubox This looks like another source of unreliability, similar to the toolchain versions above. For the start, I would simply include all those dependencies in the native toolchain container, thus we would need to have separate containers for each branch: If the API changes we would have to update the containers too. I would prefer to use master of all components or even check if there is a branch with the same name and use that one. I think we recently had some changes to iwinfo and then some changes in rpcd which depended on that. I would like to support such changes too. ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-22.03:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-21.02:20230305 ghcr.io/openwrt/ci-tools/native-testing/distro_snapshot:20230305 (distro default gcc12) ghcr.io/openwrt/ci-tools/native-testing/distro_21.02:20230305 (gcc8) ghcr.io/openwrt/ci-tools/native-testing/distro_22.03:20230305 (gcc11) So in the end, ideally, interested developer can have the same CI failure/result locally and debug/fix it faster: $ git clone https://github.com/openwrt/uci && cd uci $ wget -q https://github.com/openwrt/some-project/raw/master/Makefile -O Makefile.ci $ make ci-prepare -f Makefile.ci $ podman run --rm --tty --interactive --volume $(pwd):/home/build/openwrt \ ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 \ make ci-native-build -f Makefile.ci Have a nice weekend. Cheers, Petr
Re: [PATCH uci 1/2] fuzz: Compile using libstd++
On 3/11/23 10:01, Petr Štetiar wrote: Hauke Mehrtens [2023-03-09 00:18:09]: Hi, It looks like libfuzzer is compiled using libstd++ on Debian Bookworm and not libc++. Using libc++ causes linking errors, use libstd++ instead. so maybe this should be detected and decided at runtime? Otherwise this seems to just support Bookworm from now and thus fail to compile elsewhere? Cheers, Petr Hi Petr, I tried this in a Debian bullseye container too and there it also works fine with libstd++. What libfuzzer did you use in your container in gitlab? An automatic detection would be nice, but I have no idea how to do it. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uci 2/2] CI: Add github action
Add a github action to build uci and then execute the tests.
This first builds and installs libubox and then uses that dependency to
build and test uci.
clang 14 generates debug information in DWARF 5 format, but valgrind
19.0 does not support that. Install valgrind 20.0 from experimental
which supports it.
Signed-off-by: Hauke Mehrtens
---
I created a github pull request with these changes too:
https://github.com/openwrt/libubox/pull/2
.github/workflows/test.yml | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 .github/workflows/test.yml
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
new file mode 100644
index 000..d76300d
--- /dev/null
+++ b/.github/workflows/test.yml
@@ -0,0 +1,83 @@
+name: 'Run tests'
+
+on:
+ push:
+
+jobs:
+ build_test:
+strategy:
+ matrix:
+include:
+ - compiler: "-DCMAKE_C_COMPILER=clang"
+ - compiler: "-DCMAKE_C_COMPILER=gcc"
+
+name: Build and run tests
+runs-on: ubuntu-latest
+container:
+ image: debian:bookworm
+
+steps:
+
+ - name: Add Debian experimental
+run: |
+ echo "deb http://deb.debian.org/debian/ experimental main" >>
/etc/apt/sources.list
+
+ - name: Install compiler
+run: |
+ apt update
+ apt install -y cmake build-essential lua5.1 pkgconf libjson-c-dev
liblua5.1-0-dev python3.11-venv clang libc++abi-dev libc++-dev
+ apt -t experimental install -y valgrind
+ useradd -ms /bin/bash buildbot
+
+ - name: Checkout libubox
+uses: actions/checkout@v3
+with:
+ repository: openwrt/libubox
+ path: libubox
+
+ - name: Checkout uci
+uses: actions/checkout@v3
+with:
+ path: uci
+
+ - name: Create build directory
+run: mkdir libubox-build
+
+ - name: Create build directory
+run: mkdir uci-build
+
+ - name: Create install directory
+run: mkdir install
+
+ - name: Fix permission
+run: chown -R buildbot:buildbot libubox-build libubox uci uci-build
install
+
+ - name: Run cmake (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: cmake ../libubox -DCMAKE_INSTALL_PREFIX=../install
-DBUILD_LUA=false ${{ matrix.compiler }}
+
+ - name: Run build (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: make
+
+ - name: Run install (libubox)
+shell: su buildbot -c "sh -e {0}"
+working-directory: libubox-build
+run: make install
+
+ - name: Run cmake (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: cmake ../uci -DUNIT_TESTING=true
-DCMAKE_INSTALL_PREFIX=../install -DCMAKE_PREFIX_PATH=../install ${{
matrix.compiler }}
+
+ - name: Run build (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: make
+
+ - name: Run tests (uci)
+shell: su buildbot -c "sh -e {0}"
+working-directory: uci-build
+run: make test
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uci 1/2] fuzz: Compile using libstd++
It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.
Signed-off-by: Hauke Mehrtens
---
tests/fuzz/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fuzz/CMakeLists.txt b/tests/fuzz/CMakeLists.txt
index 1533c46..f1b4a0d 100644
--- a/tests/fuzz/CMakeLists.txt
+++ b/tests/fuzz/CMakeLists.txt
@@ -4,7 +4,7 @@ MACRO(ADD_FUZZER_TEST name)
ADD_EXECUTABLE(${name} ${name}.c)
TARGET_COMPILE_OPTIONS(${name} PRIVATE -g -O1 -fno-omit-frame-pointer
-fsanitize=fuzzer,address,leak,undefined)
TARGET_INCLUDE_DIRECTORIES(${name} PRIVATE ${PROJECT_SOURCE_DIR})
- TARGET_LINK_OPTIONS(${name} PRIVATE -stdlib=libc++
-fsanitize=fuzzer,address,leak,undefined)
+ TARGET_LINK_OPTIONS(${name} PRIVATE -fsanitize=fuzzer,address,leak,undefined)
TARGET_LINK_LIBRARIES(${name} uci)
ADD_TEST(
NAME ${name}
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH libubox 1/2] fuzz: Compile using libstd++
It looks like libfuzzer is compiled using libstd++ on Debian Bookworm
and not libc++. Using libc++ causes linking errors, use libstd++
instead.
Signed-off-by: Hauke Mehrtens
---
tests/fuzz/CMakeLists.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fuzz/CMakeLists.txt b/tests/fuzz/CMakeLists.txt
index cca74fd..6114a7c 100644
--- a/tests/fuzz/CMakeLists.txt
+++ b/tests/fuzz/CMakeLists.txt
@@ -4,7 +4,7 @@ MACRO(ADD_FUZZER_TEST name)
ADD_EXECUTABLE(${name} ${name}.c)
TARGET_COMPILE_OPTIONS(${name} PRIVATE -g -O1 -fno-omit-frame-pointer
-fsanitize=fuzzer,address,leak,undefined)
TARGET_INCLUDE_DIRECTORIES(${name} PRIVATE ${PROJECT_SOURCE_DIR})
- TARGET_LINK_OPTIONS(${name} PRIVATE -stdlib=libc++
-fsanitize=fuzzer,address,leak,undefined)
+ TARGET_LINK_OPTIONS(${name} PRIVATE -fsanitize=fuzzer,address,leak,undefined)
TARGET_LINK_LIBRARIES(${name} ubox blobmsg_json json_script ${json})
ADD_TEST(
NAME ${name}
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH libubox 2/2] CI: Add github action
Add a github action to build libubox and then execute the tests.
clang 14 generates debug informations in DWARF 5 format, but valgrind
19.0 does not support that. Install valgrind 20.0 from experimental
which supports it.
Signed-off-by: Hauke Mehrtens
---
I created a github pull request with these changes too:
https://github.com/openwrt/libubox/pull/2
.github/workflows/test.yml | 61 ++
1 file changed, 61 insertions(+)
create mode 100644 .github/workflows/test.yml
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
new file mode 100644
index 000..c6cdf0d
--- /dev/null
+++ b/.github/workflows/test.yml
@@ -0,0 +1,61 @@
+name: 'Run tests'
+
+on:
+ push:
+
+jobs:
+ build_test:
+strategy:
+ matrix:
+include:
+ - compiler: "-DCMAKE_C_COMPILER=clang"
+ - compiler: "-DCMAKE_C_COMPILER=gcc"
+
+name: Build and run tests
+runs-on: ubuntu-latest
+container:
+ image: debian:bookworm
+
+steps:
+
+ - name: Add Debian experimental
+run: |
+ echo "deb http://deb.debian.org/debian/ experimental main" >>
/etc/apt/sources.list
+
+ - name: Install compiler
+run: |
+ apt update
+ apt install -y cmake build-essential lua5.1 pkgconf libjson-c-dev
liblua5.1-0-dev python3.11-venv clang
+ apt -t experimental install -y valgrind
+ useradd -ms /bin/bash buildbot
+
+ - name: Checkout libubox
+uses: actions/checkout@v3
+with:
+ path: libubox
+
+ - name: Create build directory
+run: mkdir build
+
+ - name: Fix permission
+run: chown -R buildbot:buildbot build libubox
+
+ - name: Run cmake
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: cmake ../libubox -DUNIT_TESTING=true ${{ matrix.compiler }}
+
+ - name: build
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: make
+
+ - name: Run tests
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: make test
+
+ - name: Show logs
+shell: su buildbot -c "sh -e {0}"
+working-directory: build
+run: cat Testing/Temporary/LastTest.log
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt @ Battlemesh
Hi, Wireless Battlemesh v15 is coming up in May 8-14. https://battlemesh.org/BattleMeshV15 Battlemesh will take place this year in Calafou, Vallbona d'Anoia, Barcelona. We were thinking to do a OpenWrt meeting in parallel or before/after Battlemesh. I would like to know if it makes sense to organize an OpenWrt meeting at Battelmesh or before/after Battlemesh. I think we have 3 options. OpenWrt meetup at 7 and 8 of May. OpenWrt meetup at 14 and 15 of May. OpenWrt meetup sometime between 8 and 14 of May. If someone wants to do presentations or workshops we can do this also as part of the Battlemesh and offer it to everyone joining Battlemesh too. The main purpose of such a meetup would be to to align on some strategies on what to do next in OpenWrt and how to do it from my point of view. The advantage of doing it around Battlemesh is that we have to organize less ourselves. What do you think about this plan? Who would join such a meetup? Sorry for delaying this so much. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uqmi] fix uloop initialization
Hi Leon, Please add a prefix for which application with patch is next time. git format-patch origin/master --subject-prefix="PATCH uqmi" On 11/27/22 09:38, Leon M. Busch-George wrote: uloop_init is already called in main. uloop_done is just missing. Signed-off-by: Leon M. Busch-George --- dev.c | 2 -- main.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev.c b/dev.c index bd10207..9eb7209 100644 --- a/dev.c +++ b/dev.c @@ -353,8 +353,6 @@ int qmi_device_open(struct qmi_dev *qmi, const char *path) struct ustream *us = >sf.stream; int fd; - uloop_init(); - fd = open(path, O_RDWR | O_EXCL | O_NONBLOCK | O_NOCTTY); if (fd < 0) return -1; I am not familiar with the uqmi code. Should we move the uloop handling completely to the dev.c file? diff --git a/main.c b/main.c index aa4634c..e3ccf08 100644 --- a/main.c +++ b/main.c @@ -168,5 +168,7 @@ int main(int argc, char **argv) qmi_device_close(); + uloop_done(); + return ret; } Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [ubus PATCH] libubus: remove global variables
Hi Simon,
On 1/5/23 15:30, Simon Tate wrote:
Remove the use of global blob_buf and blob_attr variables to allow
for better thread safety with a ctx per thread on client invoke
and sends.
Add the same variables to within each calling function's scope,
encapsulating the memory usage there.
Fixes a multithreaded use case and has been verified 10,000
threads multiple times running invokes and send events.
I like this approach. The disadvantage is that we have more mallocs in
the code now. Before the global b variable had a pointer to the heap
which was reused, now we always start with a small buffer on the heap
and then have to realloc to increase it and free it up when the function
terminates.
The OpenWrt applications do not make much use of pthreads, but if your
application is such a change is helpful. I think we can effort the extra
overhead of the extra mallocs and frees.
I also found there many style problems and some problems in error paths
in the code.
Signed-off-by: Simon Tate
---
cli.c | 38 --
libubus-internal.h | 2 +-
libubus-io.c | 10 ---
libubus-obj.c | 63 ++-
libubus-req.c | 44 +-
libubus-sub.c | 13 ++---
libubus.c | 67 ++
7 files changed, 161 insertions(+), 76 deletions(-)
diff --git a/cli.c b/cli.c
index 81591ec..e6d7a1b 100644
--- a/cli.c
+++ b/cli.c
@@ -16,7 +16,6 @@
#include
#include "libubus.h"
-static struct blob_buf b;
static int listen_timeout;
static int timeout = 30;
static bool simple_output = false;
@@ -140,18 +139,29 @@ static int ubus_cli_call(struct ubus_context *ctx, int
argc, char **argv)
if (argc < 2 || argc > 3)
return -2;
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
if (argc == 3 && !blobmsg_add_json_from_string(, argv[2])) {
if (!simple_output)
fprintf(stderr, "Failed to parse message data\n");
- return -1;
+ ret = -1;
+ goto error;
}
ret = ubus_lookup_id(ctx, argv[0], );
- if (ret)
- return ret;
+ if (ret) {
+ goto error;
+ }
Please do not use brackets for only one statement. This is part of the
Linux kernel code style which is used here. There are multiple places
where you do not have to add them.
+
+ ret = ubus_invoke(ctx, id, argv[1], b.head, receive_call_result_data,
NULL, timeout * 1000);
+ if (ret) {
+ goto error;
+ }
- return ubus_invoke(ctx, id, argv[1], b.head, receive_call_result_data, NULL, timeout * 1000);
+error:
+ blob_buf_free();
+
+ return ret;
}
struct cli_listen_data {
@@ -265,15 +275,23 @@ static int ubus_cli_send(struct ubus_context *ctx, int
argc, char **argv)
if (argc < 1 || argc > 2)
return -2;
+ int ret = UBUS_STATUS_OK;
Initialization is not needed here.
Please move the "int ret;" to the beginning of the function.
+
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
if (argc == 2 && !blobmsg_add_json_from_string(, argv[1])) {
if (!simple_output)
fprintf(stderr, "Failed to parse message data\n");
- return -1;
+ ret = -1;
+ goto error;
}
- return ubus_send_event(ctx, argv[0], b.head);
+ ret = ubus_send_event(ctx, argv[0], b.head);
+
+error:
+ blob_buf_free();
+ return ret;
}
struct cli_wait_data {
@@ -428,6 +446,7 @@ ubus_cli_get_monitor_data(struct blob_attr *data)
struct blob_attr *tb[UBUS_ATTR_MAX];
int i;
+ struct blob_buf b = { 0 };
blob_buf_init(, 0);
blob_parse(data, tb, policy, UBUS_ATTR_MAX);
@@ -454,7 +473,10 @@ ubus_cli_get_monitor_data(struct blob_attr *data)
}
}
- return blobmsg_format_json(b.head, true);
+ char* ret = blobmsg_format_json(b.head, true);
+
+ blob_buf_free();
+ return ret;
}
static void
diff --git a/libubus-internal.h b/libubus-internal.h
index 24477a0..5b23668 100644
--- a/libubus-internal.h
+++ b/libubus-internal.h
@@ -17,7 +17,7 @@
extern struct blob_buf b;
extern const struct ubus_method watch_method;
-struct blob_attr **ubus_parse_msg(struct blob_attr *msg, size_t len);
+void ubus_parse_msg(struct blob_attr *msg, size_t len, struct blob_attr
**attrbuf, size_t attrbuf_len);
bool ubus_validate_hdr(struct ubus_msghdr *hdr);
void ubus_handle_data(struct uloop_fd *u, unsigned int events);
int ubus_send_msg(struct ubus_context *ctx, uint32_t seq,
diff --git a/libubus-io.c b/libubus-io.c
index 3561ac4..143d3be 100644
--- a/libubus-io.c
+++ b/libubus-io.c
@@ -41,12 +41,10 @@ static const struct blob_attr_info
ubus_policy[UBUS_ATTR_MAX] = {
Re: [PATCH v2] mvebu: add support for Fortinet FortiGate 50E
On 3/1/23 17:01, INAGAKI Hiroshi wrote: Fortinet FortiGate 50E (FG-50E) is a UTM, based on Armada 385 (88F6820). Notes: - All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of WAN1/2 are connected to GPIO expander. There is no way to indicate link speed of networking device, so those LEDs cannot be used like stock firmware. I think you can use the ledtrig-netdev to activate the LEDs on link up if they are connected to the nxp,pca9555 GPIO extender. - Both colors of Bi-color LEDs on the front panel cannot be turned on at the same time. - "PWR" and "Logo" LEDs are connected to power source directory. - The following partitions are added for OpenWrt. These partitions are contained in "uboot" partition (0x0-0x1f) on stock firmware. - "firmware-info" - "dtb" - "u-boot-env" - "board-info" . +define Device/fortinet_fg-50e + DEVICE_VENDOR := Fortinet + DEVICE_MODEL := FortiGate 50E + SOC := armada-385 + KERNEL := kernel-bin | append-dtb + KERNEL_INITRAMFS := kernel-bin | append-dtb | fortigate-header | \ +gzip-filename FGT50E + KERNEL_SIZE := 6144k + DEVICE_DTS := armada-385-fortinet-fg-50e + IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | \ +sysupgrade-tar rootfs=@ | append-metadata + DEVICE_PACKAGES := kmod-hwmon-nct7802 Why don't you add the driver for the GPIO extender kmod-gpio-pca953x here? +endef +TARGET_DEVICES += fortinet_fg-50e + define Device/globalscale_mirabox $(Device/NAND-512K) DEVICE_VENDOR := Globalscale ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mt7621: move uboot-envtools to DEFAULT_PACKAGES
On 2/27/23 13:38, Bjørn Mork wrote:
Several devices depend on fw_printenv during sysupgrade. Make sure
it always is present in all images, including initramfs images built
by the buildbots.
Fixes: 2449a632084b ("ramips: mt7621: Add support for ZyXEL NR7101")
Signed-off-by: Bjørn Mork
---
Changes since v1:
- rebased onto current master
target/linux/ramips/image/mt7621.mk | 68
target/linux/ramips/mt7621/target.mk | 2 +-
2 files changed, 29 insertions(+), 41 deletions(-)
.
diff --git a/target/linux/ramips/mt7621/target.mk
b/target/linux/ramips/mt7621/target.mk
index cfb798e35852..153ff08421d6 100644
--- a/target/linux/ramips/mt7621/target.mk
+++ b/target/linux/ramips/mt7621/target.mk
@@ -10,7 +10,7 @@ KERNELNAME:=vmlinux vmlinuz
# make Kernel/CopyImage use $LINUX_DIR/vmlinuz
IMAGES_DIR:=../../..
-DEFAULT_PACKAGES += wpad-basic-mbedtls
+DEFAULT_PACKAGES += wpad-basic-mbedtls uboot-envtools
define Target/Description
Build firmware images for Ralink MT7621 based boards.
This will add uboot-envtools to all devices. uboot-envtools is not
included in all DEVICE_PACKAGES now, should we explicitly remove it from
device definitions which do not had it before?
The Device/adslr_g7 for example does not add uboot-envtools in its
DEVICE_PACKAGES.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] octeontx: add f2fs and ext4 support
On 2/26/23 18:26, Hauke Mehrtens wrote: On 2/22/23 00:08, Tim Harvey wrote: Add both ext4 and f2fs support for overlayfs. The fstools mount_root application will choose f2fs if the overlay volume space available exceeds 100MB, otherwise ext4 is used. Signed-off-by: Tim Harvey --- target/linux/octeontx/Makefile | 3 ++- target/linux/octeontx/config-5.15 | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/octeontx/Makefile b/target/linux/octeontx/Makefile index 25096c90ba96..57250a5e01ca 100644 --- a/target/linux/octeontx/Makefile +++ b/target/linux/octeontx/Makefile @@ -20,7 +20,8 @@ include $(INCLUDE_DIR)/target.mk KERNELNAME:=Image -DEFAULT_PACKAGES += kmod-hwmon-gsc kmod-leds-gpio kmod-pps-gpio \ +DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid \ + kmod-hwmon-gsc kmod-leds-gpio kmod-pps-gpio \ kmod-gpio-button-hotplug kmod-input-evdev kmod-rtc-ds1672 \ kmod-can kmod-can-mcp251x This patch is not applying for me: - Applying: octeontx: add f2fs and ext4 support error: sha1 information is lacking or useless (target/linux/octeontx/Makefile). error: could not build fake ancestor Patch failed at 0001 octeontx: add f2fs and ext4 support - I saw that this depends on the other patch you send. I applied both of them now. Why do you add uboot-envtools? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] arm64: only enable BHI mitigation on affected CPUs
On 11/7/22 07:36, DENG Qingfang wrote:
When kernel 5.15 support was added, a new config symbol for ARM64 BHI
mitigation was enabled, which was also later backported to 5.10. However,
only a few CPUs are affected by BHI [0].
Disable it by default, and enable it only on Cortex-A72 targets.
[0] https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB
Fixes: 9a038e7fd12e ("generic: 5.15: copy config and patch from 5.10")
Fixes: 048f0b170296 ("kernel: bump 5.10 to 5.10.105")
Signed-off-by: DENG Qingfang
---
target/linux/bcm27xx/bcm2711/config-5.15 | 1 +
target/linux/generic/config-5.10 | 2 +-
target/linux/generic/config-5.15 | 2 +-
target/linux/mvebu/cortexa72/config-5.10 | 1 +
target/linux/mvebu/cortexa72/config-5.15 | 1 +
5 files changed, 5 insertions(+), 2 deletions(-)
Sorry for the late answer.
Please rebase this patch, it does not apply any more.
The armvirt and the layerscape target could also run on out of order
CPUs. For octeontx I am not sure.
Please activate it there too.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mt7621: move uboot-envtools to DEFAULT_PACKAGES
On 11/17/22 18:21, Bjørn Mork wrote:
Several devices depend on fw_printenv during sysupgrade. Make sure
it always is present in all images, including initramfs images built
by the buildbots.
Fixes: 2449a632084b ("ramips: mt7621: Add support for ZyXEL NR7101")
Signed-off-by: Bjørn Mork
---
target/linux/ramips/image/mt7621.mk | 55 +---
target/linux/ramips/mt7621/target.mk | 2 +-
2 files changed, 27 insertions(+), 30 deletions(-)
Hi Bjørn,
Sorry for the delay, this looks good, but it does not apply any more,
could you please rebase it on top of current master.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] sunxi: enable CONFIG_NVMEM_SYSFS
On 12/30/22 17:47, Robert Marko wrote: On Fri, 30 Dec 2022 at 03:41, Jan-Niklas Burfeind wrote: in both the stable and the testing kernel h2+/h3/h5 devices have a Secure ID that can be read from `/sys/bus/nvmem/devices/sunxi-sid0/nvmem`. Enabling CONFIG_NVMEM_SYSFS grants sysfs access from userspace. Signed-off-by: Jan-Niklas Burfeind --- Hauke suggested enabling it for the whole sunxi target, as all devices either have enough onboard or external memory to cope with the additional 5KB. @robimarko I split off the the changes into two commits which can be found here: https://github.com/openwrt/openwrt/compare/master...AiyionPrime:openwrt:sunxi-nvmem_sysfs I've left the first commit including all unrelated kernel settings aside, due to build failures. Something is rather broken in your build environment to get that diff, I just tried refreshing sunxi generic config and A7 config and the diff is minimal and it builds fine: diff --git a/target/linux/sunxi/config-5.10 b/target/linux/sunxi/config-5.10 index caac9e1436..4ce089b53c 100644 --- a/target/linux/sunxi/config-5.10 +++ b/target/linux/sunxi/config-5.10 @@ -113,6 +113,7 @@ CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG=y # CONFIG_CRYPTO_DEV_SUN8I_CE is not set # CONFIG_CRYPTO_DEV_SUN8I_SS is not set CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y CONFIG_CRYPTO_LIB_DES=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_RNG=y @@ -177,6 +178,7 @@ CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_CPU_VULNERABILITIES=y CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_IDLE_POLL_SETUP=y @@ -385,8 +387,6 @@ CONFIG_RESET_SUNXI=y CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RWSEM_SPIN_ON_OWNER=y -CONFIG_SATA_HOST=y -CONFIG_SATA_PMP=y CONFIG_SCSI=y CONFIG_SDIO_UART=y CONFIG_SECURITYFS=y @@ -495,8 +495,6 @@ CONFIG_VFPv3=y CONFIG_VHOST=y CONFIG_VHOST_IOTLB=y CONFIG_VHOST_NET=y -# CONFIG_VIDEO_SUN4I_CSI is not set -# CONFIG_VIDEO_SUN6I_CSI is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_VT=y CONFIG_VT_CONSOLE=y diff --git a/target/linux/sunxi/cortexa7/config-5.10 b/target/linux/sunxi/cortexa7/config-5.10 index 90e977b566..553770d6ba 100644 --- a/target/linux/sunxi/cortexa7/config-5.10 +++ b/target/linux/sunxi/cortexa7/config-5.10 @@ -1,7 +1,6 @@ CONFIG_B53=y CONFIG_B53_MDIO_DRIVER=y CONFIG_CRYPTO_BLAKE2S=y -CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y CONFIG_DWMAC_SUN8I=y CONFIG_GRO_CELLS=y # CONFIG_MACH_SUN4I is not set @@ -17,7 +16,6 @@ CONFIG_NET_DSA_TAG_BRCM_LEGACY=y CONFIG_NET_DSA_TAG_BRCM_PREPEND=y CONFIG_NET_SWITCHDEV=y CONFIG_NOP_USB_XCEIV=y -CONFIG_RTC_DRV_SUN6I=y CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_HDRC=y Regards, Robert Hi Robert, I think he just added the CONFIG_NVMEM_SYSFS changes to the commit and not the unrelated changes to the kernel configuration. I think that is fine. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] hostapd: add support for unicast beacons
On 1/9/23 14:47, Raphaël Mélotte wrote: Also refresh patches. Upstream status: https://patchwork.ozlabs.org/project/hostap/patch/20230105200945.761324-1-raphael.melo...@mind.be/ Signed-off-by: Raphaël Mélotte --- .../620-add-support-for-unicast-beacons.patch | 70 +++ .../hostapd/patches/700-wifi-reload.patch | 2 +- .../patches/720-iface_max_num_sta.patch | 2 +- ...750-qos_map_set_without_interworking.patch | 2 +- 4 files changed, 73 insertions(+), 3 deletions(-) create mode 100644 package/network/services/hostapd/patches/620-add-support-for-unicast-beacons.patch The patch is marked as "Changes Requested" in upstream hostapd. Please answer Joni to get this change into upstream hostapd first. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] hostapd: add option to ignore data frames from unknown stations
On 1/26/23 11:04, Raphaël Mélotte wrote: Also refresh patches. Upstream hostapd status: https://patchwork.ozlabs.org/project/hostap/patch/20230126091539.2325752-1-raphael.melo...@mind.be/ Signed-off-by: Raphaël Mélotte --- ...-ignore-data-frames-from-unknown-sta.patch | 72 +++ .../hostapd/patches/700-wifi-reload.patch | 2 +- .../patches/720-iface_max_num_sta.patch | 2 +- 3 files changed, 74 insertions(+), 2 deletions(-) create mode 100644 package/network/services/hostapd/patches/630-add-ignore-data-frames-from-unknown-sta.patch The patch is marked as "Changes Requested" in upstream hostapd. Please answer Joni to get this change into upstream hostapd first. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] octeontx: add f2fs and ext4 support
On 2/22/23 00:08, Tim Harvey wrote: Add both ext4 and f2fs support for overlayfs. The fstools mount_root application will choose f2fs if the overlay volume space available exceeds 100MB, otherwise ext4 is used. Signed-off-by: Tim Harvey --- target/linux/octeontx/Makefile| 3 ++- target/linux/octeontx/config-5.15 | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/octeontx/Makefile b/target/linux/octeontx/Makefile index 25096c90ba96..57250a5e01ca 100644 --- a/target/linux/octeontx/Makefile +++ b/target/linux/octeontx/Makefile @@ -20,7 +20,8 @@ include $(INCLUDE_DIR)/target.mk KERNELNAME:=Image -DEFAULT_PACKAGES += kmod-hwmon-gsc kmod-leds-gpio kmod-pps-gpio \ +DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid \ + kmod-hwmon-gsc kmod-leds-gpio kmod-pps-gpio \ kmod-gpio-button-hotplug kmod-input-evdev kmod-rtc-ds1672 \ kmod-can kmod-can-mcp251x This patch is not applying for me: - Applying: octeontx: add f2fs and ext4 support error: sha1 information is lacking or useless (target/linux/octeontx/Makefile). error: could not build fake ancestor Patch failed at 0001 octeontx: add f2fs and ext4 support - Why do you add uboot-envtools? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: replace out-of-tree hwmon-gsc driver with in-tree
On 2/18/23 01:24, Tim Harvey wrote: The Gateworks GSC drivers were merged in Linux v5.8: - remove the old out-of-tree module - add configuration for the in-tree modules Signed-off-by: Tim Harvey --- package/kernel/hwmon-gsc/Makefile | 28 --- package/kernel/hwmon-gsc/src/Makefile | 1 - package/kernel/hwmon-gsc/src/gsc.c| 308 -- package/kernel/linux/modules/hwmon.mk | 18 ++ 4 files changed, 18 insertions(+), 337 deletions(-) delete mode 100644 package/kernel/hwmon-gsc/Makefile delete mode 100644 package/kernel/hwmon-gsc/src/Makefile delete mode 100644 package/kernel/hwmon-gsc/src/gsc.c . diff --git a/package/kernel/linux/modules/hwmon.mk b/package/kernel/linux/modules/hwmon.mk index c8d79b622e7a..c8887a84827a 100644 --- a/package/kernel/linux/modules/hwmon.mk +++ b/package/kernel/linux/modules/hwmon.mk @@ -108,6 +108,24 @@ endef $(eval $(call KernelPackage,hwmon-drivetemp)) +define KernelPackage/hwmon-gsc + TITLE:=Gateworks System Controller support + KCONFIG:=CONFIG_SENSORS_GSC \ +CONFIG_MFD_GATEWORKS_GSC=y Please build CONFIG_MFD_GATEWORKS_GSC as a kernel module and not into the kenrel. + FILES:= \ + $(LINUX_DIR)/drivers/mfd/gateworks-gsc.ko \ + $(LINUX_DIR)/drivers/hwmon/gsc-hwmon.ko + AUTOLOAD:=$(call AutoLoad,60,gateworks-gsc gsc-hwmon) + $(call AddDepends/hwmon,+kmod-i2c-core) +endef + +define KernelPackage/hwmon-gsc/description + Kernel module for Gateworks System Controller with temperature sensor, ADCs, and FAN controller Please add a line break here. +endef + +$(eval $(call KernelPackage,hwmon-gsc)) + + define KernelPackage/hwmon-gpiofan TITLE:=Generic GPIO FAN support KCONFIG:=CONFIG_SENSORS_GPIO_FAN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH ustream-ssl v2] ustream-mbedtls: Use getrandom() instead of /dev/urandom
Instead of keeping a file descriptor open just use the getrandom syscall
to get random data. This is supported by the musl, glibc and Linux for
some time now.
This also improves the error handling in case this function returns not
as many bytes as expected.
Signed-off-by: Hauke Mehrtens
---
ustream-mbedtls.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
changes since v1:
* rename _urandom to _random
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index e79e37b..7fc7874 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -17,6 +17,7 @@
*/
#include
+#include
#include
#include
#include
@@ -25,8 +26,6 @@
#include "ustream-ssl.h"
#include "ustream-internal.h"
-static int urandom_fd = -1;
-
static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
{
struct ustream *s = ctx;
@@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx,
void *ssl, struct ustr
mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
}
-static bool urandom_init(void)
+static int _random(void *ctx, unsigned char *out, size_t len)
{
- if (urandom_fd > -1)
- return true;
+ ssize_t ret;
- urandom_fd = open("/dev/urandom", O_RDONLY);
- if (urandom_fd < 0)
- return false;
-
- return true;
-}
-
-static int _urandom(void *ctx, unsigned char *out, size_t len)
-{
- if (read(urandom_fd, out, len) < 0)
+ ret = getrandom(out, len, 0);
+ if (ret < 0 || (size_t)ret != len)
return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
return 0;
@@ -134,9 +124,6 @@ __ustream_ssl_context_new(bool server)
mbedtls_ssl_config *conf;
int ep;
- if (!urandom_init())
- return NULL;
-
ctx = calloc(1, sizeof(*ctx));
if (!ctx)
return NULL;
@@ -159,7 +146,7 @@ __ustream_ssl_context_new(bool server)
mbedtls_ssl_config_defaults(conf, ep, MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
- mbedtls_ssl_conf_rng(conf, _urandom, NULL);
+ mbedtls_ssl_conf_rng(conf, _random, NULL);
if (server) {
mbedtls_ssl_conf_authmode(conf, MBEDTLS_SSL_VERIFY_NONE);
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
Hi Torsten, Sorry for the late answer, I forgot about this mail thread. On 1/30/23 10:57, Torsten Duwe wrote: Hi Hauke! On Sun, 29 Jan 2023 17:08:38 +0100 Hauke Mehrtens wrote: drivers/char/random.c lines 1240- ... * Reading from /dev/urandom has the same functionality as calling * getrandom(2) with flags=GRND_INSECURE. Because it does not block * waiting for the RNG to be ready, it should not be used. Haven't audited mbedtls, but I assume it reads urandom for "lesser" entropy when needed. In any case, getrandom(out, len, GRND_INSECURE) would be the proper replacement. Torsten Hi Torsten, The mapage says this: > By default, getrandom() draws entropy from the urandom source > (i.e., the same source as the /dev/urandom device). This > behavior can be changed via the flags argument. https://man7.org/linux/man-pages/man2/getrandom.2.html GRND_INSECURE is also not documented in the man page. Well, it exists in the kernel source and headers... The option was added to the Linux kernel 5.6 here: https://git.kernel.org/linus/75551dbf112c992bc6c99a972990b3f272247e23 The documentation says > GRND_INSECUREReturn non-cryptographic random bytes We want to use the random bytes in mbedtls for cryptographic operations. I think giving no flags is the correct option here. I think the behavior of /dev/random changed some years ago. This article described it a bit: https://lwn.net/Articles/808575/ That's only the internal workings. BTW, the mentioned quote of Andy Lutomirski applies here in some sense. You read away the true entropy and might even block on it when pseudo- randomness might suffice, see below. As far as I understood the code, giving no flags will guarantee that the random pool is initialized (crng_ready() returns true) and otherwise it is the same as using GRND_INSECURE. As we use it for cryptographic operations I think we should give no flags. "cryptographic operations" is a wide area. Some randomness is required, to varying degrees, for long-term keys, session keys, IVs and padding. ustreamss uses the randomness to generate session keys (including ephemeral keys), IVs and padding. The long term keys are generated in a different application. Especially for long living keys, each end every bit should be totally unpredictable, which should correspond to read an appropriate amount from /dev/random. IVs and padding can be generated from a pseudo-RNG whose initial state is "uncertain enough", usually /dev/urandom. GIT is cool. c6e9d6f388947986 2014-Jul-17 tytso: introduce getrandom(2) system call 75551dbf112c992b 2019-Dec-23 luto: add GRND_INSECURE ... 48446f198f9adcb4 2019-Dec-23 luto: ignore GRND_RANDOM The first commit also has a man page in the comment, which is probably what was recorded. The second one changes the no-flags behaviour, away from the man page text you quoted. Someone once mentioned on LKML that drivers/char/random.c needs better maintenance... ;) I had a quick look at mbedtls and its usage of the provided rng function. It generates not only padding and IVs, but also session keys. Especially on OpenWRT these are a trade-off IMHO. OpenWRT supports a lot of hardware that is low on entropy at boot (MIPS anyone?) Do you want to block early ssh sessions, maybe even for minutes, or would you rather risk eavesdropping on those early connections? Depending on your choice for ustream, you can keep the proposed code, but please rename the functions to "random", not "urandom". Or you want to stick with the current urandom behaviour but then please add Luto's GRND_INSECURE flag to achieve that. crng_ready() should only return false at bootup before the system got enough random bits, afterwards it never returns false. Even without GRND_INSECURE it will never run out of entropy. I think we should wait with creating TLS sessions till we have enough random data to do it securely. I tested this on a lantiq xrx200 (MIPS) device and it was initialized much before the LAN interface was up. The code in ustream-mbedtls.c was probably initially written when /dev/random was still blocking when too much entropy was read out of the pool. I will rename the function. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 2/5] netifd: Fix multiple -Wsign-compare warnings
This fixes warnings like this:
warning: comparison of integer expressions of different signedness: 'int' and
'long unsigned int' [-Wsign-compare]
Mostly this was an int compared to a size_t returned by ARRAY_SIZE().
The easiest fix is to count on the size_t type.
The ifindex is sometimes an unsigned int and sometimes a signed int in
the kernel interfaces. I think it normally fits into an unsigned 16 bit
value, so this should be fine. Do the one comparison where the
compiler complains as a long.
Casting the result of sizeof() to int should be safe. These values are
never out of range of int.
Signed-off-by: Hauke Mehrtens
---
bonding.c | 2 +-
handler.c | 5 +++--
interface-ip.c | 2 +-
main.c | 4 ++--
system-linux.c | 21 -
ubus.c | 4 ++--
vlan.c | 4 ++--
wireless.c | 2 +-
8 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/bonding.c b/bonding.c
index 457fe51..f4005de 100644
--- a/bonding.c
+++ b/bonding.c
@@ -396,7 +396,7 @@ bonding_apply_settings(struct bonding_device *bdev, struct
blob_attr **tb)
if ((cur = tb[BOND_ATTR_POLICY]) != NULL) {
const char *policy = blobmsg_get_string(cur);
- int i;
+ size_t i;
for (i = 0; i < ARRAY_SIZE(bonding_policy_str); i++) {
if (strcmp(policy, bonding_policy_str[i]) != 0)
diff --git a/handler.c b/handler.c
index 04bdbee..78fc9a0 100644
--- a/handler.c
+++ b/handler.c
@@ -229,7 +229,8 @@ netifd_parse_extdev_handler(const char *path_to_file,
create_extdev_handler_cb c
void netifd_init_script_handlers(int dir_fd, script_dump_cb cb)
{
glob_t g;
- int i, prev_fd;
+ int prev_fd;
+ size_t i;
prev_fd = netifd_dir_push(dir_fd);
if (glob("./*.sh", 0, NULL, )) {
@@ -252,7 +253,7 @@ netifd_init_extdev_handlers(int dir_fd,
create_extdev_handler_cb cb)
prev_fd = netifd_dir_push(dir_fd);
glob("*.json", 0, NULL, );
- for (int i = 0; i < g.gl_pathc; i++)
+ for (size_t i = 0; i < g.gl_pathc; i++)
netifd_parse_extdev_handler(g.gl_pathv[i], cb);
netifd_dir_pop(prev_fd);
}
diff --git a/interface-ip.c b/interface-ip.c
index ab4a5cf..7359db2 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -99,7 +99,7 @@ static struct uloop_timeout valid_until_timeout;
static void
clear_if_addr(union if_addr *a, int mask)
{
- int m_bytes = (mask + 7) / 8;
+ size_t m_bytes = (mask + 7) / 8;
uint8_t m_clear = (1 << (m_bytes * 8 - mask)) - 1;
uint8_t *p = (uint8_t *) a;
diff --git a/main.c b/main.c
index 4c1c855..874dc8b 100644
--- a/main.c
+++ b/main.c
@@ -303,8 +303,8 @@ int main(int argc, char **argv)
break;
case 'l':
log_level = atoi(optarg);
- if (log_level >= ARRAY_SIZE(log_class))
- log_level = ARRAY_SIZE(log_class) - 1;
+ if (log_level >= (int)ARRAY_SIZE(log_class))
+ log_level = (int)ARRAY_SIZE(log_class) - 1;
break;
#ifndef DUMMY_MODE
case 'S':
diff --git a/system-linux.c b/system-linux.c
index 45a9efb..d13a561 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -1154,7 +1154,7 @@ static bool check_ifaddr(struct nlmsghdr *hdr, int
ifindex)
{
struct ifaddrmsg *ifa = NLMSG_DATA(hdr);
- return ifa->ifa_index == ifindex;
+ return (long)ifa->ifa_index == ifindex;
}
static bool check_route(struct nlmsghdr *hdr, int ifindex)
@@ -1438,7 +1438,8 @@ int system_macvlan_add(struct device *macvlan, struct
device *dev, struct macvla
{
struct nl_msg *msg;
struct nlattr *linkinfo, *data;
- int i, rv;
+ size_t i;
+ int rv;
static const struct {
const char *name;
enum macvlan_mode val;
@@ -1700,7 +1701,7 @@ system_set_ethtool_settings(struct device *dev, struct
device_settings *s)
.ifr_data = (caddr_t),
};
static const struct {
- int speed;
+ unsigned int speed;
uint8_t bit_half;
uint8_t bit_full;
} speed_mask[] = {
@@ -1709,7 +1710,7 @@ system_set_ethtool_settings(struct device *dev, struct
device_settings *s)
{ 1000, ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
ETHTOOL_LINK_MODE_1000baseT_Full_BIT },
};
uint32_t adv;
- int i;
+ size_t i;
strncpy(ifr.ifr_name, dev->ifname, sizeof(ifr.ifr_name) - 1);
@@ -2355,7 +2356,7 @@ static const struct {
static void system_add_link_modes(struct blob_buf *b, __u32 mask)
{
- int i;
+ size_t i;
for (i = 0; i < ARRAY_SIZE(ethtool_link_modes); i++) {
if (mask & ethtool_link_modes[i].mask)
[PATCH netifd 4/5] netifd: Explicitly zero initialize variables
The -pedantic option was complaining about the old initialization and
prefers if it is explicitly initialized to zero.
Signed-off-by: Hauke Mehrtens
---
proto.c| 2 +-
system-linux.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/proto.c b/proto.c
index 01473f2..48dd213 100644
--- a/proto.c
+++ b/proto.c
@@ -416,7 +416,7 @@ proto_apply_static_ip_settings(struct interface *iface,
struct blob_attr *attr)
unsigned int netmask = 32;
bool ip6deprecated;
int n_v4 = 0, n_v6 = 0;
- struct in_addr bcast = {}, ptp = {};
+ struct in_addr bcast = {0,}, ptp = {0,};
blobmsg_parse(proto_ip_attributes, __OPT_MAX, tb, blob_data(attr),
blob_len(attr));
diff --git a/system-linux.c b/system-linux.c
index d13a561..e4041fb 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -1529,7 +1529,7 @@ int system_netns_set(int netns_fd)
int system_veth_add(struct device *veth, struct veth_config *cfg)
{
struct nl_msg *msg;
- struct ifinfomsg empty_iim = {};
+ struct ifinfomsg empty_iim = {0,};
struct nlattr *linkinfo, *data, *veth_info;
int rv;
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 5/5] netifd: Activate -Wextra compile warnings
This activates some more compile warnings.
-pedantic is not yet activated, then we see too many errors which I do
not know how to mitigate.
Signed-off-by: Hauke Mehrtens
---
CMakeLists.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b3bf411..b87c300 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,7 +7,11 @@ IF(NOT ${CMAKE_VERSION} LESS 3.0)
check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
ENDIF()
-ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -Wmissing-declarations
-Wno-unknown-warning-option -Wno-format-truncation)
+ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -Wmissing-declarations
-Wno-unused-parameter -Wno-unused-but-set-parameter)
+IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
+ add_definitions(-Wextra -Werror=implicit-function-declaration)
+ add_definitions(-Wformat -Werror=format-security
-Werror=format-nonliteral)
+ENDIF()
IF(HAS_IMPLICIT_FALLTHROUGH)
ADD_DEFINITIONS(-Wimplicit-fallthrough)
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 3/5] netifd: Do not return values in void function
These two functions return void, do not try to return a parameter.
Signed-off-by: Hauke Mehrtens
---
interface-event.c | 6 --
main.c| 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/interface-event.c b/interface-event.c
index a40f6dc..b03bfbc 100644
--- a/interface-event.c
+++ b/interface-event.c
@@ -49,8 +49,10 @@ run_cmd(const char *ifname, const char *device, enum
interface_event event,
int pid;
pid = fork();
- if (pid < 0)
- return task_complete(NULL, -1);
+ if (pid < 0) {
+ task_complete(NULL, -1);
+ return;
+ }
if (pid > 0) {
task.pid = pid;
diff --git a/main.c b/main.c
index 874dc8b..e5260b5 100644
--- a/main.c
+++ b/main.c
@@ -129,7 +129,8 @@ netifd_process_cb(struct uloop_process *proc, int ret)
np = container_of(proc, struct netifd_process, uloop);
netifd_delete_process(np);
- return np->cb(np, ret);
+ np->cb(np, ret);
+ return;
}
int
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 1/5] netifd: bridge: Fix format string position
This fixes the following compile error: error: format not a string literal, argument types not checked [-Werror=format-nonliteral] blobmsg_printf() has the following signature: int blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...) Signed-off-by: Hauke Mehrtens --- bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bridge.c b/bridge.c index 7e61b9d..ae305e8 100644 --- a/bridge.c +++ b/bridge.c @@ -934,7 +934,7 @@ bridge_dump_port(struct blob_buf *b, struct bridge_vlan_port *port) bool tagged = !(port->flags & BRVLAN_F_UNTAGGED); bool pvid = (port->flags & BRVLAN_F_PVID); - blobmsg_printf(b, "%s%s%s%s\n", port->ifname, + blobmsg_printf(b, NULL, "%s%s%s%s\n", port->ifname, tagged || pvid ? ":" : "", tagged ? "t" : "", pvid ? "*" : ""); -- 2.39.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 0/5] Fix some compiler warnings
This fixes some compiler warnings and activates -Wextra by default now. Hauke Mehrtens (5): netifd: bridge: Fix format string position netifd: Fix multiple -Wsign-compare warnings netifd: Do not return values in void function netifd: Explicitly zero initialize variables netifd: Activate -Wextra compile warnings CMakeLists.txt| 6 +- bonding.c | 2 +- bridge.c | 2 +- handler.c | 5 +++-- interface-event.c | 6 -- interface-ip.c| 2 +- main.c| 7 --- proto.c | 2 +- system-linux.c| 23 +-- ubus.c| 4 ++-- vlan.c| 4 ++-- wireless.c| 2 +- 12 files changed, 38 insertions(+), 27 deletions(-) -- 2.39.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm47xx: relocate LZMA loader #2
On 2/7/23 15:06, Rafał Miłecki wrote:
From: Rafał Miłecki
Increased size of the 5.15 kernel requires bumping BZ_TEXT_START again.
Without this CFE hangs at the:
Starting program at 0x80001000
This fixes booting 5.15 based mips74k images on:
1. BCM4706 (Luxul XWR-1750)
2. BCM5357B0 (Linksys E1000 V2.1)
3. BCM47186B0 (Luxul XWR-600)
It isn't needed but also doesn't break:
1. BCM5354 (Asus WL-500gP V2)
Ref: 4cd97e476089 ("bcm47xx: relocate LZMA loader")
Cc: Hauke Mehrtens
Signed-off-by: Rafał Miłecki
Acked-by: Hauke Mehrtens
Maybe we should increase this even more, then we do not have to change
this again next year.
Does setting BZ_TEXT_START to 0x80D0 also work?
I do not think this has any disadvantages.
---
target/linux/bcm47xx/image/lzma-loader/src/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
index a3e7ae1c92..44891a7ab0 100644
--- a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
+++ b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
@@ -18,8 +18,8 @@
#
TEXT_START := 0x80001000
-BZ_TEXT_START := 0x8070
-BZ_STACK_START := 0x8080
+BZ_TEXT_START := 0x8080
+BZ_STACK_START := 0x8090
OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R .note -R .comment -R .mdebug -S
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release Goals 23.x?
On 1/24/23 20:48, Nick wrote: Hey, We have testing-support for 5.15 in almost all targets, so we may be able to release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. Binutils has been updated to version 2.40. Could we fill out the Release Goals page [3]? It would be great to see a new release. Hi Nick, I think nobody wrote down a release goal page yet. It was discussed here too: https://openwrt.org/meetings/20221130#next_release_23xx https://openwrt.org/meetings/20230124#next_release_23xx There are still some open topic for the next release, but it looks good for me. * make remaining targets use kernel 5.15 by default: ** rampis: Fix problems ** lantoq: Fix DSA driver ** Fix some other problems with other targets. * Add OpenSSL 3.0 * Merge risc-v support I assume that we will be ready in about 2 months with these tasks and can create the release branch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ramips: add support for Huasifei WS1208V2
On 1/27/23 14:57, arinc9.u...@gmail.com wrote:
From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM, 16 MiB SPI Flash
- MT7603EN 2.4 GHz & MT7612EN 5 GHz WLAN
- Quectel RM520N-GL Cellular Modem
- 2 WLAN & 4 Cellular Antennas
- 5 Gigabit Ethernet Ports
- 1 USB 2.0 port
- 1 PCI-E Slot
- 1 M.2 slot
- 1 SIM card slot
- 1 SD card slot
Installation:
- Install sysupgrade image via ROOter OS.
TFTP Recovery:
- Connect to serial console.
- Boot initramfs image by choosing option 1 when U-Boot prompts.
- Install sysupgrade image via OpenWrt.
Link: https://www.huasifei.com/a/Products/5G%20CPE/240.html
Signed-off-by: Arınç ÜNAL
---
v2: Add recovery information.
---
.../ramips/dts/mt7621_huasifei_ws1208v2.dts | 187 ++
target/linux/ramips/image/mt7621.mk | 12 ++
.../mt7621/base-files/etc/board.d/01_leds | 3 +
3 files changed, 202 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
diff --git a/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
b/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
new file mode 100644
index 00..c69f05a0f4
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_huasifei_ws1208v2.dts
@@ -0,0 +1,187 @@
.
+ {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_factory_e000: macaddr@e000 {
+ reg = <0xe000 0x6>;
+ };
+};
Please move this directly where you defined the factory partition in the
partitions node.
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 2269833e48..bbd25e5be0 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -996,6 +996,18 @@ define Device/humax_e10
endef
TARGET_DEVICES += humax_e10
+define Device/huasifei_ws1208v2
+ $(Device/dsa-migration)
+ $(Device/uimage-lzma-loader)
+ IMAGE_SIZE := 16064k
+ DEVICE_VENDOR := Huasifei
+ DEVICE_MODEL := WS1208V2
+ DEVICE_PACKAGES := kmod-ata-ahci kmod-mt7603 kmod-mt76x2 kmod-sdhci-mt7620 \
+ kmod-usb3 kmod-usb-net-cdc-mbim kmod-usb-net-qmi-wwan \
+ kmod-usb-serial-option -wpad-basic-wolfssl
Why do you remove wpad-basic-wolfssl?
What is kmod-usb-net-cdc-mbim needed for?
+endef
+TARGET_DEVICES += huasifei_ws1208v2
+
define Device/iodata_wn-ax1167gr
$(Device/dsa-migration)
$(Device/uimage-lzma-loader)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
On 1/29/23 15:13, Torsten Duwe wrote:
On Sat, 28 Jan 2023 19:41:13 +0100
Hauke Mehrtens wrote:
Instead of keeping a file descriptor open just use the getrandom syscall
to get random data. This is supported by the musl, glibc and Linux for
some time now.
This also improves the error handling in case this function returns not
as many bytes as expected.
Signed-off-by: Hauke Mehrtens
---
ustream-mbedtls.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index e79e37b..51ba2fa 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -17,6 +17,7 @@
*/
#include
+#include
#include
#include
#include
@@ -25,8 +26,6 @@
#include "ustream-ssl.h"
#include "ustream-internal.h"
-static int urandom_fd = -1;
-
static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
{
struct ustream *s = ctx;
@@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx,
void *ssl, struct ustr
mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
}
-static bool urandom_init(void)
-{
- if (urandom_fd > -1)
- return true;
-
- urandom_fd = open("/dev/urandom", O_RDONLY);
- if (urandom_fd < 0)
- return false;
-
- return true;
-}
-
static int _urandom(void *ctx, unsigned char *out, size_t len)
{
- if (read(urandom_fd, out, len) < 0)
+ ssize_t ret;
+
+ ret = getrandom(out, len, 0);
+ if (ret < 0 || (size_t)ret != len)
return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
[...]
drivers/char/random.c lines 1240- ...
* Reading from /dev/urandom has the same functionality as calling
* getrandom(2) with flags=GRND_INSECURE. Because it does not block
* waiting for the RNG to be ready, it should not be used.
Haven't audited mbedtls, but I assume it reads urandom for "lesser"
entropy when needed. In any case, getrandom(out, len, GRND_INSECURE)
would be the proper replacement.
Torsten
Hi Torsten,
The mapage says this:
> By default, getrandom() draws entropy from the urandom source
> (i.e., the same source as the /dev/urandom device). This
> behavior can be changed via the flags argument.
https://man7.org/linux/man-pages/man2/getrandom.2.html
GRND_INSECURE is also not documented in the man page.
The option was added to the Linux kernel 5.6 here:
https://git.kernel.org/linus/75551dbf112c992bc6c99a972990b3f272247e23
The documentation says
> GRND_INSECURE Return non-cryptographic random bytes
We want to use the random bytes in mbedtls for cryptographic operations.
I think giving no flags is the correct option here.
I think the behavior of /dev/random changed some years ago. This article
described it a bit: https://lwn.net/Articles/808575/
As far as I understood the code, giving no flags will guarantee that the
random pool is initialized (crng_ready() returns true) and otherwise it
is the same as using GRND_INSECURE. As we use it for cryptographic
operations I think we should give no flags.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom
Instead of keeping a file descriptor open just use the getrandom syscall
to get random data. This is supported by the musl, glibc and Linux for
some time now.
This also improves the error handling in case this function returns not
as many bytes as expected.
Signed-off-by: Hauke Mehrtens
---
ustream-mbedtls.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index e79e37b..51ba2fa 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -17,6 +17,7 @@
*/
#include
+#include
#include
#include
#include
@@ -25,8 +26,6 @@
#include "ustream-ssl.h"
#include "ustream-internal.h"
-static int urandom_fd = -1;
-
static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
{
struct ustream *s = ctx;
@@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx,
void *ssl, struct ustr
mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
}
-static bool urandom_init(void)
-{
- if (urandom_fd > -1)
- return true;
-
- urandom_fd = open("/dev/urandom", O_RDONLY);
- if (urandom_fd < 0)
- return false;
-
- return true;
-}
-
static int _urandom(void *ctx, unsigned char *out, size_t len)
{
- if (read(urandom_fd, out, len) < 0)
+ ssize_t ret;
+
+ ret = getrandom(out, len, 0);
+ if (ret < 0 || (size_t)ret != len)
return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
return 0;
@@ -134,9 +124,6 @@ __ustream_ssl_context_new(bool server)
mbedtls_ssl_config *conf;
int ep;
- if (!urandom_init())
- return NULL;
-
ctx = calloc(1, sizeof(*ctx));
if (!ctx)
return NULL;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
WRT54GS flash broken
Hi, I wanted to flash a recent OpenWrt onto a WRT54GS today and broke something. I used the recovery mechanism in the CFE boot loader: CFE version 1.0.37 for BCM947XX (32bit,SP,LE) Build Date: Fri Jun 25 15:49:22 CST 2004 (root@Amin) Copyright (C) 2000,2001,2002,2003 Broadcom Corporation. Initializing Arena. Initializing Devices. et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0 rndis0: Broadcom USB RNDIS Network Adapter (P-t-P) CPU type 0x29007: 200MHz Total memory: 0x200 bytes (32MB) Total memory used by CFE: 0x8030 - 0x8043DF30 (1302320) Initialized Data: 0x803381A0 - 0x8033A550 (9136) BSS Area: 0x8033A550 - 0x8033BF30 (6624) Local Heap:0x8033BF30 - 0x8043BF30 (1048576) Stack Area:0x8043BF30 - 0x8043DF30 (8192) Text (code) segment: 0x8030 - 0x803381A0 (229792) Boot area (physical): 0x0043E000 - 0x0047E000 Relocation Factor: I: - D: Boot version: v3.2 The boot is CFE mac_init(): Find mac [00:0F:66:D3:94:95] in location 1 Nothing... No eou key find Device eth0: hwaddr 00-0F-66-D3-94-95, ipaddr 192.168.1.1, mask 255.255.255.0 gateway not set, nameserver not set Reading :: CODE Pattern is CORRECT! upgrade_ver[v4.80.1] upgrade_ver[48001] 4712_ver[15000] Done. 5181472 bytes read fname=flash1.trx CODE Pattern is correct! (W54S) Programming...W The system was hanging after this operation. When I tried this again it never went further than "Programming..." I also tried to manually flash it like this: CFE> flash -ctheader : flash1.trx Reading :: CODE Pattern is CORRECT! upgrade_ver[v4.80.1] upgrade_ver[48001] 4712_ver[15000] Done. 2756640 bytes read fname=flash1.trx CODE Pattern is correct! (W54S) Programming...� I was sending the file like this: atftp --trace --option "timeout 1" --option "mode octet" --put --local-file bin/targets/bcm47xx/legacy/openwrt-bcm47xx-legacy-linksys_wrt54gs-squashfs.bin 192.168.1.1 Some old webpages said the image should be less than 3MB, so I deactivated many applications I do not need for a sysupgrade. How can I recover this device again? Currently I have UART connected only and no JTAG yet. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH relayd] route: Fix compile warning with glibc
This fixes the following compile problem:
/route.c: In function 'rtnl_flush':
/route.c:45:15: error: ignoring return value of 'write' declared with attribute
'warn_unused_result' [-Werror=unused-result]
45 | (void)write(fd, "-1", 2);
| ^~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.
Signed-off-by: Hauke Mehrtens
---
route.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/route.c b/route.c
index c552d1f..602fdc9 100644
--- a/route.c
+++ b/route.c
@@ -36,13 +36,16 @@ int route_table = 16800;
static void rtnl_flush(void)
{
+ ssize_t ret;
int fd;
fd = open("/proc/sys/net/ipv4/route/flush", O_WRONLY);
if (fd < 0)
return;
- write(fd, "-1", 2);
+ ret = write(fd, "-1", 2);
+ if (ret != 2)
+ perror("write");
close(fd);
}
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.3 third service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=22.03.3 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.3/targets/ Main changes between OpenWrt 22.03.2 and OpenWrt 22.03.3: Security fixes == * CVE-2022-30065: busybox: Fix a use-after-free in Busybox 1.35-x's awk applet * CVE-2022-0934: dnsmasq: Fixes single-byte, non-arbitrary write/use- after-free flaw in dnsmasq DHCPv6 server * CVE-2022-1304: e2fsprogs: An out-of-bounds read/write vulnerability was found in e2fsprogs 1.46.5 * CVE-2022-47939: kmod-ksmbd: ZDI-22-1690: Linux Kernel ksmbd Use- After-Free Remote Code Execution Vulnerability * CVE-2022-46393: mbedtls: Fix potential heap buffer overread and overwrite * CVE-2022-46392: mbedtls: An adversary with access to precise enough information about memory accesses can recover an RSA private key * CVE 2022-42905: wolfssl: In the case that the WOLFSSL_CALLBACKS macro is set when building wolfSSL, there is a potential heap over read of 5 bytes when handling TLS 1.3 client connections. Device support == * Support for the following devices was added: * Ruckus ZoneFlex 7372 * Ruckus ZoneFlex 7321 * ZTE MF289F * TrendNet TEW-673GRU * Linksys EA4500 v3 * Wavlink WS-WN572HP3 4G * Fix reboot loop by using LZMA loader. This affects the following devices: * NETGEAR EX6150 * HiWiFi HC5962 * ASUS RT-N56U B1 * Belkin F9K1109v1 * D-Link DIR-645 * D-Link DIR-860L B1 * NETIS WF2881 * ZyXEL WAP6805 * Fix WAN mac address assignment. This affects the following devices: * UniElec U7621-01 * UniElec U7621-06 * TP-Link AR7241 * TP-Link TL-WR740N * TP-Link TL-WR741ND v4 * Teltonika RUT230 * Luma Home WRTQ-329ACN * mvebu: Disable devices using broken mv88e6176 switch. This affects the following devices: * CZ.NIC Turris Omnia * Linksys WRT1200AC * Linksys WRT1900ACS * Linksys WRT1900AC v1 * Linksys WRT1900AC v2 * Linksys WRT3200ACM * Linksys WRT32X * Linksys WRT3200ACM * SolidRun ClearFog Pro * lantiq/xrx200: Enable interrupts on second VPE * layerscape: Fix SPI-NOR issues with vendor patches * RouterBoard 912UAG: Fix reference clock * TP-Link RE200 v3/v4: Fix LED configuration * GL.iNet GL-MT1300: Fix flash access by reducing SPI clock * Youku YK-L2 and YK-L1: Allow installing initramfs-kernel.bin over vendor web UI * D-Link DIR-825 B1: Add factory image recipe * D-Link DIR-825-B1: Expand rootfs * D-Link DGS-1210-10P: Add support for extra buttons and LEDs * Asus RT-AC88U: Include Broadcom 4366b1 firmware by default * AVM FRITZ!Box 7430: Include USB driver by default * HAOYU Electronics MarsBoard A10: Include sound driver by default * Linksys EA6350v3, EA8300, MR8300 and WHW01: Allow flashing Linksys factory firmware Various fixes and improvements == * firewall4: Fix boot hang with firewall4 and loadfile * Added the following kernel packages: * kmod-sched-prio (extracted from kmod-sched) * kmod-sched-red (extracted from kmod-sched) * kmod-sched-act-police (extracted from kmod-sched) * kmod-sched-act-ipt (extracted from kmod-sched) * kmod-sched-pie (extracted from kmod-sched) * kmod-sched-drr * kmod-sched-fq-pie * kmod-sched-act-sample * kmod-nvme * kmod-phy-marvell * kmod-hwmon-sht3x * kmod-netconsole * kmod-btsdio * Added firmware files for mt7916 and mt7921 devices * ucode: lexer: Fixes for regex literal parsing * hostapd: Remove dtim_period option from device, it is already a BSS property * procd: Service: pass all arguments to service * ustream-openssl: Disable renegotiation in TLSv1.2 and earlier * comgt-ncm: Add support for quectel modem EC200T-EU * umbim: Allow roaming and partner connections * kernel: Add support for EON EN25QX128A spi nor flash * iwinfo: Many bugfixes and improvements: * improvements in showing the used band, ht mode and hw mode * Added support for HE (Wifi 6) modes * Added support for new devices (MT7921AU, MT7986 WiSoC) * Add support for CCMP-256 and GCMP-256 ciphers * uhttpd: Fix incorrectly emitting HTTP 413 for certain content lengths * gcc: Import patch fixing asm machine directive for powerpc Core components update == * Update Linux kernel from 5.10.146 to 5.10.161 * Update mac80211 backports from 5.15.58-1 to 5.15.81-1 * Update strace from 5.16 to 5.19 * Update mbedtls from 2.28.1 to 2.28.2 * Update openssl from
Re: [PATCH] ramips: add support for D-Link DAP-X1860 A1
On 12/13/22 23:15, Sebastian Schaper wrote: The DAP-X1860 is a wall-plug AX1800 repeater. Specifications: - MT7621, 256 MiB RAM, 128 MiB SPI NAND - MT7915 + MT7975 2x2 802.11ax (DBDC) - Ethernet: 1 port 10/100/1000 - LED RSSI bargraph (2x green, 1x red/green), incorrectly populated red/orange status LEDs (should be red/green according to documentation) Installation: - Keep reset button pressed during plug-in - Web Recovery Updater is at 192.168.0.50 - Upload factory.bin, confirm flashing (seems to work best with Chromium-based browsers) Revert to OEM firmware: - tar -xvf DAP-X1860_RevA_Firmware_101b94.bin - openssl enc -d -md md5 -aes-256-cbc -in FWImage.st2 \ -out FWImage.st1 -k MB0dBx62oXJXDvt12lETWQ== - tar -xvf FWImage.st1 - flash kernel_DAP-X1860.bin via Recovery Signed-off-by: Sebastian Schaper --- I am not quite happy with the 4096K fixed-size kernel partition, but this is consistent with many other devices using UBI. If one day the kernel image will grow larger, this could be addressed simultaneously (e.g. using lzma-loader) for all devices. Do we even need UBI when there is NMBM? But probably better for redundancy. I see there are further options available for `mediatek,nmbm` in dts, i.e. `bmt-max-ratio` and `bmt-remap-range`, only used by those two NMBM devices. Do we need to set these as well, and how should the values be determined? RSSI bargraph is configured for the 5GHz interface `wlan1` to be consistent with other devices using the `rssileds` package, however in current master this is no longer working, since individual interfaces (e.g. `phy1-sta0`) will be created when connecting to a network. It seems this needs to be resolved within `rssileds`, rather than individually for this device. `uImage-relocate` is based on openwrt/staging/nbd from 977e37c0f23e ramips: add work-in-progress support for D-Link DIR-X1860 .../ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 197 ++ target/linux/ramips/image/mt7621.mk | 37 .../mt7621/base-files/etc/board.d/01_leds | 7 + .../mt7621/base-files/etc/board.d/02_network | 1 + .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 7 + .../mt7621/base-files/lib/upgrade/platform.sh | 1 + 6 files changed, 250 insertions(+) create mode 100644 target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 08aa592be8..beae1f929a 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -14,6 +14,23 @@ ifdef CONFIG_LINUX_5_10 DTS_CPPFLAGS += -DDTS_LEGACY endif +RELOCATE_LOADADDR = 0x8100 + +define Build/uImage-relocate + mkimage \ + -A $(LINUX_KARCH) \ + -O linux \ + -T kernel \ + -C $(word 1,$(1)) \ + -a $(RELOCATE_LOADADDR) \ + -e $(RELOCATE_LOADADDR) \ + -n '$(if $(UIMAGE_NAME),$(UIMAGE_NAME),$(call toupper,$(LINUX_KARCH)) $(VERSION_DIST) Linux-$(LINUX_VERSION))' \ + $(if $(UIMAGE_MAGIC),-M $(UIMAGE_MAGIC)) \ + $(wordlist 2,$(words $(1)),$(1)) \ + -d $@ $@.new + mv $@.new $@ +endef + Why do you need uImage-relocate and can not use the standard Build/uImage? You have to set KERNEL_LOADADDR to 0x8100. define Build/arcadyan-trx echo -ne "hsqs" > $@.hsqs $(eval trx_magic=$(word 1,$(1))) @@ -470,6 +487,26 @@ define Device/cudy_x6 endef TARGET_DEVICES += cudy_x6 +define Device/dlink_dap-x1860-a1 + $(Device/dsa-migration) + IMAGE_SIZE := 53248k + DEVICE_VENDOR := D-Link + DEVICE_MODEL := DAP-X1860 + DEVICE_VARIANT := A1 + UBINIZE_OPTS := -E 5 + BLOCKSIZE := 128k + PAGESIZE := 2048 + KERNEL_SIZE := 4096k + KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | \ + uImage-relocate lzma + IMAGES += factory.bin + IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata + IMAGE/factory.bin := append-kernel | pad-to $$(KERNEL_SIZE) | append-ubi | \ + check-size | elx-header 011b0060 8844A2D168B45A2D + DEVICE_PACKAGES := kmod-mt7915e rssileds +endef +TARGET_DEVICES += dlink_dap-x1860-a1 + define Device/dlink_dir-8xx-a1 $(Device/dsa-migration) IMAGE_SIZE := 16000k ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] ramips: mt7621: Add Arcadyan WE420223-99 support
On 1/2/23 17:36, Harm Berntsen wrote: The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access point distributed as Experia WiFi by KPN in the Netherlands. It features two ethernet ports and 2 internal antennas. Specifications -- SOC : Mediatek MT7621AT ETH : Two 1 gigabit ports, built into the SOC WIFI : MT7615DN BUTTON: Reset BUTTON: WPS LED : Power (green+red) LED : WiFi (green+blue) LED : WPS (green+red) LED : Followme (green+red) Power : 12 VDC, 1A barrel plug Winbond variant: RAM : Winbond W631GG6MB12J, 1GBIT DDR3 SDRAM Flash : Winbond W25Q256JVFQ, 256Mb SPI U-Boot: 1.1.3 (Nov 23 2017 - 16:40:17), Ralink 5.0.0.1 Macronix variant: RAM : Nanya NT5CC64M16GP-DI, 1GBIT DDR3 SDRAM Flash : MX25l25635FMI-10G, 256Mb SPI U-Boot: 1.1.3 (Dec 4 2017 - 11:37:57), Ralink 5.0.0.1 Serial -- The serial port needs a TTL/RS-232 3V3 level converter! The Serial setting is 57600-8-N-1. The board has an unpopulated 2.54mm straight pin header. The pinout is: VCC (the square), RX, TX, GND. Installation See the Wiki page [1] for more details, it comes down to: 1. Open the device, take off the heat sink 2. Connect the SPI flash chip to a flasher, e.g. a Raspberry Pi. Also connect the RESET pin for stability (thanks @FPSUsername for reporting) 3. Make a backup in case you want to revert to stock later 4. Flash the squashfs-factory.trx file to offset 0x5 of the flash 5. Ensure the bootpartition variable is set to 0 in the U-Boot environment located at 0x3 Note that the U-Boot is password protected, this can optionally be removed. See the forum [2] for more details. MAC Addresses(stock) +--+--+---+ | use | address | example | +--+--+---+ | Device | label| 00:00:00:11:00:00 | | Ethernet | + 3 | 00:00:00:11:00:03 | | 2g | + 0x02f1 | 02:00:00:01:00:01 | | 5g | + 1 | 00:00:00:11:00:01 | +--+--+---+ The label address is stored in ASCII in the board_data partition Notes - - This device has a dual-boot partition scheme, but OpenWRT will claim both partitions for more storage space. Known issues - 2g MAC address does not match stock due to missing support for that in macaddr_add - Only the power LED is configured by default References -- [1] https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99 [2] https://forum.openwrt.org/t/adding-openwrt-support-for-arcadyan-we420223-99-kpn-experia-wifi/132653 Signed-off-by: Harm Berntsen --- package/boot/uboot-envtools/files/ramips | 3 + .../dts/mt7621_arcadyan_we420223-99.dts | 219 ++ target/linux/ramips/image/mt7621.mk | 25 ++ .../mt7621/base-files/etc/board.d/02_network | 8 + .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 9 + .../mt7621/base-files/lib/upgrade/platform.sh | 1 + 6 files changed, 265 insertions(+) create mode 100644 target/linux/ramips/dts/mt7621_arcadyan_we420223-99.dts diff --git a/package/boot/uboot-envtools/files/ramips b/package/boot/uboot-envtools/files/ramips index 372b8a49e2..9dbe2cb181 100644 --- a/package/boot/uboot-envtools/files/ramips +++ b/package/boot/uboot-envtools/files/ramips @@ -17,6 +17,9 @@ alfa-network,awusfree1|\ alfa-network,quad-e4g|\ alfa-network,r36m-e4g|\ alfa-network,tube-e4g|\ +arcadyan,we420223-99) + ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x1000" "0x1000" + ;; This changes the ubootenv_add_uci_config also for the alfa-network devices I think this is not intended. Please move your new entry after the "ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"" line. engenius,esr600h|\ sitecom,wlr-4100-v1-002) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/2] toolchain: build all user space with sanitizer on glibc
On 1/4/23 18:39, Christian Marangi wrote: On Sun, Jan 17, 2021 at 06:10:34PM +0100, Hauke Mehrtens wrote: This patch allows to build most the OpenWrt user space with address and undefined behavior sanitizer activated by default. This only works with glibc and gcc 10 and I only tested this on x86 64 so far. It is not intended to activate this by default ever, but this is helpful to detect (security) bugs in our applications. The first patch adds a work around for a problem with our Kconfig system, I did not fully understand the problems and only provided a workaround for it, if someone has any idea what is going wrong there this would be helpful. I already found some problems like memory leaks and a use after free problem, will send separate mails for the later. When these sanitizers are activated the OpenWrt userspace needs significant more memory, use at least 256MB for a basic system. TODOs: * Fix the Kconfig recursive dependency problem * Test this on more than x86 / 64 * Make it depend on GCC 10 or wait till GCC 10 is the default. This is a bit of necroposting... But any news with this? Considering we are switching to gcc12 by default i think these feature are now mature enough to be finally introduced. Hi, I was trying it again some days ago with gcc 12. I am still running into a bug with the script which generates the Kconfig. It has some problems with the iw Makefile which has two build variants. I will update my branch in the next days. I do not know if I find the time to look into the Kconfig problem. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: AW: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Hi,
I am also fine if the user has to use image builder. This board is a bit
special.
Maybe we should allow board specific initram fs root file systems in the
future. This would also help in other cases where the user has to bot an
initramfs system for initial flashing. We can do this later.
Hauke
On 10/25/22 08:50, kestrel1...@t-online.de wrote:
Hi,
I can understand that it took a long time. The wasp loader kernel module v5 is
the next in the review list of the remoteproc-linux kernel list.
I will try to deal with Haukes suggestions by the end of the week. With regards
to the packages, I think wpad is a left over from my tests and I can remove it
and I will rework the kernel patches.
But for the special packages that are not honored by the build bots, I do not
really have a solution. For now I was thinking of instructions to use the image
builder, which also means, that as a start there will not be any downloadable
images that cover all possible functionality.
Daniel.
-Original-Nachricht-
Betreff: Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Datum: 2022-10-25T00:24:57+0200
Von: "Hauke Mehrtens"
An: "Torsten Duwe" , "openwrt-devel@lists.openwrt.org"
On 10/23/22 13:19, Torsten Duwe wrote:
Hi all,
Here is my second attempt for initial FritzBox x490 support. 22.03 now
has all the necessary prerequisites, so support can be added according
to the rules.
The original code snippets were submitted by John Crispin (IIRC),
Andreas Böhler and Daniel Kestrel. I carved out the changes I
considered necessary, integrated and tested them and cleaned them up
(hopefully ;)
These are the minimal changes required to run the FB {3,7}490 as DSL
router (tested!). The 5490 is reported to be similar, so I included
it, but could not test it due to lack of hardware.
The wireless on these boxes is offloaded to a secondary SoC which
needs to be provided its own OS. This feature is explicitly left out
here in order to go step by step. I kept some loose ends where they
don't hurt, for future reference.
Changes from v1:
* return to squashfs for the rootfs; ubifs causes too much complexity
esp. for updates, when even the same model can be equipped with
varying flash chip geometries. UBI partitioning and volumes are kept
though.
Hi,
How is this related to the pull request adding support for these devices
on github?
https://github.com/openwrt/openwrt/pull/5075
The pull request on github looks mostly ok to me, I just had some minor
questions.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/25/22 17:21, Dave Taht wrote: On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls wrote: On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! As I said on a related thread - if an eu body can be found to care more deeply on these issues, I'm pretty sure 30-50k of funding is available via one or more of nlnet's grant programs. Applications for this round close december 1st. https://nlnet.nl/ Thanks for pointing it out. If someone wants to apply for this and improve the security of OpenWrt it would be nice. One problem is still the constant maintenance which is needed to keep it up to date. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/25/22 16:29, Peter Naulls wrote: On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! I also prefer if the CVE number is named in the patch. If this is missing somewhere you could send a patch or pull request to rename the patch. I'm afraid I don't have any explicit examples, but I'll let you know if find any. There are some concerns with the older lua I mentioned below, but I'll need to come back to those. In any case, a suggestion for future CVE patches. The OpenWrt project does not have enough resources to maintain security patches for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and we update to the most recent LTS version every few days or weeks in the maintained branches. If some security patches are missing in the LTS kernel versions used by OpenWrt it is probably best to approach the Linux stable team directly. See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure system" section: http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Yes, sure. And whether you or I agree with this or not is to some degree irrelevant, since what matters to the security people is that they see the bug fixed. In 90% of the cases I was able to dismiss CVEs since the subsystems in question are not in use by us (or most of OpenWrt for that matter. e.g, frame buffers), but some tricky ones remain. I do not care much about such security experts which are just able to hand a list of "problems" their broken tool found and now want fixes. If you found a real problem patches are welcome, but best is probably to inform the stable Linux group. Many security problems in the Linux kernel do not even get CVE numbers, relaying only on CVE numbers for the kernel is not reliable. That said, there's a very large number of patches to the kernel in OpenWrt; mostly for new device function, pending fixes or whatnot; I guess few of these are actual security fixes. It would be good if someone could create a script finds all patches which have a Fixes tag referencing a patch we backported. So, to user space: dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't go over particularly well, even though they have been properly dismissed by the Simon Kelley and others. See my mail on the dnsmasq mailing list: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html Yes, and was referred to and well understood by myself at least. Still, the objection is that Mitre have this as "disputed", which is rather unhelpful, and that is what is being focused upon. Obviously I cannot fix something that isn't broken and has no fix, so there's no satisfactory answer here to a security review beyond getting the CVEs dismissed from Mitre. tcpdump 4.9.3 - CVE-2018-16303 This CVE is not for tcpdump, but PDF-XChange Editor: https://nvd.nist.gov/vuln/detail/CVE-2018-16303 Sorry, trying to juggle lots of items here. https://nvd.nist.gov/vuln/detail/CVE-2018-16301 Long since in OpenWrt patches. e2fsprogs 1.46.5 - CVE-2022-1304 This is pretty hard to attack. You could provide a patch. This was the patch I provided here: I brought in this patch: diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c index b324c7b0..1a206a16 100644 Yes, very large files on OpenWrt are unlikely without external media. If would be simply easier on the optics if I was able to ditch 5.1.5 in the build and just use 5.3 - is this possible; I'm sure there's been much discussion on this before, so please point me at that - will it break luci? An update to Lua 5.4 would be good, but I do not know which impact it has. Understood. I'm going to come back to this later in another post. There's much more, but that's quite enough for now. OpenWrt is a mostly volunteer run project. Especially (security) maintenance does not get paid by companies. If you have some fixes tested patches would be really helpful. Yes, I know, and to say my reliance upon OpenWrt over the years is considerable would be an understatement, but my time is limited as well, and my focus must be on addressing specifics to the security review. Still, I felt it better to at least have a partial discussion here, and do what little I can. I don't necessarily have time to roll patches in a format suitable for OpenWrt upstreaming; sometimes I think it's more constructive to simply point out what can be done, and have the maintainers do it. Maybe not ideal, but it's something. Look for some more posts on specific topics in the near future. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SBOM Tool for OpenWRT to feed Dependency Track
On 10/18/22 16:38, Pfendtner Steffen wrote: Hi, We decided to publish our internal fork of the Timesys SBOM Tool we found on github. You find our version at: https://github.com/ads-tec/sbom-openwrt It takes a complete OpenWRT build tree as input and will generate a SBOM in CycloneDX JSON Format for the currently configured image. This SBOM can be fed into your personal dependency track instance. See https://dependencytrack.org/ if you don't know what this is. In my opinion Dependency Track is much more usable compared to uscan. However Dependency Tack currently heavily relies on valid CPE ID. Thus you will need to fix the CPE IDs in the OpenWRT package Makefiles - some are missing. I think it would be a great security benefit for the OpenWRT ecosystem if we get a best possible coverage of CPE IDs in the available Makefiles. I'll try to push our CPE ID additions upstream. Best regards, Steffen Pfendtner Hi Steffen, Nice tool, do you have some "demo" output for a recent OpenWrt release somewhere? One advantage of uscan from my point of view is that I just have to open a website to see the results for OpenWrt master and the maintained branches and do not have to run some scripts and install some tooling myself. Having multiple tools for such tasks is always helpful. Normally every additional tool find additional problems. Adding the missing CPE IDs is no problem, someone just has to do it. If you already have some internal changes with additional CPE IDs it would be nice if you could send a patch or pull request adding them to OpenWrt master and then we can backport it to OpenWrt 22.03 too. Petr added the missing CPE IDs to 4 packages recently. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
On 10/23/22 13:19, Torsten Duwe wrote:
Hi all,
Here is my second attempt for initial FritzBox x490 support. 22.03 now
has all the necessary prerequisites, so support can be added according
to the rules.
The original code snippets were submitted by John Crispin (IIRC),
Andreas Böhler and Daniel Kestrel. I carved out the changes I
considered necessary, integrated and tested them and cleaned them up
(hopefully ;)
These are the minimal changes required to run the FB {3,7}490 as DSL
router (tested!). The 5490 is reported to be similar, so I included
it, but could not test it due to lack of hardware.
The wireless on these boxes is offloaded to a secondary SoC which
needs to be provided its own OS. This feature is explicitly left out
here in order to go step by step. I kept some loose ends where they
don't hurt, for future reference.
Changes from v1:
* return to squashfs for the rootfs; ubifs causes too much complexity
esp. for updates, when even the same model can be equipped with
varying flash chip geometries. UBI partitioning and volumes are kept
though.
Hi,
How is this related to the pull request adding support for these devices
on github?
https://github.com/openwrt/openwrt/pull/5075
The pull request on github looks mostly ok to me, I just had some minor
questions.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/20/22 22:26, Peter Naulls wrote:
Apologies for the obtuseness of the previous email about the squashfs
permissions - that's related to the following, but a different topic. I
can now
say that we're undergoing a security review for our system which is very
much
based upon OpenWrt 22.03.
If you have ever done this, you'll probably know what's in such things,
lots
of picky items, much that is to be polite, spurious and many other things
which are of little relevance, but are security theater and therefore
important to people who make such reports. Nevertheless, I do have to
provide answers and "proof" for everything.
The following is partly for my own benefit, but it might benefit anyone
else who is settling upon 22.03 for a stable version and will be doing
the same in the near future.
First a request on patch naming in OpenWrt - if it's a specific CVE
patch, then
it would help that it was named that. I know that often isn't possible,
since
often they get rolled up into other upstream patches, pulled out of git,
etc, etc, but it would help.
I also prefer if the CVE number is named in the patch. If this is
missing somewhere you could send a patch or pull request to rename the
patch.
For the kernel, a great many of the CVEs in my report relate to the 5.15
kernel series. The dumb assumption here is a that the 5.10 series
kernel is "older", and therefore these must apply to. The reality is that
in most cases, these are issues introduced in that series for new features,
or they've been backported by either the 5.10 maintainers or the OpenWrt
maintainers, both of who I know are on top of such things.
For other remaining CVEs, sometimes it's very hard to know, unless you
can (a) rule out for sure the driver/subsystem isn't in use, or failing
that (b) close code examination and hand-waving that the patch isn't
relevant, sans intimate knowledge of the codebase.
CVE-2022-500 and CVE-2021-4150 are examples here.
For CVE-2022-39188, CVE-2021-3669, it seems like they might get 5.10 series
patches, if they are relevant, so I will wait on a kernel bump on those.
The OpenWrt project does not have enough resources to maintain security
patches for the kernel on our own. OpenWrt relays on the LTS kernel
maintenance and we update to the most recent LTS version every few days
or weeks in the maintained branches. If some security patches are
missing in the LTS kernel versions used by OpenWrt it is probably best
to approach the Linux stable team directly.
See this blog post from Greg Kroah-Hartman, especially the "Keeping a
secure system" section:
http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/
So, to user space:
dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false
didn't go
over particularly well, even though they have been properly dismissed by
the Simon Kelley and others.
See my mail on the dnsmasq mailing list:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html
However, there is CVE-20220-0934.
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39
Which can easily be patched, or update to dnsmasq 2.87.
Thank you, I was not aware of this problem.
busybox 1.35.0 - CVE-2022-30065
I brought in patches from here:
https://bugs.busybox.net/show_bug.cgi?id=14781
Someone should backport these changes.
tcpdump 4.9.3 - CVE-2018-16303
This CVE is not for tcpdump, but PDF-XChange Editor:
https://nvd.nist.gov/vuln/detail/CVE-2018-16303
Long since in OpenWrt patches.
e2fsprogs 1.46.5 - CVE-2022-1304
This is pretty hard to attack. You could provide a patch.
I brought in this patch:
diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
index b324c7b0..1a206a16 100644
--- a/lib/ext2fs/extent.c
+++ b/lib/ext2fs/extent.c
@@ -495,6 +495,10 @@ retry:
ext2fs_le16_to_cpu(eh->eh_entries);
newpath->max_entries = ext2fs_le16_to_cpu(eh->eh_max);
+ /* Make sure there is at least one extent present */
+ if (newpath->left <= 0)
+ return EXT2_ET_EXTENT_NO_DOWN;
+
if (path->left > 0) {
ix++;
newpath->end_blk = ext2fs_le32_to_cpu(ix->ei_block);
@@ -1630,6 +1634,10 @@ errcode_t
ext2fs_extent_delete(ext2_extent_handle_t handle, int flags)
cp = path->curr;
+ /* Sanity check before memmove() */
+ if (path->left < 0)
+ return EXT2_ET_EXTENT_LEAF_BAD;
+
if (path->left) {
memmove(cp, cp + sizeof(struct ext3_extent_idx),
path->left * sizeof(struct ext3_extent_idx));
lua 5.1.5 and lua 5.3.
CVE-2014-5461 and others. lua 5.1.5 has been heavily patched in OpenWrt,
and I suspect these have all long since been fixed.
If would be simply easier on the optics if I was able to ditch 5.1.5 in the
build and just use 5.3 - is this possible; I'm sure there's been much
discussion on this before, so please point me at that - will it break luci?
An update to Lua
OpenWrt 21.02.5 fifth service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 21.02 stable version series. It fixes security issues. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=21.02.5 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/21.02.5/targets/ The OpenWrt 21.02 stable series is in security maintenance only mode. It is projected to go end of life on 6. April 2023 following the OpenWrt Security support guidelines. We encourage all users of the OpenWrt 21.02 stable series to upgrade to OpenWrt 22.03. https://openwrt.org/docs/guide-developer/security#support_status Main changes between OpenWrt 21.02.4 and OpenWrt 21.02.5: Security fixes == * mac80211/cfg80211: Security fixes for BSSID parsing (CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721 and CVE-2022-42722) * See Security Advisory 2022-10-17-1 * https://openwrt.org/advisory/2022-10-17-1 Device support == * None Various fixes and improvements == * None Core components === * None - Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.5 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.5#known_issues For a detailed list of all changes since 21.02.4, refer to https://openwrt.org/releases/21.02/changelog-21.02.5 To download the 21.02.5 images, navigate to: https://downloads.openwrt.org/releases/21.02.5/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=21.02.5 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Security Advisory 2022-10-17-1 - Multiple issues in mac80211 and cfg80211 (CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721 and CVE-2022-42722)
DESCRIPTION Multiple vulnerabilities were found in the Linux Kernel mac80211 and cfg80211 framework. OpenWrt takes the mac80211 and cfg80211 framework from the wireless backports project which copies it from a more recent Linux kernel version. These vulnerabilities are in the multi BSSID (MBSSID) beacon parsing code and the P2P-device beacon parsing code. * CVE-2022-41674 [0]: fix u8 overflow in cfg80211_update_notlisted_nontrans (max 256 byte overwrite) (RCE) * CVE-2022-42719 [1]: wifi: mac80211: fix MBSSID parsing use-after-free use after free condition (RCE) * CVE-2022-42720 [2]: wifi: cfg80211: fix BSS refcounting bugs ref counting use-after-free possibilities (RCE) * CVE-2022-42721 [3]: wifi: cfg80211: avoid nontransmitted BSS list corruption list corruption (DOS) * CVE-2022-42722 [4]: wifi: mac80211: fix crash in beacon protection for P2P-device NULL ptr dereference crash (DOS) REQUIREMENTS The vulnerabilities are mostly in the Wifi beacon parsing code. OpenWrt operating as Wifi AP or Wifi client is affected when it scans for Wifi networks. A malicious attacker could exploit this by sending specially crafted packets while the target is scanning for Wifi networks. A malicious attacker has to be physically close to the target to exploit these vulnerabilities. This can be exploited by attackers which are not necessary part of the network, no authentication needed. Wifi drivers in OpenWrt will parse beacons from arbitrary Wifi devices nearby. All Wifi drivers in OpenWrt are using cfg80211 and many are using mac80211. MITIGATIONS You need to update to a fixed OpenWrt version. Fixes for the vulnerabilities are integrated in OpenWrt 22.03.2 and OpenWrt 21.02.5. Upgrading the packages with opkg update is not sufficient. The fix is contained in the following and later versions: * OpenWrt master: 2022-10-13 (fixed by reboot-20925-g26f400210d6b) * OpenWrt 22.03: 2022-10-13 (fixed by v22.03.1-16-gf1de43d0a0) * OpenWrt 21.02: 2022-10-13 (fixed by v21.02.4-2-gfa9a932fdb) AFFECTED VERSIONS To our knowledge, OpenWrt snapshot images are affected. OpenWrt stable release versions 22.03.1 and OpenWrt 21.02.4 and earlier are affected. Older versions of OpenWrt (e.g. OpenWrt 19.07, OpenWrt 18.06, OpenWrt 15.05 and LEDE 17.01) are end of life and not supported any more. CREDITS Thanks to security researcher Sönke Huster from TU Darmstadt ( shus...@seemoo.tu-darmstadt.de ) and Johannes Berg from Intel for identifying the problems and fixing them in the upstream Linux kernel. [5,6]. REFERENCES 0. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41674 1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42719 2. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42720 3. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42721 4. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42722 5. https://lwn.net/ml/oss-security/20221013101046.gb20...@suse.de/ 6. https://lwn.net/ml/oss-security/ff7256bc-418b-e833-18d8-bc9700f6d...@seemoo.tu-darmstadt.de/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.2 second service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=22.03.2 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.2/targets/ Main changes between OpenWrt 22.03.1 and OpenWrt 22.03.2: Security fixes == * mac80211/cfg80211: Security fixes for BSSID parsing (CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721 and CVE-2022-42722) * See Security Advisory 2022-10-17-1 * https://openwrt.org/advisory/2022-10-17-1 Device support == * Support for the following devices was added: * ZyXEL NWA50AX / NWA55AXE (ramips) * ramips/mediatek: backport NAND flash driver from master * mpc85xx: p1010: make TP-Link WDR4900 v1 build again Various fixes and improvements == * busybox: nslookup: Fix wrongly dropped DNS response on some platforms Core components update == * Update rpcd from 2022-08-24 to 2022-09-21 * Update ucode from 2022-08-29 to 2022-10-07 * Update firewall4 from 2022-09-01 to 2022-10-14 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.2 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.2#known_issues For a detailed list of all changes since 22.03.1, refer to https://openwrt.org/releases/22.03/changelog-22.03.2 To download the 22.03.1 images, navigate to: https://downloads.openwrt.org/releases/22.03.2/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=22.03.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 announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.4 fourth service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 21.02 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=21.02.4 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/21.04.4/targets/ The OpenWrt 21.02 stable series is in security maintenance only mode. It is projected to go end of life on 6. April 2023 following the OpenWrt Security support guidelines. We encourage all users of the OpenWrt 21.02 stable series to upgrade to OpenWrt 22.03. https://openwrt.org/docs/guide-developer/security#support_status Main changes between OpenWrt 21.02.3 and OpenWrt 21.02.4: Security fixes == * wolfssl: Fix security problem (CVE-2022-34293, CVE-2022-38152, CVE-2022-38153 and CVE-2022-39173) * See Security Advisory 2022-10-04-1 * zlib: Fix security problem (CVE-2022-37434) * openssl: Fix security problem (CVE-2022-1292, CVE-2022-2068 and CVE-2022-2097) Device support == * Support for the following devices was added: * Wavlink WL-WN579X3 * Sitecom WLR-4100 v1 002 * Banana Pi M2 Berry * YunCore AX820/HWAP-AX820 * MikroTik RouterBOARD hAP ac lite * MikroTik RouterBOARD mAP * Youku YK1: speed up spi frequency for YK-L1, split YK1 to YK-L1 and YK-L1c * ZBTLink ZBT-WG2626: add reset GPIO for PCIe port 1 * ZBTLink ZBT-WE1026 5G: fix watchdog reset * Asus RT-AC57U: fix WPS button level * Archer VR2600: fix switch ports numbering * ZyXEL NBG-419N v2: Fix booting * Linksys MR8300: add WAN port * ramips: several fixes and improvements to mt7620 Ethernet * bcm53xx: * Disable GRO by default at kernel level * Enable & setup packet steering * ipq40xx: fix ar40xx driver * bcm4908: * Enable NVMEM U-Boot env data driver * Backport mtd parser for Broadcom's U-Boot partition * fix -EPROBE_DEFER support in bcm4908_enet Various fixes and improvements == * kernel: * Fix IPv6 flow offloading (FS#3373) * Backport LEDs driver for BCMBCA devices * Backport mtd dynamic partition patch * Fix possible mtd NULL pointer dereference * mac80211: fix QCA9561 PA bias * mac80211: disable ft-over-ds by default * mt76: backport fix encap offload ethernet type check * hostapd fixes and improvements: * Add support for enabling link measurements * Fix uninitialized pointer * zlib: backport null dereference fix * build system: * Switch from xxd tool to xxdi.pl script * Check TLS certificates by default when downloading over HTTPS * feeds: use git-src-full to allow Git versioning * Fix build warnings with grep-3.8 * Add compatibility with Python 3.11 Core components === * Update Linux kernel from 5.4.188 to 5.4.215 * Update openssl from 1.1.1n to 1.1.1q * Update wolfssl from 5.2.0 to 5.5.1 * Update wireless-regdb from 2021.08.28 to 2022.08.12 * Update intel-microcode from 20210608 to 20220809 * Update exfat from 5.12.3 to 5.19.1 * Update iwinfo from 2021-04-30 to 2022-04-26 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.4 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.4#known_issues For a detailed list of all changes since 21.02.3, refer to https://openwrt.org/releases/21.02/changelog-21.02.4 To download the 21.02.4 images, navigate to: https://downloads.openwrt.org/releases/21.02.4/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=21.02.4 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.1 first service release
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 22.03 stable version series. It fixes security issues, improves device support, and brings a few bug fixes. Download firmware images using the OpenWrt Firmware Selector: * https://firmware-selector.openwrt.org/?version=22.03.1 Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.1/targets/ Main changes between OpenWrt 22.03.0 and OpenWrt 22.03.1: Security fixes == * wolfssl: Fix security problem (CVE-2022-38152, CVE-2022-38153 and CVE-2022-39173) * See Security Advisory 2022-10-04-1 Device support == * Support for the following devices was added: * ZTE MF281 * Ubiquiti UniFi FlexHD * Asus RT-AX53U: fix switch setup * GL-inet GL-AP1300: add LTE package, add WAN LED * Ubiquiti XM moved to ath79/tiny * Ubiquiti UniFi 6LR: fix network config * Linksys RE6500: enable LZMA loader to fix boot * LibreRouter v1: fix watchdog and PoE passthrough * NanoPi R4S: ensure unique MAC address * bcm4908: * Enable NVMEM U-Boot env data driver * Backport mtd parser for Broadcom's U-Boot partition * fix -EPROBE_DEFER support in bcm4908_enet * realtek: * fix RTL838x receive tag decoding * fix RTL839x receive tag decoding * ath79/tiny: activate low_mem too Various fixes and improvements == * kernel: * Backport mtd dynamic partition patch * Fix possible mtd NULL pointer dereference * hostapd: rename hostapd multicast_to_unicast option to multicast_to_unicast_all * mt7620 wifi: multiple improvements * build system: * Switch from xxd tool to xxdi.pl script * Check TLS certificates by default when downloading over HTTPS * Fix issues with targets installed via feeds * Fix build warnings with grep-3.8 * Fix build problems with external toolchains * Activate fortify source when using external toolchain Core components update == * Update Linux kernel from 5.10.138 to 5.10.146 * Update mt76 from 2022-08-26 to 2022-09-06 * Update wolfssl from 5.4.0 to 5.5.1 * Update wireless-regdb from 2022.06.06 to 2022.08.12 * Update intel-microcode from 20220510 to 20220809 - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.1 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.1#known_issues For a detailed list of all changes since 22.03.0, refer to https://openwrt.org/releases/22.03/changelog-22.03.1 To download the 22.03.1 images, navigate to: https://downloads.openwrt.org/releases/22.03.1/targets/ Use OpenWrt Firmware Selector to download: https://firmware-selector.openwrt.org/?version=22.03.1 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: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.4 and OpenWrt 22.03.1 release planning
On 10/6/22 16:42, Szabolcs Hubai wrote: Hi Hauke, There is another LZMA ERROR 1 issue [0] for a ramips/rt3883 device. I have sent a fix for that to GitHub as PR#10834 [1]. It's not on the master, as it is not reviewed yet. The problem is that this device is a SEAMA device, and it got the "$(Device/uimage-lzma-loader)" fix already, exactly for this LZMA ERROR 1 in the 21.02 times. [2] Due to this, my fix is not just a oneliner, but it contains a new recipe to avoid future recipe misunderstandings. Should I resend the series to ML and close my pull request? [0]: https://github.com/openwrt/openwrt/issues/10634 [1]: https://github.com/openwrt/openwrt/pull/10834 [2]: https://git.openwrt.org/09faa73c53bd097666cbbe68176dd46cfcf80ee8 -- Thanks, Szabolcs Hi, We should get this first into master and then we can try to backport it if needed. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Refactoring OpenWrt's build infra
On 10/5/22 17:56, Thibaut wrote: Hi, Following an earlier conversation on IRC with Petr, I’m willing to work on refactoring our buildbot setup as follows: - single master for each stage (images and packages) - latent workers attached to either master, thus able to build opportunistically from either master or release branches as needed / as work becomes available The main upside is that all buildslaves could be pooled, improving overall throughput and reducing wasted « idle time », thus lowering build times and operating costs. Petr also suggested that extra release workers could be spawned at will (through e.g. cloud VMs) when a new release is to be tagged; tagged release could be scheduled only to release workers: this would still work within this « single master » build scheme. NB: I’m aware of the potential performance penalty of having buildslaves randomly switching between branches, so I would try to come up with a reasonably smart solution to this issue if it doesn’t conflict with the main goals. Before I set on to revamp the system accordingly I want to ask if this proposal seems like a Good Idea™ :) Comments welcome, T. Hi, This sounds like a good idea, but I am not an expert in this topic. I would approve such a change, but others are much more knowledge how our infrastructure works. I do not know if we need special container for each release branch, I think we try to use an old Debian to build to make it possible to use the image builder binaries also on older systems. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.4 and OpenWrt 22.03.1 release planning
Hi, I would like to do an OpenWrt 21.02.4 and OpenWrt 22.03.1 release on the next weekend or some days later. Are there still some commits missing which should get backported? I will wait for the wolfssl update from Petr. I do not see much on github: https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F22.03 https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02 0/5] backport fix for TLSv1.3 RCE in uhttpd by using 5.5.1-stable
On 10/5/22 11:46, Petr Štetiar wrote: Hi, we need to upgrade wolfSSL to version 5.5.1 as it fixes several remotely exploitable vulnerabilities in TLS v1.3 protocol handling, so I suggest to do so by backporting following commits from 22.03 release. I've tested this change in x86/64 QEMU, using openwrt-21.02.3-x86-64-generic-squashfs-combined.img.gz image as a base: root@OpenWrt:/# opkg list-upgradable | cut -d ' ' -f 1 | xargs opkg upgrade Upgrading libustream-wolfssl20201210 on root from 2022-01-16-868fd881-1 to 2022-01-16-868fd881-2... Downloading http://192.168.220.1/~ynezz/packages/21.02/x86_64/base//libustream-wolfssl20201210_2022-01-16-868fd881-2_x86_64.ipk Installing libwolfssl5.5.1.99a5b54a (5.5.1-stable-2) to root... Downloading http://192.168.220.1/~ynezz/packages/21.02/x86_64/base//libwolfssl5.5.1.99a5b54a_5.5.1-stable-2_x86_64.ipk Upgrading px5g-wolfssl on root from 3 to 4.1... Downloading http://192.168.220.1/~ynezz/packages/21.02/x86_64/base//px5g-wolfssl_4.1_x86_64.ipk Configuring libwolfssl5.5.1.99a5b54a. Configuring libustream-wolfssl20201210. Configuring px5g-wolfssl. Then verified, that: * px5g still works * LuCI is still accessible over HTTPS * opkg/uclient can still fetch from HTTPS Cheers, Petr 1. https://downloads.openwrt.org/releases/21.02.3/targets/x86/64/openwrt-21.02.3-x86-64-generic-squashfs-combined.img.gz Eneas U de Queiroz (2): wolfssl: bump to v5.3.0-stable wolfssl: bump to 5.4.0 Ivan Pavlov (1): wolfssl: bump to 5.5.0 Petr Štetiar (2): wolfssl: fix TLSv1.3 RCE in uhttpd by using 5.5.1-stable (CVE-2022-39173) treewide: fix security issues by bumping all packages using libwolfssl Acked-by: Hauke Mehrtens ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Handle target path located under target/linux/feeds/
On 10/3/22 17:24, Hauke Mehrtens wrote: On 5/31/22 07:23, Prasun Maiti wrote: When we are installing targets to target/linux/feeds, BOARD is not located under target/linux/ So, we need to handle this scenario taking proper target path Does this change also fix your problem? https://git.openwrt.org/3a8825ad6acbf18b2b472ace56be58868af78be7 It was also backported to 22.03: https://git.openwrt.org/25d8b9cad6f141104a1065880efe21b8c292d8c6 If this is not solving your problem please explain in more detail in the commit message what problem you want to solve, for me it is not really clear from the commit message. Hauke This commit also looks related to your problem: https://git.openwrt.org/00094efec33f07c9dc16cce23be492430c40b3cc Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] argp-standalone: generate a shared library instead of static library
On 9/28/22 12:11, Petr Štetiar wrote: Thomas Langer [2022-09-13 17:47:56]: Hi, Change the argp-standalone package to produce a shared library instead of a static library for the target. The host build is not changed. we can see that from the diff already, so we would prefer to know, why would you like to have this change included. argp-standalone is licensed under the LGPL. An application linking statically against it has to follow the LGPL, when an application links dynamically against it there is not need to follow LGPL. Update related packages to add it as a direct dependency, otherwise the buildsystem will complain. Please check also https://github.com/openwrt/packages/pull/19357, a related pull request for the packages feed, to avoid that this change is breaking all the packages that depend on argp-standalone. Can't this be solved in some less intrusive way? I can imagine, that this is not going to be bisect friendly and could provide other woes in the future. What about introducing shared library in conjunction to the static one, thus not breaking anything? Then if it makes sense, we could convert existing static users to shared version in a next step. When the linker finds a static and a shared library with a matching name it will use the shared library by default. When a package is build in OpenWrt the build process has access to all libraries already build and will find the shared library. This will add an extra dependency. When I looked on the Internet I also found this library: https://github.com/xhebox/libuargp It also looks like argp-standalone has some bugs: https://www.openwall.com/lists/musl/2021/02/12/2 Maybe we should introduce libuargp as a new package which builds a shared library and place it in an own folder. Then package Makefiles which want to link against it have to modify the TARGET_FLAGS to include the extra folder. This way we can do a slow migration to the shared library. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Handle target path located under target/linux/feeds/
On 5/31/22 07:23, Prasun Maiti wrote: When we are installing targets to target/linux/feeds, BOARD is not located under target/linux/ So, we need to handle this scenario taking proper target path Does this change also fix your problem? https://git.openwrt.org/3a8825ad6acbf18b2b472ace56be58868af78be7 It was also backported to 22.03: https://git.openwrt.org/25d8b9cad6f141104a1065880efe21b8c292d8c6 If this is not solving your problem please explain in more detail in the commit message what problem you want to solve, for me it is not really clear from the commit message. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Tozed S12 Plus (UNISOC)
On 7/28/22 07:31, Ian Pangilinan wrote:
From: Ian Pangilinan
Date: Sun, 28 July 2022 11:27:00 +0800
Subject: [PATCH] ramips: add support for Tozed S12 Plus (UNISOC)
Tozed S12 Plus (UNISOC) is a Cat.6 LTE CPE. It is known as ZLT S12 Pro
in some markets.
Product link: https://www.sztozed.com/en/contents/58/84.html
Hardware Highlights:
* SOC: MT7621A 2C4T @ 880MHz
* RAM: DDR3 256MB @ 800MHz
* FLASH: MX25L12805D 16MB SPI NOR
* WLAN0: MT7612E 5GHz 802.11nac 2x2:2 @ 867Mbps
* WLAN1: MT7603E 2.4GHz 802.11bgn 2x2:2 @ 300Mbps
* SWITCH: MT7530 4-port GbE
* WWAN: UNISOC SL8563 Cat.6 LTE
* SIM: 1x Mini-SIM 2FF
* BUTTONS: Reset, WPS, Wi-Fi
* LEDS: Power (Yellow/Blue), Wi-Fi, Data (Red/Blue), Signal1-5,
Telephone
* POWER: 12VDc 2A
There is an existing PR for this device here:
https://github.com/openwrt/openwrt/pull/10321, but the author seems to
have abandoned it after a week of no update in reply to reviewer
suggestions and inquiries. This submission aims to remedy the
shortcomings of that PR and will be made up-to-date by this author.
You should mention "1Conan " as the original author.
.
The only non-configurable LEDs are those from each of the switch ports.
They function as intended. I set the yellow and blue power LEDs as
status indicators for OpenWrt. There is also an exported GPIO to reset
the WWAN.
Support fgor WWAN could come at a later date. I have setup LAN4 of the
"for" has a typo.
device as WAN.
Signed-off-by: Ian Pangilinan
---
..
+
+_default {
+ gpio {
+ groups = "jtag", "rgmii2", "uart3", "wdt";
+ function = "gpio";
+ };
+};
.
+
+ {
+ ports {
+ port@0 {
+ status = "okay";
+ label = "wan";
+
+ nvmem-cells = <_factory_e006>;
+ nvmem-cell-names = "mac-address";
+ };
+
+ port@1 {
+ status = "okay";
+ label = "lan3";
+ };
+
+ port@2 {
+ status = "okay";
+ label = "lan2";
+ };
+
+ port@4 {
+ status = "okay";
+ label = "lan1";
+ };
+ };
This needs some adaptions, see
https://git.openwrt.org/f1c9afd801380a05a91d979b475c76cc0a67caae
+};
+
.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: fix compilation with GCC12
On 9/28/22 04:22, Rosen Penev wrote:
On Sun, Aug 21, 2022 at 7:54 AM Hauke Mehrtens wrote:
On 6/11/22 16:47, Bjørn Mork wrote:
e9hack writes:
The 'dangling pointer' issue can be fix without using malloc().
--- a/dev.c 2022-05-04 02:18:17.0 +0200
+++ b/dev.c 2022-06-11 08:48:21.185567953 +0200
@@ -206,6 +206,7 @@ void qmi_request_cancel(struct qmi_dev *
int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
{
bool complete = false;
+bool *c;
bool cancelled;
if (!req->pending)
@@ -226,8 +227,10 @@ int qmi_request_wait(struct qmi_dev *qmi
uloop_cancelled = cancelled;
}
- if (req->complete == )
-req->complete = NULL;
+c = req->complete;
+req->complete = NULL;
+if (c != )
+req->complete = c;
return req->ret;
}
How about just fixing GCC instead? Having all sorts of funny and
pointless code just to avoid bogus compiler warnings is kind of stupid,
isn't it?
If GCC can't do better that this, then it's much better to disable that
warning.
GCC complains about this code because the pointer is only removed
conditionally
---
if (req->complete == )
req->complete = NULL;
---
https://git.openwrt.org/?p=project/uqmi.git;a=blob;f=dev.c;h=bd1020790f844fd364fd753135acd8f53f34d996;hb=HEAD#l229
When you make this part unconditionally it does not complain any more.
Is it possible that something changes the req->complete pointer address
in between?
this is still an issue.
Hauke
Hi,
Is it possible to deactivate the error and make it only a warning which
we can ignore?
I would deactivate this error for the complete application and add a
comment to it that this is a workaround for GCC 12.
Did someone create a ticket at GCC for this problem? I am aware of the
one for elfutils only.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel/crypto: fix crypto-lib-curve25519 x86_64 build
On 7/21/22 15:17, Florian Eckert wrote: The crypto-lib-curve25519 dependency for x86_64 could not be met, because the package for for the architecture x86_64 was not added to crypto-lib-curve package. Also the package arch definition for x86/64 does not exist. It musst be change to x86_64 to get added. Maybe you should mention that you want to change it from depending on the x86/64 target to the x86_64 CPU config configuration. Signed-off-by: Florian Eckert --- package/kernel/linux/modules/crypto.mk | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index ed4e51079e..f31c4d5949 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -526,11 +526,16 @@ define KernelPackage/crypto-lib-curve25519/config imply PACKAGE_kmod-crypto-kpp endef -define KernelPackage/crypto-lib-curve25519/x86/64 +define KernelPackage/crypto-lib-curve25519/x86_64 KCONFIG+=CONFIG_CRYPTO_CURVE25519_X86 FILES+=$(LINUX_DIR)/arch/x86/crypto/curve25519-x86_64.ko endef I was looking into this code some time ago. I think the KCONFIG changes per target are not working. Does it work for you when nothing else directly selects the Kconfig symbol? I think the evaluation of the next lines is only working when Kconfig is finished, but I am not sure. +ifdef KernelPackage/crypto-lib-curve25519/$(ARCH) + KernelPackage/crypto-lib-curve25519/$(CRYPTO_TARGET)=\ + $(KernelPackage/crypto-lib-curve25519/$(ARCH)) +endif + define KernelPackage/crypto-lib-curve25519/arm-neon KCONFIG+=CONFIG_CRYPTO_CURVE25519_NEON FILES+=$(LINUX_DIR)/arch/arm/crypto/curve25519-neon.ko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] arm-trusted-firmware-mvebu: stop cluttering Image Builder
On 9/7/22 19:23, Tomasz Maciej Nowak wrote: W dniu 7.09.2022 o 00:15, Hauke Mehrtens pisze: On 8/31/22 17:03, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak All contents of staging_dir/image are included in Image Builder (IB) in case some binary needs to be included in final image. But in case of this package, all sources are stored there and those clutter the final tarball of IB for no reason. Those sources are not used during image creation and are just dead weight. To put it in perspective, the IB for 21.02.0 is 158 MiB, 22.03.0-rc6 is 366 MiB and snapshot is over 620 MiB! To fix it, put them in package build directory, so they won't end up included in IB tarball. With that, the custom clean definition can be removed, as the default one will take over. Signed-off-by: Tomasz Maciej Nowak Reviewed-by: Andre Heider --- v1 -> v2 - as pointed by Andre, we can use default clean definition - add his review tag I think the build times are much higher with this change compared to before. Yes, that's correct, since all source is extracted/rebuilt for each variant. The toolchain tarball is huge and it takes lot of time to extract. The second culprit is cryptopp. It's rebuilt for each variant with one job. I haven't found the time to do real measurements. I used this configuration to test: CONFIG_TARGET_mvebu=y CONFIG_TARGET_mvebu_cortexa53=y CONFIG_TARGET_mvebu_cortexa53_DEVICE_globalscale_espressobin=y I did measurements, before change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m17,046s user25m24,272s sys 1m49,963s with the change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real28m26,566s user79m45,906s sys 4m6,547s As You can see it's more than double. I also did test where $(BUILD_DIR) was used: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m19,462s user25m21,511s sys 1m53,047s which looks same as in current state (ignore spinning rust hiccups). Should I use $(BUILD_DIR) for the sources? did you mean a common folder in $(BUILD_DIR) with your $(BUILD_DIR) approach? I think it would be better to place the bootloader toolchain in some common place and not duplicated for each variant. Is cryptopp also common for all variant and only used on the host? Maybe we can make this all a host package? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] arm-trusted-firmware-mvebu: stop cluttering Image Builder
On 8/31/22 17:03, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak All contents of staging_dir/image are included in Image Builder (IB) in case some binary needs to be included in final image. But in case of this package, all sources are stored there and those clutter the final tarball of IB for no reason. Those sources are not used during image creation and are just dead weight. To put it in perspective, the IB for 21.02.0 is 158 MiB, 22.03.0-rc6 is 366 MiB and snapshot is over 620 MiB! To fix it, put them in package build directory, so they won't end up included in IB tarball. With that, the custom clean definition can be removed, as the default one will take over. Signed-off-by: Tomasz Maciej Nowak Reviewed-by: Andre Heider --- v1 -> v2 - as pointed by Andre, we can use default clean definition - add his review tag I think the build times are much higher with this change compared to before. I haven't found the time to do real measurements. I used this configuration to test: CONFIG_TARGET_mvebu=y CONFIG_TARGET_mvebu_cortexa53=y CONFIG_TARGET_mvebu_cortexa53_DEVICE_globalscale_espressobin=y Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 22.03.0 first stable release
Hi, The OpenWrt community is proud to announce the first stable release of the OpenWrt 22.03 stable version series. It incorporates over 3800 commits since branching the previous OpenWrt 21.02 release and has been under development for about one year. Download firmware image for your device (firmware selector): * https://firmware-selector.openwrt.org/?version=22.03.0 Download firmware images directly from OpenWrt download servers: * https://downloads.openwrt.org/releases/22.03.0/targets/ Highlights in OpenWrt 22.03.0 = Firewall4 based on nftables === Firewall4 is used by default, superseding the iptables-based firewall3 implementation in the OpenWrt default images. Firewall4 uses nftables instead of iptables to configure the Linux netfilter ruleset. Firewall4 keeps the same UCI firewall configuration syntax and should work as a drop-in replacement for fw3 with most common setups, emitting nftables rules instead of iptables ones. Including custom firewall rules through /etc/firewall.user still works, but requires marking the file as compatible first, otherwise it is ignored. Firewall4 additionally allows to include nftables snippets. The firewall documentation https://openwrt.org/docs/guide-user/firewall/firewall_configuration explains how to include custom firewall rules with firewall4. Some community packages that add firewall rules might not work for now, and will need to be adapted to fw4: this will happen gradually throughout the lifetime of the 22.03 release series. The legacy iptables utilities are not included in the default images anymore, but can be added back using opkg or the Image Builder if needed. The transitional packages iptables-nft, arptables-nft, ebtables-nft and xtables-nft can be used to create nftables rules using the old iptables command line syntax. Many new devices added == OpenWrt 22.03 supports over 1580 devices. Support for over 180 new devices was added in addition to the device support by OpenWrt 21.02. OpenWrt 22.03 supports more than 15 devices capable of Wifi 6 (IEEE 802.11ax) using the MediaTek MT7915 wifi chip. More targets converted to DSA = The following targets or boards were migrated from swconfig to DSA with OpenWrt 22.03 in addition to the systems already migrated with OpenWrt 21.02: * bcm53xx: All board using this target were converted to DSA * lantiq: All boards using the xrx200 / vr9 SoC * sunxi: Bananapi Lamobo R1 (only sunxi board with switch) Dark mode in LuCI = The LuCI bootstrap design supports a dark mode. The default design activates dark mode depending on the browser settings. Change it manually at “System” -> “System” -> “Language and Style”. Year 2038 problem handled = OpenWrt 22.03 uses musl 1.2.x, which changed the time_t type from 32 bit to 64 bit on 32 bit systems, on 64 bit system it was always 64 bit long. When a Unix time stamp is stored in a signed 32 bit integer it will overflow on 19 January 2038. With the change to 64 bit this will happen 292 billion years later. This is a change of the musl libc ABI and needs a recompilation of all user space applications linked against musl libc. For 64 bit systems this was done when the ABI was defined many years ago, the glibc ARC ABI already has a 64 bit time_t. Core components update == Core components have the following versions in 22.03.0: * Updated toolchain: * musl libc 1.2.3 * glibc 2.34 * gcc 11.2.0 * binutils 2.37 * Updated Linux kernel * 5.10.138 for all targets * Network: * hostapd 2.10, dnsmasq 2.86, dropbear 2022.82 * cfg80211/mac80211 from kernel 5.15.58 * System userland: * busybox 1.35.0 In addition to the listed applications, many others were also updated see the detailed Changelog for more information. https://openwrt.org/releases/22.03/changelog-22.03.0 Upgrading to 22.03.0 Sysupgrade can be used to upgrade a device from OpenWrt 21.02 to 22.03, and configuration will be preserved in most cases. Upgrades from a previous 22.03.0 release candidate are also supported. * Sysupgrade from 19.07 to 22.03 is not supported. * There is no migration path for targets that switched from swconfig to DSA. In that case, sysupgrade will refuse to proceed with an appropriate error message: Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.0 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.0#known_issues For a detailed list of all changes since 21.02, refer to
Re: [PATCH] umdns: add timeout_lookup parameter for services
On 8/26/22 13:40, Tobias Waldvogel wrote:
From: Tobias Waldvogel
Printing on Android devices via mdns IPP does not work
with the default value of 60 seconds for the
lookup timeout. It seems that Androd expects an
immediate answer just when trying to print. Nevertheless
the umdns debug messages show that the answer is supressed
due to the timeout. As a result the printer does not
show up.
This patch implements an additional parameter
timeout_lookup for setting a dedicated timeout value
with a fallback to TOUT_LOOKUP (60s).
This is a sample ipp service definition, which works
now with Android standard printing:
{
"ipp": {
"service": "_ipp._tcp.local",
"instance": "HL3040CN @ router",
"port": 631,
"timeout_lookup": -1,
"txt": [
"txtvers=1",
"UUID=308f65f9-5393-3027-4c83-374cb704e729",
"rp=printers/HL3040CN",
"ty=Brother HL3040CN",
"note=Office",
"pdl=application/pdf,image/jpeg,image/png,image/pwg-raster",
"Color=T",
"Copies=T"
]
}
}
Signed-off-by: Tobias Waldvogel
The white spaces in this patch are damaged.
It is also broken in patchwork:
https://patchwork.ozlabs.org/project/openwrt/patch/caaatp75fm8oavryfdzty2bvccmoh8pns0pxv+lpxpxcxu7h...@mail.gmail.com/
You could use "git send-email" to send the patch for example.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
