Latest version DHCP bug, system drops after 1 hour

Hello All,

Another tech and I have tested this several times on 3 different servers.
There is something not working between DHCP & time zones.
I have not had this issue on hard coded IP based systems.

If you yum update everything on the last update, reboot the box it will boot and run, but in 1 hour EXACTLY the DHCP lease will be up and the server will be DOWN.

It looks like if your time zone is set to EST ( maybe anything except UTC) your lease will not renew and therefore you have no networking, hence server down.

In some cases you can type in DATE, and it will show you (in my case ) EST, but show UTC time.

To resolve this, set the server to UTC time reboot and the problem goes away.

I can duplicate this time and again, so this is a bug 100%, but I’m not sure if it’s a Centos 7 Bug or a FreePBX Bug.

Looking forward to a fix and wanted to share this with everyone.

I have never heard of this ever being a cause. First, DHCP doesn’t set timezones on the devices it can set the NTP server for the devices to use for their time. Second, DHCP doesn’t do any checks or comparisons of the devices or the router for time zones. So if I have a device set to EST and one set to PST, the only thing DHCP is going to tell those devices is use 0.pool.us.ntp.org for their time source. The DHCP will not care if one is EST or one is PST.

No, you wouldn’t since setting a static IP in the device removes the device from requesting/using DHCP and thus not needing a lease renewal. The only way this would impact a “static” device is if the IP is assigned to a devices MAC and will pass out a static lease when the device requests DHCP. Then you might run into this issue as the lease still expires like normal.

What do the logs in the DHCP server show? What happens when the PBX makes a renewal request after 1 hour? Does the server see the request? Does the server do anything with that request?

Follow up question: Why in the world is your PBX using DHCP to get its address? This a static route as I mentioned in my previous post?

Clearly you are behind NAT and really should have a static IP on the PBX so your NAT/Firewall rules don’t have to be changed down the road. Or, like in this case, run into issues with DHCP changing or causing issues.

There should be no reason for your PBX to be getting dynamic IPs on the LAN.

AWS, and this has never been an issue.
I agree with what you are saying, when on my own networks, this scenario wouldn’t happen.

OK, then most likely a static lease for the instance since on the systems I’ve had there the LAN IP doesn’t change. As well the issue of getting/handling DHCP is an OS level issue not a FreePBX/Asterisk issue. Neither one of those have anything to do with obtaining IPs via DHCP.

I’ll agree with what you’re saying, but this wasn’t easy to troubleshoot, so I figured if someone ran into this, it would be good to know.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.