OpenWrt 23.05.5 - Service Release

bism · October 9, 2024, 3:46pm

ramips/mt7621 Linksys EA7500 v2

Flooded with beacon messages. They appear every 5 seconds. v23.05.4 didn't have these.

Masked MAC are iPads and iPhones

Wed Oct  9 23:53:18 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 13 ack=1
Wed Oct  9 23:53:18 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 13 04
Wed Oct  9 23:53:23 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 14 ack=1
Wed Oct  9 23:53:23 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 14 04
Wed Oct  9 23:53:28 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 15 ack=1
Wed Oct  9 23:53:28 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 15 04
Wed Oct  9 23:53:33 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 16 ack=1
Wed Oct  9 23:53:33 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 16 04

Masked MAC is an Android device:

Wed Oct  9 23:37:45 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 52 00 80300000000000000000000000aa0058e~~truncated long sequence
Wed Oct  9 23:37:50 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 53 ack=1
Wed Oct  9 23:37:50 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 53 00 51010000000000000000000002c60058e~~truncated long sequence
Wed Oct  9 23:37:55 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 54 ack=1
Wed Oct  9 23:37:55 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 54 00 80300000000000000000000000c60058e~~truncated long sequence
Wed Oct  9 23:38:00 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 55 ack=1
Wed Oct  9 23:38:00 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 55 00 5100000000000000000000008000000000000000000000000000
Wed Oct  9 23:38:05 2024 daemon.notice hostapd: phy1-ap0: BEACON-REQ-TX-STATUS xx:xx:xx:xx:xx:xx 56 ack=1
Wed Oct  9 23:38:05 2024 daemon.notice hostapd: phy1-ap0: BEACON-RESP-RX xx:xx:xx:xx:xx:xx 56 00 80300000000000000000000000aa0058e~~truncated long sequence

qunvureze · October 9, 2024, 4:22pm

Isn't this DAWN asking stations how they hear the AP?

bism · October 9, 2024, 5:18pm

You're right. It's DAWN to blame. Even loglevel 5 generates these annoying logs. Moreover there is no any tag relating to DAWN, misled me to /etc/config/wifi, instead of /etc/config/dawn.

I found no way to turn it off, as long as DAWN is running.

qunvureze · October 9, 2024, 9:09pm

Play with wireless log filtering. There’s log_80211 option which might silence these entries.

Depending on how you use DAWN, you can increase DAWN's timer value to something like 60: update_beacon_reports to see less of these entries.

bism · October 10, 2024, 3:09am

Thank you for the valuable info. But the problem persists.

It's for sure DAWN related. Because if we stop dawn service, the beacon messages are no more.

/etc/config/dawn update_beacon_reports is set to 20. If this setting had any effect, the beacon log should have been generated every 20 seconds, not every 5 seconds.

/etc/config/wireless log_level is set to 4, it doesn't affect the beacon messages.

I haven't been able to find where to put log_80211 as you mentioned. Would you put it in more detail? Thanks in advance!

Again, v23.05.4 didn't have this issue.

qunvureze · October 10, 2024, 7:10am

Put it next to the log_level option and set to 0. I haven’t tested if this hides that log entry.

In my case DAWN timer adjustment works as expected.

tsengf · October 10, 2024, 11:37pm

I wanted to share my experience with 23.05.5. I have a Netgear R7800. I upgraded without any issues and the system was working properly. However, I've noticed that the 5.4GHz radio randomly goes offline and back online and in some cases, going offline completely until I reboot the device. I've tried resetting the device as well as reflashing. Nothing seems to help. I eventually went back to 23.05.3 and the 5.4GHz radio seems stable again.

bism · October 11, 2024, 4:42am

I have tried log_80211. It seems log_level and log_80211 don't affect the DAWN beacon log. Those log lines come and go with the DAWN process.

wifi status
"radio1": {
		"config": {
				"log_level": 4,
				"log_80211": false,

Still waiting for a fix.

jbrodriguez · October 13, 2024, 11:58am

successful update using attended sysupgrade on a netgear wax206, took me about 2 min
thanks a lot for those who sponspor the asu infrastructure

GetVladimir · October 14, 2024, 10:13am

If anyone else is using the WebSSH app (or similar SSH apps on Mobile) and keeps getting errors when logging in to OpenWrt 23.05.5 like this:

Connection failed: Unable to agree upon server-to-client MAC algorithm

And it also shows this error in OpenWrt system log:

No matching algo mac c->s

Add this in the ssh_config (/etc/ssh/ssh_config) file of the app or client itself:

Host *
    MACs hmac-sha2-256,hmac-sha2-512

This will enable the missing MAC algos and should proceed to connect.

Source: https://webssh.net/documentation/help/SSH/supported-algorithms/#macs

wokkocher · October 14, 2024, 7:51pm

Hey all, thank you for all the work!

Yesterday I returned from vacation and I upgraded some of my devices from 23.05.4 to 23.05.5 - at least I tried. First, I successfully upgraded my two main road warriors (GL-AR750s). As this went smoothly and fine, I smiled and got some good mood. I decided to upgrade two other devices (GL-AR150) and run into some trouble.

I alway flash the plain sysupgrade binary without any customization from ASU, keep settings and use /etc/rc.local for reinstallation of all packages I need. So for, the flashing worked. What did not work was the reinstallation of additional packages. I tried to debug this, but I not sure if I found the error. It turned out, both devices got a network address. Both failed to do opkg update .

System log for opkg update

Mon Sep 23 14:41:20 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/targets/ath79/generic/packages/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/targets/ath79/generic/packages/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/base/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/base/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/luci/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/luci/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/packages/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/packages/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/routing/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/routing/Packages.gzCollected errors:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/targets/ath79/generic/packages/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/base/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/luci/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/packages/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/routing/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:  * opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/telephony/Packages.gz, wget returned 5.
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done:
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: Downloading https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/telephony/Packages.gz
Mon Sep 23 14:41:23 2024 daemon.notice procd: /etc/rc.d/S95done: *** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.5/packages/mips_24kc/telephony/Packages.gz

According to the system log ( opkg_download: Failed to download https://downloads.openwrt.org/releases/23.05.5/targets/ath79/generic/packages/Packages.gz, wget returned 5. ), I tried to figure out what that means. If I read the source of uclient-fetch correctly, error code 5 means some problems with https certificates. That matches the fact, I was not able to do opkg update via luci in the software tab. The same error occured.

In contrast I was able to ssh to both devices and run

/bin/sh -x /etc/rc.local

to debug even more. This run through without any error. HOW? WHY? opkg update runs clean, all additional software got installed, now both devices are working fine. Even a reflashing did not cause any error. Did I do a certificate update by accident? Why does a re-flash run clean now?

I am afraid to upgrade my main devices now (3x GL-AR300m and 1x GL-MT300n-v2), I would like to avoid this scenario. Does anyone see a failure?

EDIT:
Only one device is ok with re-flashing. The oher one has the same problems again.

efahl · October 14, 2024, 8:26pm

I'd bet $10 that the clock skew was causing SSL to say "NO!", so wget raised error 5. Once the clock is set to the correct time, then everything works fine.

You may be able to avoid this in the future by doing something like touch /etc/urandom.seed, thus giving the pre-NTP clock something to work with (failing all else, startup sequence sets the current time to the stamp on the newest file in /etc...).

EDIT: do that touch just before you do sysupgrade...

wokkocher · October 14, 2024, 8:31pm

You earned $10... Meh Thanks. I just wonder why NTP failed and keeps failing even after minutes. I set 2 servers, the provided home-router of my ISP (192.168.x.y something) and time.cloudflare.com. Both should be accessable, the first one even without DNS. Puh.

EDIT: I found out why. It is my fault, that I enabled ntpd for local networks. The ntp service crashed because of a configuration mistake in the specified binding interfaces.

A stupid self-made mistake, but I found it. So I can confirm, 23.05.5 works fine for me. Tomorrow, I will upgrade the other devices.

efahl · October 14, 2024, 10:10pm

Woo! I'm rich!

Notwithstanding your config error, sometimes the network isn't up yet when NTP makes it's first request and that borks it, even with a raw IP. (ntpd seems to be somewhat fragile, given the number of threads that point to it doing something wrong at WAN or LAN startup.)

To partially mitigate issues with that, I make a point of putting that touch command in my /etc/.profile on all of my devices that don't have a "mobo battery", so whenever I log in it gets a recent timestamp (which works for me, as I always do my upgrades from the cli and hence have just sshed into the device; other peoples' experience will of course vary).

waynea · October 15, 2024, 8:40am

just upgraded my NanoPi R4S with no issues fund. Thanks all, I cant get over how amazing the OpenWRT project really is!

WildByDesign · October 16, 2024, 3:11pm

I finally upgraded my WRT3200ACM to 23.05.5 from 23.05.3 and everything is working wonderfully as expected.

vinu · October 17, 2024, 2:08pm

Upgraded a Linksys E8450 from 23.05.3 to 23.05.5 using sysupgrade with a downloaded image and with settings retained. Upgrade was uneventful and everything works fine the past few days.

Thank you devs!.

badulesia · October 20, 2024, 6:33pm

Hi.
Just tried file transfers LAN -> wifi. Transfers reach 60MB/s+ which is outstanding. I don't remember such performances before.

On the other hand I have tested the latest main snapshot, and the device still have the LAN to LAN issues. I fear for the incoming 24.10 version.

Klingon · October 21, 2024, 5:56am

Thanks for your feedback @badulesia I'll check it again, now I'm running stock firmware.

CryptoWizard · October 21, 2024, 3:07pm

I'm behind in upgrading. Never upgraded my OpenWrt yet.

I'm running 23.05.0, on an R4S.

I do have a backup SD with my current setup in case of problems.

The post above says 23.05.0 -> 23.05.5 should be supported via Sysupgrade.

I have downloaded a Sysupgrade generated image file.....

openwrt-23.05.5-a6522374ed70-rockchip-armv8-friendlyarm_nanopi-r4s-ext4-sysupgrade.img.gz

I've also backed up my config via Flash Operations / Backup.

The backup process seems to include additional packages installed.

Does Sysupgrade collect the latest packages for additional modules installed?
I have Wireguard (used) & Keepalived (not used).