Lease Expiry Causing DHCP Critical Error

While attempting to troubleshoot my kids reports of wifi cutting out fairly often (visible during zoom or facetime type activities).
I noted something that I had not noticed before or recall seeing before and no idea when it started… but
I am getting a red line on my logs every 19 minutes - the lease time for my 1gig bell fibre service.
(equipment -Router RB450Gx4, wifi capac)

Initially I thought it was due to a script I had been using in case the actualy gateway IP and wanip changed (very infrequent but annoying as I had to manually reset the router (put the new gateway manually into my IP route rule). This has been working for at least 6 months maybe longer without issue until recently or at least until I noticed the red lines in the log. They were not there before.

I guess I am asking is this normal??? (note the script was removed to ensure it was not involved)

https://imgur.com/RLlUYGT

A DHCP Client at the 50% of the lease Time will try to Renew the Address it already has, this is the Renewal Timer…
When the Renewal Timer is Reached then the DHCP Client is at the Renewing state until the address is renewed or untli the 87.5% of the Renewal Time is Reached and then the Client goes to the Rebinding State, this is the Rebinding Timer…Notice though, the Client still has the same IP…
So, Timer 1 is reached but the address did not Renew, then Timer 2 came in play but the DHCP Server again did not respond(or Denied) or any other Server (during T2 the Client will try to reach even another DHCP Server, if there is any)… If every attemp until now is unsuccessful then the Clients Lease will Expire…
To me your Server denies the Renewal and the Rebinding States(does not allow to extend the Lease) for some reason untils the obvious happens, Lease Expires and the Client goes to the Initial State to ask for a new Lease…

What i would do is enable Debug with Topics DHCP and Debug, you might see some DHCPNAK messages and get more info…

So are you saying the problem is at the ISP end or on the router?
I am back to normal setting before I used the script and the same issue is occurring.
This did not occur before which leads me to think that the ISP changed something??

Okay two logging rule added
(topic → prefix)
DHCP -->debug
Debug → debug

Okay I have four pages of ‘stuff’.
What I did notice is that at 3 minutes to lease time (at the advanced page of the IP DHCP Client) on the STATUS page, that it was “RENEWING”
At two minutes from lease time a. dropped the DHCP server entry - became blank. b. status changed to “REBINDING”

So all is good ref comparing the current route config compared to last year…
The four pages may show something but not sure… what specifically are you looking for, would send you the pages directly if you provide me an email address… (i provide mine already)

Okay the four pages show when it fails, I will now attempt to capture the 3min renewing window, and the 2 min rebinding window.
Perhaps this is what is new in that the provider is not reacting to this as it did before… on the ISP end that is…

Okay I see at the 50% of lease point it tries renewing and states renewing on the status page…
I dont see anything else in the debugging that is going to help???

Initial request is like
debug: dhcp-client on vlanbell sending request with id XXXXXXXX7 to 255.255.255.255
And there are 7 and so steps after that keep repeating with no joy.
Hmmmm, stumped again.

Okay two logging rule added
(topic → prefix)
DHCP -->debug
Debug → debug

No, it is 1 Rule with 2 topics selected, debug && DHCP

So are you saying the problem is at the ISP end or on the router?

Since the DHCP Client goes through T1 and T2 Timers, Rewnew and Rebind, with no success it is obvious to me that your ISPs equipment for some reason Does not Extend The Lease
Also, at the Rebinding state, in case the Server for Some reason does not want to extend the Lease, the client will be ready to accept even a new Address…
So, Lease Expired means that the Server neither extended nor assigned an new IP during the T1 and T2 stages…

So why magically does it get a new IP, which is really the old IP in the end… (after lease expirY)

Bell support is useless, they cannot view their modem…
I suppose I should try a power up and down…

When the Lease Expires the Client just requests an IP address from the server… There is No Renewing, No Rebinding, no extention of the Lease, nothing…
So to me your Server Fails to every step of the extention of the Lease… The client in the above process just asks to extend it’s lease, nothing more nothing less… And as i said earlier, in the Rebind process it does not even care if the Server will assign a new Adress or the same, but even in that case your DHCP Server does nothing.

But what i would do, since you said the Lease Time is 19 Minutes? I would try to Increase it to lets say 1 Hour and see if the result is the Same (From the ISPs Router)…
If the Log debug provides info upload not all of it, just the debug messages when the renew/rebind process takes place…

I have no access to the ISP modem, and neither does their useless tech support.
Rebooted modem and router, no change in behaviour.

I have no access to the ISP modem, and neither does their useless tech support.

Not you, not them, so who has access ? :laughing:

Probably @sindy :laughing:

I wish he did, thanks mkx, I knew I could count on you for humour and not a solution LOL.

Probably have to get a tech out who knows crap about handshaking but has the steps down to attach a modem successfully to get an IP, which I get every time.
I need an engineer LOL

@anav you never provided details of the debug log…
Also if there is no access to the modem from anyone, you don’t need an engineer, you need a better modem/Router…

That is correct too much personal info in the logs, I offered to email them to you if you want to look at them.

This topic is getting to my favorite phase where I step in and ask “why the heck would you waste time, when you can simply sniff the DHCP traffic on the port?”
You will clearly see if your router is asking for DHCP renew and when. You will see if there is some NAK answer or if the request is ignored…
debug log? cute but not enough.

Hi vern, so you want me to wire shark the handshaking?
At which part the 50% timer1 request at about 9 min, or the 85% timer2 request at about 3 minutes, or the failure point at time zero??

Or are you talking something I can do on the router directly without special pain in the ass processes…

Ideally you’d start wireshark before initial address acquisition and then keep running it until after next address acquisition … if run with appropriate filters it should show all DHCP-related handshakes including unsuccessfull tries. And if trace shows some mis-behaviour of ISP’s core nodes, that should be enough evidence for ISP first-line support to ring the second line.

Well I opted for packet sniffer on MT router first. that was fun.
I selected the bell ethernet and vlanbell connections and ran it through the timer 2 sequence.
Dont see anything useful in the over th 119K items in packet sniffer, 159 items in packet sniffer connections, 115 items under packet sniffing hosts, and 218 items in packet sniffing protocols…

Are there specific Sniffer settings that I am not using that need to be defined. (for ex. I noticed a hockey sock full of selections under ports???)
By the way while doing this sniff the router kicked me the admin off the router several times during the sniffing. Not sure why, but the router itself remained servicable.

Are there specific port selections I should make to help filter?