Fallback forcing IP conflits

One of my AP6 Pros keep switching to DHCP even though I have fallback off and when doing so its creating an IP conflict. I’ve rebooted the AP and the route10 and it just keeps doing this over and over. I can go in set it back to 192.168.1.3 and it immediately reverts back to 192.168.1.240 and creates the conflict. It just started today from what I can tell.

Letting it go to DHCP and it moved to an IP without a conflict which at least stopped the alerts that the ap is unreachable. I don’t understand why all of a sudden its failing on 192.168.1.3, my dhcp pool starts at .100 and the only thing below that are statically assigned devices of which the 3 alta products occupy .1, .2, and .3 followed by the next closest device is .10.

If I change it back to static and set it to 192.168.1.3 it now fails back to the 192.168.1.241 it picked up after changing it to DHCP. Fallback is still off mind you.

Are you verifying this with a simple ping test or going by the FE? There have been some caching issues and one of the known ones is Alta device statics appearing to revert to the DHCP address, but they often don’t actually do that.

yeah setting to 192.168.1.3 and then pinging the new address it falls back to seems to confirm it is indeed falling back despite that option being turned off.

1 Like

So taking a step back.. The cases where that would invoke, when enabled, would be if pings failed to ping.alta.inc or the upstream gateway stops responding to ARP requests. So usually it means there is a real issue, and disabling it actually should expose that. It could still be a false positive, but I just wanted to give that small disclaimer in case.

I think I forgot to something. The connectivity checker does continue running when mesh is enabled, so to fully disable it, you would need to disable mesh. It doesn’t look like you’re using that feature. I wonder if that part of the connectivity checker failing is why this behaviour continues.

If you want to check logs first, then grep netd /var/log/messages* from web terminal on each AP should highlight the connectivity checker events, just note that the log time is in UTC (not your local time, unless you reside in the UTC zone).

I disabled mesh, changed back to 192.168.1.3 (the ui keeps reverting it after the window closes), hit save, it changed back to .3 briefly then went back to .241, ping confirms its on 241.

The other AP is just fine, no issue, same with devices on the leg of the network. I can still remote into the pc thats connected to the same switch as the AP.

I’m 99% sure fallback upon failure is all that’s needed, and given that one is behaving and the other isn’t, that also leans into that. I sent a DM with a few other things to check, as I’m curious how it’s provisioning. Please let me know at your convenience.