Cant access dumb AP after sysupgrade

Hello guys,

My network is current in this layout.

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 If so the AP is reset to its default values and you need to reconfigure it.

Just use a backup of settings.

1 Like

i tried this, removed the cable from the main router and i could not access the router trough

I just want to make sure this is a typo... there is no such version.

Did you mean 23.05.2 > 23.05.3

What was the file you used for the upgrade? (please tell us the exact file name)

1 Like

sry for the typo.

this is the name of the file: openwrt-23.05.3-3ffbc1b69fc4-ramips-mt7621-tplink_archer-c6-v3-squashfs-sysupgrade.bin

i just add irqbalance to the default openwrt image and generated it trought firmware selector.

Does the computer still receive an IP by DHCP ? i.e is connected directly to the AP ?

yes, the AP is receiving a normal DHCP ip, and computer too, wireless ir working normal as previously configured too

This is slightly strange as I'd expect the filename to be:

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?

yeah its the normal lease dchp that is commonly assigned to the AP.

i cannot ping the AP, says connection refused. this is weird

i just update the nanopi r4s and update went smooth, all settings preserved.

This issue only happens with my archers c6 v3 dumb APs. ive experienced this issue on the last updated too

If so than you should be able to ping the AP as it has started.

The fastest fix is probably simply to reset to defaults using failsafe mode.

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).

1 Like

I had the same issue - I can't SSH or LUCI after update to 23.05.2 solved it.

1 Like

yeah i just reseted it and configured all over again. @davidhealy posted the solution but i cannot test anymore, since already reseted both AP.

i hope devs notice this problem and fix it on next release

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?

1 Like

unfortunately i dont have a backup.

But on those APs i have only changed according to OpenWrt documentation on this link:

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.

1 Like