Main router (nanopi r4s) -> 2 archer c6v3 as dumb AP
today i just upgrade one of the archer c6v3 using sysupgrade from 23.05.2 to 23.5.3 and after upgrade finish, i cant access the dumb ap of that router no matter what i do.
ive rebooted main router, restarted interfaces, reboot the pc, i cant access the dumb ap luci interface trough wireless or ethernet.
i have normal internet connection btw, and i can access the main router and the modem.
i cannot ping the updated dumb ap router or access trough ssh either
My network is current configured on a 192.168.2.XXX range.
If any1 can give me a solution for this because i dont really want to factory reset and setup all over again, this is so annoying and is the second time that this happens when upgrade openwrt versions.
Isolate the AP from the network, connect a PC directly and ping 192.168.1.1. If so the AP is reset to its default values and you need to reconfigure it.
This is slightly strange as I'd expect the filename to be: openwrt-23.05.3-ramips-mt7621-tplink_archer-c6-v3-squashfs-sysupgrade.bin
But, you did get the sysupgrade file, so as long as the file was intact, everything should be okay.
How have you verified this? I assume from the main router? Does the leasetime correspond to the last time it was rebooted/power-cycled/connected via ethernet to your network?
Can you ping the device at the IP that has been issued?
Note that you need to disconnect the AP from your network and connect directly via ethernet to your computer. Your computer's ethernet interface must be set with a manually configured static IP and it is usually a good idea to ensure that there are no other active network interfaces (turn off wifi, if applicable).
If you can reproduce (and document) exactly the conditions that caused the issue, it would be possible to further investigate. But without specifics about the previous config, it'll be effectively impossible to do. Thus far, the upgrade appears to be smooth for most and what you've experienced doesn't appear to be a common situation.
Do you happen to have a backup of your config prior to the upgrade?
beside the changes of the common dumb ap configuration, i only installed nano and irqbalance and edited the config of irqbalance for its proper running, since it greatly improve my wifi performance. everything else is on default and AP was running on DHCP client mode
from now on I've set static ip adresses on both AP and i hope next update this issue doesn't happen again
It's always good to have a backup -- this makes it really easy to restore if you have to do a reset for any reason (be it an issue like this or human error as you are changing configurations).
It doesn't sound like anything would have been that unusual, but it's really hard to tell.
If you have the time and inclination, roll back to your previous version, configure (then backup), and then do a sysupgrade again. If it fails, we can start to understand if there is anything in your config that might have caused the problem to occur. If it succeeds, we'd have to conclude that thee might have been something going on in the previous config that was not replicated in the later test, or that it was some spurious issue that would likely be very hard to track down.
I have a LAN switch that is running OpenWRT. I had turned the firewall OFF -- because that LAN switch does not NEED a firewall running on it. It is a network-infrastructure device residing behind a separate router/firewall/DHCP server which is authoritative for the LAN.
Upgrading from 23.05.2 using attended sysupgrade.
Now I am completely locked out of my device, can't ping it, can't SSH to it -- but it continues to operate & move layer-2 packets, i.e. I can ping other devices on my LAN. The upgrade obviously worked because the device remains functional as a LAN layer-2 ethernet switch. I just can't get into its LuCi interface (or SSH) any longer.
This is super-annoying.
I don't want to be told that "this is expected behavior."
--->>>>> If I tell the firewall to be OFF, by explicitly turning it off, it should STAY OFF through an upgrade, not force me to fall back to recovery mode to get back into my device.
There referenced (recent) change aside (which might just as well bite you), that behaviour is expected behaviour, if you disable your services incorrectly. Use the service's own configuration to neuter itself, don't rely on the absense of a symlink, which will just get recreated on the next upgrade - the failure is not the system (that works as documented and does exactly what it claimed to), it's yours.