Netonix Forums

I found an old post from 2015 talking about this issue, however it appears we are still having this issue.

We use WS-6-mini switches at commercial client sites quite frequently. They are setup to get an IP address via DHCP from our NMS. The issue we are having is that if the switches don't get a response from a DHCP server they will revert to their last static IP address. This is a great feature, however when the switches are powering the radio that connects them to the network, the DHCP process times up before the radio powers up, and then it's always reverting to static.

Is there anything we can do about this issue? For now I have had to assign them statically, however we don't like that for client devices.

IKWYM and it is a pet peeve of mine when kit does that. IMHO, if there is a failure to get a DHCP lease, it should try again after time has passed and/or when there is a link state change.

I also have the reverse of that where a link state change causes some DHCP configured Ubiquiti kit to drop to the fallback IP which doesn't have a DG option.

This is something we'll have to think about. Do you all think having a field to configure how long the time before the failover to static take's place would be helpful?

Timeout value and number of retries... at least the timeout value for sure.

If it falls back to static, what address does it fall back to? As it is now, selecting DHCP mode grays out the static address values. Wouldn't it make sense to be able to enter what you want it to fall back to if DHCP fails?

sakita wrote:Timeout value and number of retries... at least the timeout value for sure.

If it falls back to static, what address does it fall back to? As it is now, selecting DHCP mode grays out the static address values. Wouldn't it make sense to be able to enter what you want it to fall back to if DHCP fails?

I agree with timeout and retries.

Right now it falls back to whatever is in that greyed out field.

Have you considered letting the DHCP client continue searching even after falling back, then shutting off the fallback address if it does eventually pick up a DHCP address?

I will look into seeing if that can be done.