I have a RB600 running the latest ROS (although tested with 5.14, 5.23 as well as 6.0rc7) in which the following problem occurs.
I have two internet providers, both providing DHCP public addresses to separate physical ethernet interfaces. I can test the problem below with either provider individually or together, or even on different ports, it makes no difference.
The first provider (Comcast) assigns a 100 hour lease time, this one has the issues described herein.
The second provider (Verizon/Frontier) assigns a 30 minute lease time and acts completely normal (no adverse behaviors).
Any attempt to perform a renewal either from winbox or the command line/script using:
/dhcp-client renew ether2
does absolutely nothing. Releasing the lease results in obtaining the same IP with the same remaining time as before (i.e. less than 100 hours).
I need to figure out why renewals are not working, as a release/renew will break my applications, no matter how quickly it rebinds. I also want to make sure that in 2d23:30:00 (when my present lease expires) that this first provider (recently installed) will continue to function. I suppose I only have to wait another 23hours actually, since the client should attempt to renew at the half life of the lease.
I have not had time to test it on other Routerboard hardware or x86 hardware, nor do I believe that is applicable since the behavior is present regardless of which physical interfaces I plug the offending provider in to.
I’m not sure what you are asking or looking for specifically? The Comcast behavior is expected and normal. Most of the time your lease rarely, if ever changes. A DHCP server will try and give you a previous IP that you have had if at all possible. Just because you did a renew command on the DHCP client and didn’t get a different IP doesn’t mean it didn’t do anything, it just means it asked for a lease and got the same one.
This is not a problem with receiving the same IP as presently assigned (which is the RFC behavior specified if the address hasn’t been reallocated elsewhere). The problem is that Winbox or command line renew requests result in NO CHANGE to the lease or the creation of DHCP request/offer/ack/nak messages. I expect the IP to stay the same, but I also expect the expire-after time to refresh (not just keep counting down from the original acquisition) and I also expect to see the client status go through a renewing/rebinding step before returning to bound.
If I torch the Routerboard’s ether ports to watch the renewal I can see the UDP/67-68 renewal to the DHCP server on the Verizon/Frontier port, I see no similar activity when torching the Comcast ether port and trying to perform a renewal.
I am closing this request for support as follows, as I don’t expect the forum to be able to correct for Conmcast’s behavior.
Comcast is intentionally ignoring the published behavior in the RFC (no surprise there). RFC 2131 4.3.2 reads (in part):
DHCPREQUEST generated during RENEWING state:
.
.
.
A client MAY choose to renew or extend its lease prior to T1. The
server may choose not to extend the lease (as a policy decision by
the network administrator), but should return a DHCPACK message
regardless.
Here is what Comcast does do (at least in my area):
Prior to 50% of the original lease expiration time, all requests for renewal are ignored (no DHCPACK) and discover requests (i.e. after a reboot) are given the remaining expiration time from the original lease rather than a new, full expiration time. Only after the original 50% mark has been reached will renewal or discover requests be answered with a new, full expiration time. The lease time is not a deviation from the RFC, but the lack of response certainly is.
This is not the first time I have found Comcast to have implemented a non-standard DHCP configuration. Years ago, they had DHCP configured to force a different IP at every lease renewal to discourage people from running servers unless they had employed a dynamic DNS IP updater.
I was relying on the expiration time to accurately determine when the next renewal would occur so I could script my change IP updater scheduled start-times to coincide with renewals (I actually was forcing the renewal at 5 seconds before the client would have done it automatically, and then performed a while loop until it was bound). This minimized the amount of traffic, delays in updates, and CPU time of that updater script. Combine this new found behavior and multi-day lease with my other post on “Date Arithmetic”, and I may revert back to dumb scripts rather than trying to keep them fully self-aware, as it has been for the past years.
