1

Problem Description

The problem I am observing is that I will lose connectivity with all non-local IPv4 hosts one hour after Windows 11 boots up. This would normally manifest as getting disconnected from my game of Rocket League and cursing at my PC. The problem does not seem to resolve itself in a timely fashion (I think I've waited ~1 hour or less while googling for solutions).

Initial Troubleshooting

I have done some troubleshooting and determined the following:

  1. After the issue occurs, if I run ipconfig /all, there will be no IPv4 address listed for my Ethernet interface. It does have an IPv6 address though. Note: I am not using any wireless interfaces.
  2. If I run ipconfig /renew then the problem is resolved.
  3. My router (Arris Surfboard) is configured to give out DHCP leases that expire 1 hour after grant.

My initial hypothesis was that the Windows DHCP client is somehow failing to renew the lease automatically, even though it is able to do so after manual intervention (ipconfig /renew).

I think it is also relevant that my PC dual boots Linux and Windows. I believe I experience this issue most commonly after switching from Linux to Windows. Because Linux expects the hardware clock in UTC and Windows expects localtime, Windows will always have the incorrect time on boot. Even though NTP is configured, I always need to manually sync the system time after boot. I believe this sync will also reset the hardware clock. I wonder if this is related to my issue, since the DHCP client must rely on a timer to know when to request a lease renewal.

Experiment

I also performed an experiment where I changed the router DHCP configuration to expire leases in 30 seconds. Then I performed the following:

  1. Reboot into Linux.
  2. Reboot into Windows. Note that the system time is incorrect.
  3. Watch the ipconfig /all output for a few minutes and observe that it functions as expected; the IPv4 address is maintained and the lease expiration updates every 15 seconds.
  4. Sync the system time with NTP.
  5. Repeat step 3. This time the IPv4 address eventually disappears and never returns without manual intervention.
  6. Run ipconfig /renew and observe the issue is fixed, seemingly for good.

I have not yet done any kind of UDP packet capture to inspect the DHCP traffic, but I will be doing this shortly.

Update

I performed the same experiment as above while doing a packet capture with Wireshark. As you can see from the DHCP traffic, when I manually synchronized the system time with NTP (via Windows Settings) around 30 seconds into the capture, the client goes silent:

DHCP Capture

Only after I ran ipconfig /renew did the client start back up with the DHCP Discover packet.

Update 2

This is the NTP Sync button I am using:

Sync Now

Update 3

After performing the experiment with Wireshark running, I am quite certain that this issue results from a bug in the Windows DHCP client. I suspect that when the NTP sync occurs and the RTC is set back in time, the client gets confused and thinks that it has more time on its expired leases. This would explain why the client suddenly goes silent after the NTP sync.

I've created a bug report in the Windows "Feedback Hub" app.

As for workarounds, some users have mentioned switching away from dual booting to virtualization. I may experiment with this, but there are simpler workarounds.

I could also configure Linux to interpret the RTC as local time, or I could configure the Windows registry to interpret RTC as UTC.

I think the simplest workaround is to raise the validity duration of my DHCP leases (in the router config) to 24 hours, so that even after an 8 hour desync, the client will still try to renew its lease before it expires.

Duncan
  • 11
  • 3
  • Windows 11 losing addresses and time does not happen on any of my Windows 11 Pro machines. Is your Linux system fully compatible with TPMV2, UEFI, and Secure Boot? – John May 31 '23 at 22:52
  • @John Do you also dual boot Linux? RE: TPMV2, UEFI, and Secure Boot, I honestly don't know. I am using Manjaro Linux. – Duncan May 31 '23 at 23:21
  • @Duncan - It shouldn’t matter as the likelihood of the time zone setting in Windows being the cause of your lost of connection is next to zero (or it shouldn’t). Which by the way you could easily configure windows to the same time setting as Linux. – Ramhound May 31 '23 at 23:27
  • I use virtualization to install all my machines (leaving Windows 11 Host to be the only host system). I used Dual Boot a long time ago and gave it up as slow, inefficient and wasteful of time. Much much better to use virtualization – John May 31 '23 at 23:27
  • @Ramhound I am not modifying the time zone setting. I've attached a picture of the NTP sync button which is causing the issue. – Duncan May 31 '23 at 23:57
  • @John Virtualization may or may not be an acceptable solution, but it opens up a large can of worms, so I think it's out of scope for this discussion. – Duncan Jun 01 '23 at 00:15
  • @Duncan - Your essentially changing the time zone. Have you tried to enable [RealTimeIsUniverse](https://superuser.com/questions/482860/does-windows-8-support-utc-as-bios-time)? Windows also supports the UTC timezone – Ramhound Jun 01 '23 at 00:21
  • *Because Linux expects the hardware clock in UTC* ... you can configure linux to expect RTC to be in local time instead ... or [the recommended solution for dual boot linux windows](https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows) – Jaromanda X Jun 01 '23 at 00:49
  • Virtualization is NOT a can of worms. It works great for me and has done for a couple of decades. It avoids all the issues you are having. – John Jun 01 '23 at 00:50
  • *Windows will always have the incorrect time on boot. Even though NTP is configured* ... well, windows can't automatically sync time until it can access the NTP server, for that it needs an IP address ... see the issue? – Jaromanda X Jun 01 '23 at 00:51
  • @JaromandaX No. Windows has an IP on boot and it has no problem synchronizing with the time server. The IP only disappears *after* the time sync. – Duncan Jun 01 '23 at 02:23
  • Q: where did it get that IP? A: from DHCP ... and only AFTER that the time changed - though, I didn't realise windows was stupid enough to screw up DHCP lease time because the time has changed – Jaromanda X Jun 01 '23 at 02:26
  • @JaromandaX Yea. The DHCP client has started and discovered its IP address before I even have a chance to change the system time. I suspect it is the act of rewinding the hardware clock which confuses the DHCP client into thinking the lease has not expired yet. – Duncan Jun 01 '23 at 02:29
  • exactly, but you can't "rewind the time" (using NTP) until you have an IP address to do so - did you read the [recommended solution](https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows) I posted? – Jaromanda X Jun 01 '23 at 02:31
  • @JaromandaX Yea I read it. See "Update 3" in my original post. RE: *you can't "rewind the time" (using NTP) until you have an IP address to do so* Yes I am aware, but Windows has no trouble acquiring an IP address on boot. In fact, there is no networking issue at all until I perform the NTP sync. – Duncan Jun 01 '23 at 02:49
  • This isnt a bug, this is just things working as intended. Your setup is creating this situation, so you are responsible for fixing it. @Jaromanda X already provided a valid workaround. – Silbee Jun 01 '23 at 09:20
  • @Silbee You can't blame the user for this. The DHCP client has a bug if it can't handle time syncs, which are a completely normal occurrence. – Duncan Jun 01 '23 at 17:14
  • @Duncan it's not a bug. The lease time is set to a certain hour and it is (correctly) oblivious to time changes. Time changes are absolutely not a normal occurence, especially for a computer connected to a network. Where would that computer ever change time zones ? I agree it might be a nuisance in your case, its still upto you to work around it. Dont expect any dhcp client ever to account for arbitrary time changes. – Silbee Jun 02 '23 at 09:13
  • @Silbee Red Hat Enterprise Linux can handle this case: https://bugzilla.redhat.com/show_bug.cgi?id=1729211 – Duncan Jun 04 '23 at 23:50

0 Answers0