DHCP Lease Time on BT Home Hub 2?

For the past few months I have been having apparently random wi-fi disconnects on various devices often at very inconvenient times when in the middle of streaming some live sport. So ahead of this upcoming heavy weekend of sport I logged into the Home Hub to give it a reboot in the hope that it would remain stable for the next few days.

But, browsing through the various settings (as you do) I came across the DHCP Lease Time and saw that it was set to 24 hours for each device. Curious!! So I changed them all to 21 days then went ahead with the reboot then checked that all devices had their lease time updated. I also put a three-weekly reminder in my phone diary to reboot the router on the Tuesday (after that weekend's sport).

I am assuming that BT forced an update those months ago that had the effect of changing the lease times? Or has it always been set to that but for some reason never been such an issue before? Or was it the reason for the dis-connects at all? Is it less secure to have such long lease times and I would be adviced to change back to shorter times?

24 hours is the recommended lease time for DHCP servers, especially for home use. If this is causing clients to lose their leases then you have some other problem. A device that is on when the lease expires will renew it automatically (with the same address). It shouldn't matter if a device loses its lease when it is switched off (assuming you don't want it to have a fixed IP address) as it will just acquire a new lease when it is next switched on. If you want it to retain its IP address you should switch on the "Always use this IP address" in its settings via the address table.

I can't say for sure but I would be very surprised if the default was ever different from the recommended 24 hours.

Setting a longer lease time isn't a security risk but does mean that there is a greater chance of running out of available addresses. Probably not a problem as you have 253 to play with, so if 21 days works for you that's no problem. I'm not sure what rebooting the router every 21 days would achieve; it won't affect the DHCP assignments as these should persist across a reboot.

DHCP doesn't wait until the lease expires before it renews - it sends out a request to renew when it hits 50% of the lease time. With a 24 hours lease this would give 12 hours for the device to renew the lease before the lease expires.

As you say changing the DHCP lease time is unlikely to make any difference and is likely a red herring to the actual problem the OP has.

In reply to a post by ian72:

DHCP doesn't wait until the lease expires before it renews - it sends out a request to renew when it hits 50% of the lease time.

That's true, I wonder if I have a problem.

Text
1 2	Lease Obtained. . . . . . . . . . : 25 February 2024 13:53:34 Lease Expires . . . . . . . . . . : 09 March 2024 07:59:23

That depends upon how the server is configured. 50% is the default before the RENEWING state is entered, but can be altered (I suspect that for the BT hub it is fixed at 50%). The RFC only says that this time must be earlier than the REBINDING time (which defaults to 87.5% of the lease time) which, in turn, must be earlier than the lease expiration time. But the lease remains valid until the lease expiration time if there is no response to DHCPREQUEST messages.

I'm not sure that this level of detail is really relevant to an outline understanding of the workings of DHCP.

Do you have the Wifi channels set to Auto? Sometimes if the channel selection is set to Auto, the Wifi can move channels and cause disconnects whilst doing so.
It may be worthwhile checking, and using a cabled connection if at all possible. Personally I only use Wifi when there is no other option.

In reply to a post by gomezz:

For the past few months I have been having apparently random wi-fi disconnects on various devices often at very inconvenient times when in the middle of streaming some live sport.

How do you know this is a "wi-fi disconnect"?

If you are on an FTTC line, and the line quality deteriorates and forces a retrain, this could cause a few seconds of interruption to service and/or a change in your dynamic IP address.

You may be able to look in your router logs to see if there is evidence of such activity (I don't know what level of logs the HH2 provides though).

Depending on how it is reporting I am not sure why that would be a problem. The original lease was obtained on 25 Feb, it has quite possibly renewed every day or more since and the next expiry is 9 March. I would check maybe tomorrow morning and see if the expiry has changed but the lease obtained is the same - I suspect that will be the case and just means it keeps extending the lease but the lease obtained date doesn't change.

In reply to a post by ian72:

I would check maybe tomorrow morning and see if the expiry has changed but the lease obtained is the same - I suspect that will be the case and just means it keeps extending the lease but the lease obtained date doesn't change.

I would have expected the "lease obtained" date to reflect the latest renewal, which is more interesting information than whatever date the lease was initially obtained.

I presume Windows logs lease renewals in the event log, somewhere.

I can't find a definitive answer but based on the evidence in your post I believe "Lease obtained" is when the IP address was first assigned to the device within the session. This will not change for a lease extension. I can think of times it is much more useful to know when the IP was assigned to the device rather than the last time it was extended.

As I said check a little before it is due to expire to see if the expiry has changed and see if the lease obtained changed - I suspect the former will but the latter won't.

I think both would be useful information, but the time of last lease renewal seems quite hard to find in Windows.

I've updated my NIC drivers, they were ancient, so my lease obtained date has reset.

That sort of thing is to be found on the DHCP server, but consumer routers may not provide access it. I’m not sure that I see the reason for a client wanting to know more than the expiration date and time. Does it really matter when the lease was renewed? (It could matter when managing the server, but I can’t see that it matters to a client.)

In reply to a post by TinyMongomery:

Does it really matter when the lease was renewed? (It could matter when managing the server, but I can’t see that it matters to a client.)

It matters no less than when the lease was initially obtained, which is available in ipconfig.

It could be useful when someone without access to the server is trying to determine whether a particular device had a particular ip address on a particular date and time. The lease obtained date is important here whereas the lease renewed is irrelevant.

Thanks for all the information and advice.

Still getting the odd issue mostly with my Chromecast dongle and tablet. I have now reset the lease times back to 24 hours but made another change to say to always used the same LAN/DHCP address for each of my devices rather than let it dynamically allocate one. It may be no coincide that the devices that have a problem are the ones which are only connected when in use.

Lets see how that goes.

My final solution which people will probably say should have been the first thing to do is replace the old HH2 with the newer HH6 BT sent me along with a new Youview box when the old Youview box was having problems a couple of years back. This weekend looks good for doing that as much less sport on TV I want to keep across (cricket / F1 / MotoGP / Six Nations rugby the weekend just gone).

I'm not expecting this to make any difference because by design you get the same IP address back anyway if the client device is currently on the network when it chooses to renew (versus actually expiring while powered off for example), and a DHCP renewal doesn't drop/reconnect a Wi-Fi or wired connection to renew anyway.

In other environments I would be looking for something else advertising the an SSID known to the client but having no uplink to your network, or coming from a second router, such that your client sometimes roams to another connection without Internet access or with a different LAN subnet.

Also to check that any Wi-Fi client based permanently in the home has no saved networks other than the one it should be using in the home or more generally that the home SSID is the most preferred (in OSes that support strict ordering of saved Wi-Fi profiles and which are set to auto vs manually connect, such as Windows).

Thanks for your input. Fixing IP address allocation does not seem to have made any difference. In particular over the past few days my tablet has been struggling to maintain a stream of the IPL cricket commentary (although curiously if I stream from my phone instead then not a problem) and also I seem to need to power-cycle my Chromecast dongle every day before use to force it to reconnect.

Given the upcoming weekend is free of sport I would want to stream live then now seems like a good time to swap to the newer HH that I was sent as part of my last BT package renewal / upgrade. Actually, will wait until tomorrow after I have iPlayer'd the Wales v Poland Euros play off final this evening.

I am beginning to suspect that the problem is actually a mix of poorer wifi signal and a newish bug in the BBC Sounds app. Wondering if one of my neighbours have changed or added to their kit and getting a clash of wifi channel. Closest neighbour is next to other end of the house and next nearest is a garden away but may be they have added a wifi extender to their garden shed.

Did do a channel change a few years back when I realised my old microwave oven was causing problems so did a best channel find while the oven was running and stuck with that. Won't be the issue with the overnight issues I am having though then the new oven is switched off.

In the meantime will do another overnight test streaming from VRadio rather than BBC Sounds.

After the first overnight of streaming with a new fixed preferred wifi channel things are looking promising ...

Just a thought that if I had swapped to the new HH (still to do) then the process of setting that up would have included that "little" change and could have misled me into thinking the problem was the old HH.

Mmm! Curiouser and curiouser! Even though the wi-fi connection is constant and strong my old Android 7 tablet is hanging every few minutes while streaming and only a wi-fi disconnect / connect gets it going again. But! Only overnight. During the daytime it is fine. Wondering if the Do Not Disturb feature is impacting this even though it is turned off?

Seems DND is not guilty. I set the schedule time for it to come on for ten minutes early in the evening in case the turn off setting was not doing what it should.

Last night I activated the Stay Alive app to keep the screen active and that appears to stop the stream hanging. Mind I also had to keep the tablet on charge and also activated the Blackr app to make the still active screen totally black to avoid it being a distraction. That appears to work.

Which is leading me to the conclusion that the fault lies with the BBC Sounds app and reminds me of a similar problem the BBC Sports app had a few years back (which is why I had the Stay Alive and Blackr apps already to hand). But why it only happens overnight is still a puzzle. I can accept that maybe the app is now broken on Android 7 while still working as it should on newer versions.

Additional evidence comes in the form of the Pocket Casts app on the tablet struggling to stream or download overnight which suggests that both apps are now expecting the OS to do something differently to the way it used to. Meanwhile my back up podcatcher AntennaPod continues to stream or download quite happily,

I am going to draw a line under this situation as over the past few days had a problem with my landline with no dialling tone and reduced broadband speed (about half what it should be). Turned out to be the ancient (50 year old) junction box outside the house which had allowed water in and corroded the connections. Now made good with a new box to provide adequate weather protection. Only realised I had a problem with this when the security alarm kept going off as it thought the line was being tampered with (as detected by the voltage momentarily dropping below a trigger value). Had to make a middle of the night call to the security company who told my how to turn off the tamper detection sensor until I got the line fault fixed.

So now we will see if I still have problem with streaming on my tablet overnight ...

And yes we do. It is the only happening overnight and not during the day which has got me scratching my head. Latest thought I had was that having DND active on my phone overnight was somehow affecting behaviour on my tablet as both are signed into BBC Sounds and Pocket Casts with the same login details. But then why does a forced wifi disconnect/connect make things work again for a little while?

Edit: I think I may try pulling an all-nighter on the settee downstairs and see if the location is a factor.

Edited by gomezz (Sun 07-Apr-24 09:56:46)

Ah, hah! I have found a problem with the tablet in that it was no long seeing the SD Card. Re-seated it and could now see it again and the streaming experience overnights went a lot better. But not perfect with still the occasional hang and still leaves the mystery of why it is only overnight and not during the day.

Which also poses the questions of why the two apps having problems BBC Sounds and Pocket Casts were able to see already downloaded files on the SD Card but struggled to download and stream / buffer to the card. Either they can see the card or they can't.

I am wondering if I should uninstall those two apps and re-install them without the SD Card present to force them to exclusive;y use the (limited) internal memory.

In reply to a post by gomezz:

Which also poses the questions of why the two apps having problems BBC Sounds and Pocket Casts were able to see already downloaded files on the SD Card but struggled to download and stream / buffer to the card. Either they can see the card or they can't.

Write-protect slide (if the card has one) slightly out of position so detection is marginal? Wild guess, but easy to check.

No write protect switch on the card.

This time I think I have found the root problem. What I didn't mention earlier was that I was streaming playback through my old alarm clock / Bluetooth speaker. Some time after I first started having problems the Bluetooth speaker functionality started playing up and is now unusable so I have been using another Bluetooth speaker for streaming ...

... but! I kept the old device still plugged in as I find the large digit clock display easy to read without my glasses. Then I had the thought that maybe the electronics inside that were failing had also started to emit RF noise that intermittently interfered with the tablet's wifi connection and had been doing so in the run up to the Bluetooth speaker failing. So last night I unplugged the old radio alarm completely and Huzzah! The streaming experience returned to being rock solid.

But now without a large digit clock display so have now repurposed my old redundant Hudl tablet to use the Night Clock app and that actually has even larger digits.

Is this the end of the story? Ideally I would like to declutter and replace the DAB radio, Bluetooth speaker and large digit clock display with a single device but my searches over the years have proven fruitless with the large digit clock display being the hardest to find as what most people think of as large is still way too small for my usage.

The HUDL tablet is too bright to use as a night time clock display so time to think again ...

Found an inexpensive LED alarm clock which is a lot better (and less power hungry) which also shows me the ambient room temperature and sits neatly just in front of the Bluetooth speaker But made a small mistake by getting the red on black display rather than the orange on display version (miissed that option when ordering) so still a bit brighter than I would ideally like. If I can find an appropriate coloured bit of clear plastic such as from a slip folder will try sticking that over the display.