That is typically/often caused by an incorrect network configuration from a local software point of view (which differs from it working correctly as a router from other connected devices).
Things to check:
is default gateway set correctly (if not main router)
is dns set correctly on your interface(s)? Check /etc/resolv.conf and try a local βping OpenWRT.orgβ just see what happens.
Easiest way to check would be if you ssh into your pi device and type ip route. If the output doesn't have any lines starting with default then that is your issue.
I don't have complete understanding of when that happens but I think it is likely to happen in any openwrt 23 installation using wifi as a client (as opposed to an AP).
Edit is not available anymore so I'll use reply..."full sysupgrade" did the work (thanks to badulesia for pointing that out.)...tried twice attended sysupgrade and both radio's were gone after update. After "full sysupgrade" everything works...well except the LEDs - LAN1-3 still have green LEDs on even though previously v22.03.5 was able to keep all the lights off.
It seems that all of the packages are downloaded with IPv4 except the telephony package which is attempting to be delivered over IPv6 and that's failing for some reason. Why just this one package when they're all coming from the same host, I have no idea. At least now I have some sense of what problem to look for though.
To debug this, I needed to see the detailed output of wget when invoked by opkg. Unfortunately, opkg passes a the -q quiet flag to wget unconditionally (even when run in verbose mode).
So I made a shell script to intercept the wget invocation and strip the first argument.
vim /tmp/wget
#!/bin/ash
shift
/usr/bin/wget $@
Then we run it!
chmod +x /tmp/wget
export PATH=/tmp:$PATH
opkg update
<snipped for brevity>
Downloading 'https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/routing/Packages.sig'
Connecting to 168.119.138.211:443
Writing to '/tmp/opkg-MaejNh/Packages.sig'
/tmp/opkg-MaejNh/Pac 100% |*******************************| 142 0:00:00 ETA
Download completed (142 bytes)
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz
Downloading 'https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz'
Connecting to 2a01:4f8:251:321::2:443
Connection error: Connection failed
*** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz
At least I have some idea where to look. This device isn't sending neighbor solicitations for IPv6 addresses across the bridge but it started working after I restarted the network interface. Could be a regression (race condition on startup?) but it needs further investigation.
@hauke please can you amend your opening post above to further include this warning for the Zyxel users:
The prebuilt images for Zyxel NR7101 are currently broken and will brick your device. PLEASE DO NOT INSTALL. (bug already fixed but require SNAPSHOT or self-compile).
Update went prefect on my TP Link C2600 by using sysupgrade from 22.03.05 to 22.05.0 stable and retaining settings. (the LUCI, Attended Sysupgrade as I first tried was not working due to the switch from wolfssl to mbedtls). Thanks for the update!
The issue with uwsgi seems to have been resolved, and I could install all the needed packages.
It is not working, but I guess I need to update my configuration.
Flawless upgrade from 22.03.2 to 23.05.0 on my Linksys WRT3200ACM using sysupgrade, all settings retained.
I am not using the WIFI options and just using one LAN-port, so I stayed on version 22.03.2 waiting for 'relief' from the 23.05 version. First 24 hours of operations on 23.05.0 without any issues to report.
Thanks to everybody who contributed to this release. It feels great to be back in the current release.
Just to see how it would go, I "sidegraded" an x86 VM I have that was running last Monday's snapshot: auc -y -b 23.05 -B 23.05.0
The kernel upgraded from .133 to .134, but a handful of packages and kmods downgraded in version. Everything is working just fine, subnet restored and nothing funky going on in the system logs.
Just did an Archer C7 v4 from 22.03.5 -> 23.05.0, worked fine and everything is connecting as expected. Extra packages include adblock and my usual suite of network tools (nmap, tcpdump, conntrack...). The wolfssl packages were auto-replaced with the mbedtls and the configuration has no visible hiccups.
The English translation for adblock was dropped, as expected:
$ auc -y -b 23.05
auc/0.3.1-1
Server: https://sysupgrade.openwrt.org
Running: 22.03.5 r20134-5f15225c1e on ath79/generic (tplink,archer-c7-v4)
Available: 23.05.0 r23497-6637af95aa
Requesting package lists...
...
Package libustream-wolfssl should be replaced by libustream-mbedtls.
libustream-wolfssl: 2022-12-08-9217ab46-2 -> libustream-mbedtls: 2023-02-25-498f6e26-1
...
Package wpad-basic-wolfssl should be replaced by wpad-basic-mbedtls.
wpad-basic-wolfssl: 2022-01-16-cff80b4f-16.2 -> wpad-basic-mbedtls: 2023-09-08-e5ccbfc6-4
...
Package px5g-wolfssl should be replaced by px5g-mbedtls.
px5g-wolfssl: 6.2 -> px5g-mbedtls: 9
...
installed package luci-i18n-adblock-en cannot be found in remote list!
Requesting build...
Downloading image from https://sysupgrade.openwrt.org/store/85598b411ca57eaea5492e44c94ce516/openwrt-23.05.0-de0dc218a1a2-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin
Writing to 'openwrt-23.05.0-de0dc218a1a2-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin'
image verification succeeded
invoking sysupgrade
Memory use with about 65k entries in my adblock table is 35%, cached is 15% and free is 51%. Flash use is still pretty low, so it looks like this device will live on for quite a while: