Re: OpenWrt 23.05.0 - First stable release
Congratulations on an epic release All the best, Nicholas All the best, Nicholas Nicholas Smith NB Embedded Pty Ltd nicho...@nbembedded.com ABN: 54 663 236 940 https://nbembedded.com On Fri, 13 Oct 2023 at 19:26, Hauke Mehrtens wrote: > > 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:
Re: Developer Meeting November 2022
If a move from Github is inevitable, should we continue investing in Github, i.e. start auto-labelling tickets, making new templates, etc? For auto-closing bugs, perhaps a good policy is to auto-close bugs for any unsupported release. We could automate notifications to the reporters to let them know that this bug was reported on a release that's reaching EoL, and to reopen it anew on a supported version if it is present. All the best, Nicholas All the best, Nicholas Nicholas Smith NB Embedded Pty Ltd nicho...@nbembedded.com ABN: 54 663 236 940 Book a Meeting On Fri, 2 Dec 2022 at 06:22, Paul Spooren wrote: > > Hi all, please find our notes from yesterdays meeting below: > > https://openwrt.org/meetings/20221130 > > Feel free to comment in this thread. > > Sunshine, > Paul > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: add blink and turnoff commands to the led script
ACK I like this. Good for many applications, not the least of which
include a quick "stealth mode" LED setting or warning/notification LED
blink patterns.
All the best,
Nick
On Mon, 28 Jun 2021 at 17:18, John Crispin wrote:
>
> This allows us to make all leds blink or force all leds to off.
> It is also possible to force the default behaviour to not load
> any led states/triggers by setting system.@system[-1].leds_off
> to 1.
>
> Signed-off-by: John Crispin
> ---
> package/base-files/files/etc/init.d/led | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/package/base-files/files/etc/init.d/led
> b/package/base-files/files/etc/init.d/led
> index 51cb8b5178..252bba623a 100755
> --- a/package/base-files/files/etc/init.d/led
> +++ b/package/base-files/files/etc/init.d/led
> @@ -3,6 +3,9 @@
>
> START=96
>
> +extra_command "turnoff" "Turn all leds off"
> +extra_command "blink" "Blink all leds"
> +
> load_led() {
> local name
> local sysfs
> @@ -121,7 +124,25 @@ load_led() {
> }
> }
>
> +turnoff() {
> + for led in `ls /sys/class/leds/`; do
> + echo none > /sys/class/leds/$led/trigger
> + echo 0 > /sys/class/leds/$led/brightness
> + done
> +}
> +
> +blink() {
> + for led in `ls /sys/class/leds/`; do
> + echo 0 > /sys/class/leds/$led/brightness
> + echo timer > /sys/class/leds/$led/trigger
> + done
> +}
> +
> start() {
> + [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
> + turnoff
> + exit 0
> + }
> [ -e /sys/class/leds/ ] && {
> [ -s /var/run/led.state ] && {
> local led trigger brightness
> @@ -137,5 +158,7 @@ start() {
>
> config_load system
> config_foreach load_led led
> + . /etc/diag.sh
> + set_state done
> }
> }
> --
> 2.25.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
netifd: Information events with proto_notify_info()
Hello, My goal is to add a way to notify users via netifd about "info" events for interfaces instead of only "errors", by adding support for a function called proto_notify_info(). Currently, I am (ab)using proto_notify_error() in modemmanager.sh to indicate what is happening during the sometimes long and error prone process of establishing a mobile data connection. However, most of the time the events are not strictly speaking "errors", but due to the way things currently are (unless I am missing something), they are displayed like errors. This has been the source of some confusion among users, for instance: "Why does it say 'Error: Connection attempt in progress' when it probably should say 'Info: connection attempt in progress'?" Actually, I can think of a number of events like that which I could use this feature on, which is why I would like to implement it. So, is there support for this already, or is this something I can add to netifd and the corresponding scripts? Would this be a welcome change upstream or too niche? All the best, Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
