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

3 thoughts on “Windows IPv6 slow-or-broken: resolved

  1. I’ve heard of all sorts of quirky behavior around IPv6 — on both Windows and Mac — and the general recommendation I’ve seen people make is “Hey, just disable IPv6!” so I’ve never dug into it beyond that. I think I have IPv6 disabled on at least some of my machines here based on that casual advice. Next time I see anything quirky around IPv6, I’ll remember this blog post! 🙂

  2. Great post!!!

    This totally solved my Chocolatey issue and I’ve shared it with Rob Reynolds of Chocolatey in the event he didn’t know.

    I’ve read your “Goin’ back to Windows” posts and I’m torn.

    I get that you like the Yoga and I understand that Microsoft/Windows is better with it’s recent embrace of Linux (finally, thanks Satya).
    However, WSL is work-in-progress.
    Powershell is great, but bash and the GNU Core Utilities are so ubiquitous, hence WSL.

    That said, for me (admitted late 16′ MacBook Pro, 10.13, daily driver), I’m thinking of migrating to a Linux OS for my daily driver Desktop on my MBP.

    I can’t stand the telemetry crap that Microsoft Windows 10 does.

    I am frustrated by Apple’s disinterest in macOS (see recent root no password issue amongst others) and their telemetry interests.

    I also feel that I’m not alone and people want to have more say over what software is running on their personal computers/devices, especially recently.

    I believe that true ownership or data relinquishment will become more of an interest in the general public in the next 5 years, even with hardware, including mobile devices.

    I’m not a hardcore RMS-type person with regard to openness, I understand the concept of best tool, but I am curious about some of your other pain points that provoked you to switch back to Windows from Linux.

    Thanks for your blog.

    Eric

    1. Hey Eric, your reasons for going to Linux make a lot of sense, IMHO. I’m kinda fingers-crossed that Microsoft provides more control over the telemetry. I’ve got my settings turned down as far as they can go, and I’ll be interested to see what this new telemetry viewer app they’re coming out with shows.

      As for pain points, it really did come down to hardware. The Ubuntu install on my old Samsung Chronos was wonky as hell. I could never get the trackpad quite right, which was infuriating. It drained battery waaaaay faster than Windows on the same machine. And finally when either a disk started going bad or something else resulted in that Ubuntu install basically not really working anymore, I decided it was time to invest in a new machine. Mac wasn’t even a question for me for reasons I mentioned in the original post. And I figured if I didn’t like the Windows experience on this Yoga, I could always just put Linux on it. So far, I haven’t felt the need to do so. WSL has been fantastic. Yeah, I’ve hit a few snags here and there, related to either Docker or npm, but I hit npm problems on Mac and Linux all the time, so this is no worse, and I think I have my Docker problems largely squared away at this point.

      Thanks a lot for reading and commenting!

Leave a Reply

Your email address will not be published. Required fields are marked *