Please open a bug.
In regards to the eip93 for mediatek , it looks like there were "Changes since V3" patch series (so a v4 patch?) that of which a submission was attempted to the device tree mailing list as requested by one of the maintainers, this v4? even looks like it might of been reviewed, I don't know what happened after that, maybe it got lost?
https://lore.kernel.org/all/YYF3V0FzIwhIuyNK@robh.at.kernel.org/
I believe that was a result of the already-fixed bug in the Firmware Selector that dropped some profile-specific package lists (https://github.com/openwrt/firmware-selector-openwrt-org/commit/389605be2f026b3aa1d73844f4b1601b916da137), so no need...
I have issues updating my PC Engines ALIX ( x86/geode ) to 23.05.5 with ASU.
"Server response: [object Object]"
What client are you using? Could you show me your ubus call system board output, so I can try to duplicate it?
ubus call system board
{
"kernel": "5.15.162",
"hostname": "OpenWrt",
"system": "Geode(TM) Integrated Processor by AMD PCS",
"rootfs_type": "ext4",
"release": {
"distribution": "OpenWrt",
"version": "23.05.4",
"revision": "r24012-d8dd03c46f",
"target": "x86/geode",
"description": "OpenWrt 23.05.4 r24012-d8dd03c46f"
}
}
ASU gives
{
"url": "https://sysupgrade.openwrt.org",
"revision": "r24012-d8dd03c46f",
"advanced_mode": "1",
"sha256_unsigned": "",
"branch": "23.05",
"efi": null,
"profile": "x86/geode",
"target": "x86/geode",
"version": "23.05.4",
"packages": [
"announce",
"attendedsysupgrade-common",
"auc",
"avahi-daemon-service-http",
"avahi-daemon-service-ssh",
"avahi-dbus-daemon",
"avahi-utils",
"base-files",
"boinc",
"boinc-wrapper",
"busybox",
"bzip2",
"ca-bundle",
"cgi-io",
"collectd-mod-df",
"collectd-mod-disk",
"collectd-mod-dns",
"collectd-mod-entropy",
"collectd-mod-ethstat",
"collectd-mod-ntpd",
"collectd-mod-sensors",
"coreutils",
"coreutils-stat",
"curl",
"dnsmasq",
"dropbear",
"e2fsprogs",
"ethtool-full",
"fdisk",
"firewall4",
"fstools",
"fwtool",
"getrandom",
"grub2",
"grub2-bios-setup",
"grub2-editenv",
"grub2-efi",
"jansson",
"jshn",
"jsonfilter",
"kernel",
"kmod-button-hotplug",
"kmod-crypto-acompress",
"kmod-crypto-arc4",
"kmod-crypto-cbc",
"kmod-crypto-crc32c",
"kmod-crypto-ecb",
"kmod-crypto-hash",
"kmod-crypto-hw-geode",
"kmod-fs-cifs",
"kmod-fs-vfat",
"kmod-input-core",
"kmod-ledtrig-gpio",
"kmod-lib-crc-ccitt",
"kmod-lib-crc32c",
"kmod-lib-lzo",
"kmod-lp",
"kmod-mii",
"kmod-nf-conntrack",
"kmod-nf-conntrack6",
"kmod-nf-flow",
"kmod-nf-log",
"kmod-nf-log6",
"kmod-nf-nat",
"kmod-nf-reject",
"kmod-nf-reject6",
"kmod-nfnetlink",
"kmod-nft-core",
"kmod-nft-fib",
"kmod-nft-nat",
"kmod-nft-offload",
"kmod-nls-base",
"kmod-nls-cp437",
"kmod-nls-iso8859-1",
"kmod-nls-utf8",
"kmod-ppp",
"kmod-pppoe",
"kmod-pppox",
"kmod-slhc",
"kmod-usb-ledtrig-usbport",
"kmod-usb-ohci",
"kmod-usb-printer",
"kmod-via-rhine",
"ksmbd-server",
"libatomic",
"libavahi-compat-libdnssd",
"libblkid",
"libblobmsg-json",
"libbz2",
"libc",
"libcap",
"libcomerr",
"libcurl",
"libevent2-core",
"libevent2-pthreads",
"libext2fs",
"libf2fs",
"libiwinfo",
"libiwinfo-data",
"libiwinfo-lua",
"libjson-c",
"libjson-script",
"liblua",
"liblucihttp",
"liblucihttp-ucode",
"libmbedtls",
"libmnl",
"libncurses",
"libnftnl",
"libnl-tiny",
"libopenssl",
"libopenssl-conf",
"libparted",
"libpng",
"libsane",
"libsmartcols",
"libss",
"libstdcpp",
"libubox",
"libubus",
"libuci",
"libuclient",
"libucode",
"libustream-mbedtls",
"libuuid",
"libwolfssl",
"lm-sensors-detect",
"logd",
"losetup",
"lua",
"luci",
"luci-app-advanced-reboot",
"luci-app-firewall",
"luci-app-ksmbd",
"luci-app-ledtrig-rssi",
"luci-app-ledtrig-switch",
"luci-app-ledtrig-usbport",
"luci-app-opkg",
"luci-app-p910nd",
"luci-app-snmpd",
"luci-app-statistics",
"luci-base",
"luci-compat",
"luci-i18n-advanced-reboot-de",
"luci-i18n-attendedsysupgrade-de",
"luci-i18n-base-de",
"luci-i18n-dashboard-de",
"luci-i18n-firewall-de",
"luci-i18n-ksmbd-de",
"luci-i18n-opkg-de",
"luci-i18n-p910nd-de",
"luci-i18n-statistics-de",
"luci-lib-nixio",
"luci-light",
"luci-mod-admin-full",
"luci-mod-network",
"luci-mod-status",
"luci-mod-system",
"luci-proto-ipv6",
"luci-proto-ppp",
"luci-ssl",
"luci-theme-bootstrap",
"luci-theme-material",
"luci-theme-openwrt",
"luci-theme-openwrt-2020",
"mkf2fs",
"mtd",
"nano-full",
"netifd",
"nftables-json",
"ntp-keygen",
"ntp-utils",
"ntpdate",
"odhcp6c",
"odhcpd-ipv6only",
"open-plc-utils",
"open-plc-utils-plcdevs",
"open-plc-utils-plclist",
"open-plc-utils-plctool",
"openssh-sftp-avahi-service",
"openssh-sftp-server",
"openssl-util",
"openwrt-keyring",
"opkg",
"p910nd",
"parted",
"partx-utils",
"perl",
"perlbase-base",
"perlbase-bytes",
"perlbase-class",
"perlbase-config",
"perlbase-cwd",
"perlbase-errno",
"perlbase-essential",
"perlbase-fcntl",
"perlbase-file",
"perlbase-list",
"perlbase-posix",
"perlbase-tie",
"perlbase-xsloader",
"ppp",
"ppp-mod-pppoe",
"procd",
"procd-seccomp",
"procd-ujail",
"procps-ng",
"procps-ng-pmap",
"px5g-mbedtls",
"resize2fs",
"rpcd",
"rpcd-mod-file",
"rpcd-mod-iwinfo",
"rpcd-mod-luci",
"rpcd-mod-rrdns",
"rpcd-mod-ucode",
"sane-canon",
"sane-daemon",
"sane-frontends",
"sane-pixma",
"sane-xerox_mfp",
"smbinfo",
"snmp-mibs",
"snmp-utils",
"tcpdump",
"ubox",
"ubus",
"ubusd",
"uci",
"uclient-fetch",
"ucode",
"ucode-mod-fs",
"ucode-mod-html",
"ucode-mod-math",
"ucode-mod-ubus",
"ucode-mod-uci",
"uhttpd",
"uhttpd-mod-ubus",
"umdns",
"urandom-seed",
"urngd",
"usbids",
"usbip",
"usbip-client",
"usbip-server",
"usbutils",
"usign",
"wsdd2",
"xinetd",
"zlib"
],
"diff_packages": true,
"filesystem": "ext4",
"client": "luci/undefined"
}
Ah, I see it. The ubus system board call should be showing a board_name field, which tells sysupgrade what profile to use. Apparently the missing board name gets propagated into the json you show above as the profile (the line where it says "profile": "x86/geode", which is incorrect) and that causes the ASU server some problems (it expects either generic or geos, i.e., one of the profile keys from https://downloads.openwrt.org/releases/23.05.5/targets/x86/geode/profiles.json).
Try this:
echo "generic" > /tmp/sysinfo/board_name
ubus call system board | grep board_name
and if that last command produces "board_name": "generic",, then it should be good to try again.
There is no directory /tmp/sysinfo and no file board_name
That's not good, I wonder what's up with that? Try a mkdir /tmp/sysinfo/ first, then do those other two commands.
Thx.
I did two things:
- chose profile 'generic' in ASU page --> firmware upgrade is built
- applied your suggestions --> profile 'generic' shows up in page, firmware is built
Upgrade worked!!
But after reboot the directory /tmp/sysinfo is gone.
EDIT:
Some further investigation shows, that vendor and board_name are generate from DMI. This device doesn't exist for ALIX2e.
Ah, that sort of explains it. It sure seems like it should put at least something in the /tmp/sysinfo files when the uci-defaults are executed at boot, though... And at least you know the workaround for next time. 
1 Like
Can anyone confirm if the 23.5.4 ipq806x throughput issue is fixed in this release?
Very similar with Linksys WRT3200ACM.
The USB is detected once every two boots. Strangely, its detected properly if unpluged/pluged.
Kind regards.
Linksys WRT1900ACS, custom image (imagebuilder) succesfully upgraded from 23.05.3: many thanks to all the devs.
1 Like
Wifi devices getting stuck in NSS1 mode is fixed. Though measure and consider rollback.
I believe that's this included fix which affected many targets:
- mac80211: fix wifi throughput regression
3 Likes
For the 3200ACM, it seems my WireGuard setup has regressed. While I get a connection to the router, I can’t access my LAN devices. Still checking if it’s user error on my part or if there is a small remediation I can do.
EDIT: was just user error
I've had some issues upgrading to this version on 2 of my devices.
-
TP-Link C6U used as a dumb AP with some VLANs, no extra packages. I flashed the sysupgrade version (downloaded from official releases, not firmware-selector) then the unit never came back up. I could only physically reach it after ~24 hours and I found it with just the power LED on, everything else off. Wireshark in any of the ports reported no traffic. My guess is the new firmware just failed to boot and it was just sitting there doing nothing. I power cycled it and it booted fine to 23.05.5 with the config preserved and everything working, but I immediately downgraded to 23.05.4.
-
TP-Link C6 V2 used as a dumb AP, no extra functionality, no extra packages. I flashed the new version, it came back up fine, went in to disable firewall / dnsmasq / odhcpd and rebooted, then it didn't come back up fine, because I had no traffic passing over LAN ports. Attached Wireshark and I could see a really ugly broadcast storm of pause frames being passed around.
LAN ports were dead, so I managed to connect over WLAN with a static IP (because I couldn't reach DHCP), and the router looked fine in LuCI. I pulled the system logs and kernel logs, and rebooted. It came back up fine this time. I compared the logs to the ones from a successful boot but there was no notable difference. Downgraded to 23.05.4 and called it a day.
So that's 2 devices out of 7 that I upgraded which had issues, and I guess you can call it a coincidence, because none of these problems really sticked. But it's also very suspicious that it happened to two separate devices at once (in different physical locations), where I had previously upgraded these units tens of times before with no issues ever.
ramips/mt7620 TP-Link Archer C2 v1
In version 23.05.5 there are frequent hangs of the 2.4 GHz WiFi network. Helps "wifi down radio1; wifi up radio1" or restarting the device. The log only contains:
Tue Sep 24 16:14:42 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Tue Sep 24 16:14:42 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Tue Sep 24 16:15:12 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Sep 24 16:15:17 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Tue Sep 24 16:15:17 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 3)
Tue Sep 24 16:15:17 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=open
Tue Sep 24 16:15:17 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Tue Sep 24 16:15:17 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Tue Sep 24 16:15:17 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.110 xx:xx:xx:xx:xx:xx
Tue Sep 24 16:15:48 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs
Tue Sep 24 16:15:48 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Tue Sep 24 16:16:18 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Sep 24 16:16:22 2024 daemon.info hostapd: phy1-ap0: STA yy:yy:yy:yy:yy:yy IEEE 802.11: disconnected due to excessive missing ACKs
Tue Sep 24 16:16:22 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED yy:yy:yy:yy:yy:yy
Tue Sep 24 16:16:41 2024 daemon.notice hostapd: phy1-ap0: yy:yy:yy:yy:yy:yy IEEE 802.11: did not acknowledge authentication response
Tue Sep 24 16:16:42 2024 daemon.notice hostapd: phy1-ap0: yy:yy:yy:yy:yy:yy IEEE 802.11: did not acknowledge authentication response
Tue Sep 24 16:16:43 2024 daemon.notice hostapd: phy1-ap0: yy:yy:yy:yy:yy:yy IEEE 802.11: did not acknowledge authentication response
Tue Sep 24 16:16:44 2024 daemon.notice hostapd: phy1-ap0: yy:yy:yy:yy:yy:yy IEEE 802.11: did not acknowledge authentication response```Xiaomi AX3600 works without problems since more than 5 days.
I use all three Wifi devices, wireguard, mesh, ...
Uwe