Periodically my 3 APs change IPs.
I made sure to setup static configurations outside the DHCP range (.7, .8, .9) and somehow the IPs change.
Most recently they get set to a static IP on the DHCP range.
Anyone else experience this?
If you have Fallback upon failure enabled, which it is by default, then it would revert to DHCP if it detects a loss of upstream connectivity. That seems like the most likely culprit for why it has changed. They should revert to the static when rebooted, at least.
So if you wish to debug, then it would be worthwhile to look at the on device log file shortly after the next time they rotate to see what reason is printed to syslog, as typically it’s there (/var/log/messages*). Or, if you’d rather just likely avoid it altogether, disable Fallback upon failure—this will only fix the IP changing though, it won’t fix an issue with the upstream path if there is one.
Are you intentionally dropping ICMP along the path from the AP? If so you likely would be best to disable the above feature anyway to mitigate false positives. If not, then it’s something else (and this is where logs would come in handy).
Mine do sometimes too. I just switch them back.
Thanks Mike.
No intentional ICMP dropping. From what I can see it looks like this may have been caused by the switches being updated (Route10 > Switch > AP).
Will review the logs close to the event when this happens again.
Mesh is enabled on the AP, would that mean that the Mesh would have had to lose upstream connectivity as well? Wondering if all switches are restarting at once for updates and the mesh is failing along with all upstream connectivity.
Do we know if that’s happening and is there a way to stagger updates or enable an update schedule?
Thanks for the insights!
Hi,
today I discovered the same and can not change the AP back to it’s static IP address.
It has been on the static IP address for month and now with no reason it changed to the DHCP range and I can not change it back
I am not even a specialist that know how to solve the issue but I know there has not been any changes in devices connected to the AP so it should really not happen.
Looking forward to some help.
As @Alta-MikeD pointed out above, the Fallback upon failure option is most likely the culprit.
As Joe and Mike noted.
You can toggle the “Fallback upon failure” option to prevent this from happening again. It sounds like it was caused by losing connectivity, most likely when patches were applied.
You can then reboot the device. Go to settings, scroll to where you see “Save” hold the shift key and “Reboot” will show up as an option. That should return the device to the static IP.
Let us know how you make out.
@Alta-MikeD @Joe
OK I have tried to unselect the fallback solution and reset the AP device and I also tried to turn off POE ad restart the device in this way.
I still get the same
This is the overview
And the detail device I try to configure
And what I get when I reset the device.
So assistance is still needed for this subject.
I understand the fallbck solution and I have turned that off for the device. But it really does not mak any difference at all if on or off it does exactly the same.
If you would like to tike to take a look I could invite you to my site.
Astina,
What is your DHCP range?
Under devices does something else have the .2 address?
Some people will have a the DHCP range start further up the range (.10 or .30, to 254) then using that earlier range for specific devices like APs and switches.
Also I see you have .02 vs .2. I don’t know if it matters, maybe worth changing that to .2.
I’m having the same issue here, fallback is off yet it does it anyway.
I’m honestly wondering if you’re hitting a caching issue, which is compounding this for you. Either by rendering the wrong IPs at times, and/or causing it not to provision as expected, or both.
I’d be happy to take a look if you’d like, then I can follow up with a summary of what’s discovered. I’ll send you my email via DM.
@ donsandro
My DHCP range is from 11 to 254 so I have reserved a few addresses for the Alta Equipment.
I have tried all possible numbers .2, .02 and even .002 but nothing help.
I also tried with .4, .04 but also this does not help.
@Alta-Mike,
I sent the invitation to you and looking forward to hear what is the reason for this issue.
Thanks! I’ve gone ahead and fixed the APs on your site. I waited 15 minutes and they were sticking to the proper IP. I also left your site at that point.
The Fallback Upon Failure feature was enabled, so it is the likely trigger. The events of when it rotated were no longer in the logs though—the device logs had rotated beyond that point, so I can’t look up that specific incident. It shouldn’t re-occur though please do reach out if you notice it happening again, or anything else.
@Alta-MikeD OK thank you for your help.
The fallback upon failure was on because after several trial to change the IP address even with the fallback upon failure off I was toggle the function to on again.
But for now it looks OK.
1 Like
Are you able to share the fix so others can do the same in the event they, too, have this issue?
Sure, here is the workaround: rm /cfg/dhcp.sh && reboot
This can be done from web terminal—go to Control, go to Network, hold shift, and click on the name of the device stuck on its fallback IP. I’m using && to make sure the first command successfully executes.
Normally a reboot would fix it, and it shouldn’t get stuck like that, so that part is a bug. We’ll have that fixed in the next release.
3 Likes
Nice improvement to help avoid this error in the future!
2.2i
Released on 04/08/2025
- Honor static IP address setting even if system switches to DHCP (via manual config, or fallback).
- Use HTTP for time synchronization, in case NTP is unavailable.
- Improve system stability.
[/quote]
Thanks team!
2 Likes