Windows IPv6 slow-or-broken: resolved

This is part of a series on moving from desktop Linux back to Windows.

The first post is here. The previous post is here.

Chocolatey slowness?

When I originally posted about package management with Chocolatey, I mentioned two problems I had on a brand new laptop: 1) inability to download large packages; 2) general slowness when downloading.

Turns out, these are not Chocolatey’s problems at all.

Wait… Powershell too?

I noticed when working in Powershell that curl, which just wraps Invoke-WebRequest, was taking a really long time. Simple commands were returning results like this:

PS C:\WINDOWS\system32> Measure-Command { curl https://microsoft.com }

Days : 0
Hours : 0
Minutes : 0
Seconds : 43
Milliseconds : 316
Ticks : 433164486
TotalDays : 0.000501347784722222
TotalHours : 0.0120323468333333
TotalMinutes : 0.72194081
TotalSeconds : 43.3164486
TotalMilliseconds : 43316.4486

It would consistently take about 43 seconds.

Resolution: my IPv6 settings

I narrowed it down to a problem on my network — either the main PC, router, or modem — by trying out the curl command above while connected to my phone’s WiFi hotspot instead of our home router.

I’ll spare the sleuthery for later and cut to the chase:  I resolved the problem two separate ways:

1. by setting the IPv6 DNS settings in my wireless router (A D-Link DIR-880L); I did not stick with this
2. ultimately, by finding the broken DNS setting in my primary PC’s IPv6 config. This is the one I went with, but the first might be instructive or useful, so:

In my router’s config, I simply set the Primary and Secondary DNS server settings to Google’s DNS

Once I did that, the IPv6 connection in my router went from Not connected to Connected. My IPv6 readiness score went from 0/10 to 10/10, Powershell curl commands returned to reasonable amounts of time, and Chocolatey was both fast and able to download large packages (300+MB with no problem).

However, I couldn’t let go of something… why would I need to do this anyway? It occurred to me that a very, very long time ago — maybe as far back as 2010, when I first bought our current home PC, I had monkeyed with a DNS setting for some reason or another related to my job at the time.

So I went into the IPv6 settings (here’s how), and sure enough in the DNS tab I had overridden the default with some mumbo-jumbo I’ve long forgotten about. I set it back to the default, undid the changes I had made in the router, and voila, same expected behavior with Powershell, Chocolatey, and IPv6 readiness.

The End. Stop here if you don’t care about how I figured this out.

Sleuthery for those who like stories about troubleshooting

Some people like stories about troubleshooting — I know I love reading them — so here’s the story of troubleshooting this problem.

It is admittedly crazy on first take: that a buried-kinda-deep TCP/IP setting on one computer would not affect that computer, but would affect another computer on the network.

When I noticed the problem with Chocolatey originally, I saw that it was timing out in Invoke-WebRequest. That’s what eventually led me to even be curious about the behavior of curl / Invoke-WebRequest in Powershell itself, outside of Chocolatey. It just took me a few weeks (and a day off of work) to make time to investigate.

I noticed that initial requests were taking about 43 seconds, and a second request would take the same time as well. Then, subsequent requests would complete quickly. After a few seconds of waiting, they’d return to 43 seconds. A very helpful person on the StackOverflow post I made provided a quickie Powershell script to gather some data, which confirmed the above behavior.

I tried curl in Ubuntu via Windows Subsystem for Linux, and it looked fine.

I disabled, and then uninstalled, Antivirus. No effect.

I then connected to my phone’s WiFi hotspot instead of our home wireless, and voila, everything worked fine.

Now that’s interesting. Sounds like a network problem. Let’s try to isolate the various components in the home network and pin one down as the culprit.

I went to our primary PC and tried an Invoke-WebRequest in Powershell, and it was fine, too.

So here’s where I was: 1 computer on the network worked fine, and 1 didn’t. What’s the difference?

Turns out, sometime within the past year, on the home PC, I needed to disable IPv6 for something related to Comcast email and Outlook, and I remembered that.

So on the laptop, I tried disabling IPv6 just as I had on the home PC, and that solved the problem on the laptop.

Fantastic.

Except… why? Why did that work? It made no damn sense. I hated not understanding that.

At first, I tried investigating the problem via the wireless router. I went into the configs and everything was at the default, but I also noticed that it was telling me that IPv6 was Not Connected. Weird. I tried monkeying with a few settings whose purpose I didn’t know, and that made no difference. I then returned it to the default setting and on a whim looked up Google’s DNS IPv6 servers and plugged them in.

After restarting the router, the router showed me Connected for IPv6, and back on the laptop I re-enabled IPv6 and everything seemed to work fine.

To be clear: changing DNS here wasn’t a momentary stroke of brilliance. Often, my troubleshooting strategy boils down to “I wonder what happens if I twist this knob,” and that’s what this was. In my line of work, I’ve seen DNS cause all manner of network goofiness, so this was kind of like “hmmm…. here’s an empty text field related to DNS, and since DNS can act-a-fool, I wonder what happens if I put something legit in it.”

Fantastic-er. Can I be done now?

Why? I mean, sure, it worked, but why would I need to override DNS in the router?  That, also, just didn’t sit right. And I could not let it go.

The only thing I could think of at this point was that there was something wonky about the home PC’s IPv6 settings, and overriding the DNS settings in the router was working around that wonkiness.

I then went into the home PC’s IPv6 settings, and everything looked default.

Clicked “Advanced”, and then “DNS”, and that’s when I saw it: There was a radio button checked and then it had a text box with DNS entries that I have no recollection of setting, and one of the FQDN’s was the internal domain for one of my old jobs. WTF?

So then I returned that setting back to the default, undid the router DNS change, and success!

Though… there’s something else: I’ve had Mac, Linux, Android, iOS, and Windows devices using this network for years and none have hit this problem. Just Powershell. Curious, don’t you think?

Finally, if you’re looking for more of these troubleshooting stories, here’s one from a while back on The Curious Case of the Slow Jenkins Job.

Next post: AWS Lambda: Using SAM Local to test Lambda functions locally on Windows