# TortoiseHG and wildcard certificates

Having resolved recent SSL certificate issues with Mercurial/TortoiseHG, I now encountered a similar issue with the wildcard certificate for *.google.com where getting a clone would result in a "SSL: Server certificate verify failed" error.

One way around this issue is to add the fingerprint for this certificate to your configuration. Currently for *.google.com this is 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8 and one way to get this from a Unix command line is with openssl s_client -connect code.google.com:443 < /dev/null 2> /dev/null | openssl x509 -in cert-code -fingerprint -noout -in /dev/stdin | tr "[:upper:]" "[:lower:]". This corresponds with Chrome’s certificate view’s thumbprint field, you just need to add colons.

Right click in Explorer, select TortoiseHG » Global Settings and then click Edit File and add the following:

[hostfingerprints] code.google.com = 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8

This should make Mercurial/TortoiseHG work, at least until the certificate expires and you need to update it with the latest fingerprint.

# TortoiseHG and non-standard SSL certificates

For my own development I use Mercurial and TortoiseHG for my version control system. I also use, at the moment, a CAcert certificate to use HTTPS with my repositories. I am not sure what changed when, but apparently the certificates now get verified. So this causes obvious problems trying to push or pull due to "SSL: Server certificate verify failed" errors.

To make this work on a Windows 7 machine with TortoiseHG in stalled, first download the CAcert root PEM certificate and place it some permanent directory. Next open the TortoiseHG global settings (right click somewhere in Explorer and select TortoiseHG » Global Settings). In the window that opens click the Edit File button. If it does not exist yet create a section similar to this:

[web] cacerts = C:\path\to\cacert-root.pem

Press Save and OK and any push and pull action with HTTPS URLs should work as they ought to.

# Pinning Eclipse to the Windows taskbar

I pin programs that I use frequently to the taskbar of Windows. So I was a bit surprised to see that the newer version of Eclipse, Juno, doesn’t seem to support this by default. After some searching I find out that you can force this by adjusting the eclipse.ini by starting the file with something akin to:

-vm C:\Program Files\Java\jdk1.7.0_05\bin

Then after starting Eclipse with this in place, you can, once fully loaded and past the splash screen, pin Eclipse to the taskbar.

# TortoiseSVN (Subversion) and Windows 7 file corruption

During a checkout of a Subversion tree on my Windows 7 installation I got quite a fair share of errors from TortoiseSVN, all of which ended with The file or directory is corrupted and unreadable.

After digging around a bit, I came across this blog post on the exact same problem. And subsequently I found there is a hotfix available from Microsoft on their page about . This hotfix will be in the upcoming service pack 1.

You might also be able to work around it by disabling indexing on the particular folder or drive. It solved it for me at least.

# Upgrading dd-wrt for Windows 7, problems and a possible fix?

As noted in my earlier post I had issues with my network interface card (NIC) dropping my connection whimsically.

So finding some posts about possible firmware issues with Linksys routers and disconnects I proceeded to update my router’s firmware from dd-wrt v23 to v24 pre-sp2. This actually caused me some problems. I followed the information presented in the stickies on the dd-wrt forum, which means that prior to updating the firmware I did the 30/30/30 reset to get the factory defaults going again, then proceeded with uploading the new firmware (v24 pre-sp2 build 13064) and once that was done do the 30/30/30 reset again.

And that’s where 2-2,5 hours of frustrating would kick in. After the router had rebooted I couldn’t ping the default 192.168.1.1 address. I was getting a destination unreachable message. So alarm bells started to ring in my head, thinking I had bricked my router in some way. But the strange thing was that it looked like it rebooted correctly, no strange flashing LEDs, or not being responsive to cables being plugged in and taken out. Of course, with the router down I had no Internet connectivity to do some troubleshooting browsing. But thankfully I could use my Android mobile phone for that. I retried various reset routines but to no avail. Of course I started to despair a bit more, thinking I would have to buy a new router. I then noticed that the WLAN LED was lit up. Since my Android phone supports WiFi I figured I should see if it shows up. ‘Lo and behold, it had a network with the SSID ‘dd-wrt’ and sure enough, I could connect to it. Next was trying to router’s web interface and that worked too! Of course that enthusiasm was quickly dampened when I discovered that you cannot do a firmware upgrade over the wireless link. I also couldn’t find any way online on how to override this precautionary lockout, so it was back to square one.

And then I stumbled over a post which mentioned that Linksys routers with the original firmware sometimes have their wired LAN ports revert to 10 Mbit/half-duplex settings. After picking up my jaw from the floor I wondered if it could be so easy. Sure enough, after changing the settings for my NIC in the configuration window, I could ping 192.168.1.1 and load up the administration interface in my browser.

Then I tried my World of Warcraft (WoW) patch download again (which is essentially a BitTorrent client) and stream Bohemian Rhapsody by the Muppets at HD quality from YouTube only to have my NIC go silent on me again. So, after the few hours of futzing with the router and its upgrade I was no closer to a proper solution. Although I did conclude it was, in fact, the Windows 7 box acting up since my WiFi connection as well as the Unix box on another LAN port could still use the network as it should.

Then the morning after I was looking around several Google results again and came to a post on the Windows7Forums.com website where someone had troubles with a wireless connection from Windows 7. I use a wired connection, so aside from the symptoms it’s not quite similar. It then documents the ‘roll back driver’ solution, which I had previously tried. But it became interesting when I found Sage’s post at the bottom which reads:

“I think I’ve found the solution to this problem. It was revealed recently (A week or two ago) that there is a bug in the NVIDIA chipsets when using 64-bit addressing. This ends up affecting a whole host of things on machines, including this nefarious “Random internet disconnect” problem. I posted this solution over at a couple other W7 forums and others with NVIDIA chipsets and 64-bit machines have all found it to succeed in fixing this frustrating issue.

What it more or less comes down to is applying this hotfix: You encounter problems when you move data over USB from a Windows 7 or Windows Server 2008 R2-based computer that has an NVIDIA USB EHCI chipset and at least 4GB of RAM

Ignore the fact that it mentions this fix to be solely for USB hardware issues. It is a fix for the NVIDIA chipset on 64-bit Windows 7 and has been practically a miracle fix for people with the USB harddrive disconnect problem, the random internet drop problem, and the internet-disconnect-on-wake-from-sleep problems that have all been plaguing Windows 7 64-Bit users since the RC.”

Funnily enough my Windows 7 is 64-bits and I also have an NVIDIA nForce chipset. Looking at the hotfix page shows it really is only updated USB driver files. Figuring it cannot possibly be worse than my situation now I installed the hotfix are being emailed the location to download it from. A reboot later I was downloading my WoW patch with the downloader while streaming the Muppets again and haven’t seen it drop dead yet. So initial tests show it might very well be the solution, but I need to stress test it some more.

# Windows 7 and the case of the dropped network traffic

So the good news of Windows 7 is that they removed the TCP half-open limits.

The bad news is that quite a fair number of people have problems with their network interface card (NIC) dropping dead on them as soon as they push their system to sustained high throughput, think of leeching newsgroups, using torrents, but also downloading ISOs (BSD or Linux releases) or even watching YouTube clips and downloading a driver.

The suggested ‘fixes’ have been ranging from absurd to interesting.

Things I have done so far:

• rolled back the driver from NVIDIA to Microsoft’s stock driver, did NOT help
• disabled power management features, did NOT help
• disabled autotuninglevel (netsh int tcp set global autotuninglevel=disabled), still in testing

Things to try still:

• disable all Quality of Service (QoS) stuff