The Upgrade - Part 2, Mainly getting the VPN to work

Well, once I got Windows 7 running, everything seemed fine. For a while. For a stand-alone machine, Windows 7 is OK. Personally I don't find it any better or worse than XP - different sometimes, but not noticeably better. The graphics are all different but honestly they don't make any real difference. It's kind of cute the way taskbar items give you a preview before you expand them, but again it's not exactly life changing.

I can't comment on whether the performance is better than XP, as some people claim, because the machine was so badly broken before that it isn't a fair comparison. Some things are however much worse. For some reason re-sorting a large directory can take ages - tens of seconds - if the content consists mainly of images. I suspect it is re-extracting the thumbnails from the files. It's a typical example of trying to be gee-whizz helpful and just making the user experience painful, which unfortunately is fairly characteristic of Windows.

It was when I tried to install the VPN so I could use the machine to work from home that things started to go downhill rapidly. Like many companies, we have a Cisco PIX (well, it's called something else now) which provides VPN services among other things, and the Cisco VPN client. Getting hold of the Windows 7 client and getting the VPN to come up was amazingly easy. So far things were looking good. I could SSH to my Linux system, and I found a so-so free X server and that worked too. For some reason I stopped there, and it was a few days before I tried the next step.

Which was... to open a Windows Explorer window on the Linux filesystem. We have (just like lots of people) a server that runs Samba. When I tried to connect, it just hung for a long time and eventually said it couldn't reach the server. What's more, this time, I couldn't get SSH to work either. Using Wireshark, I could see that packets were being sent into the VPN client, but they were never coming out on the wire side. And in fact, the client's statistics window showed an increasing "discarded packet" count. It's impossible to find out why the client discards packets. The log shows nothing, even when you turn the logging level up to maximum for everything.

At this point I gave up for a while on the regular VPN client, and tried using the SSH client. This was amazingly easy to install. But it didn't work. I eventually discovered that even though I had my work network set as "trusted" in the ZoneAlarm firewall, I still had to turn the global internet security level all the way down, effectively disabling the firewall altogether. The SSH VPN came up that way, but of course this is way too dangerous as a normal setting. So much for that solution.

Luckily, I was able to ask for help from a security expert at Cisco, who parenthetically remarked that it's just about impossible to get the VPN to work with the ZoneAlarm firewall running. Aha! I turned it off, turned on the Windows firewall, and now everything except remote mounting my Linux server worked fine. So, lesson #1: don't use the ZoneAlarm firewall if you want VPN to work.

More Wiresharking showed that this time, packets were getting through to the wire, and were getting replies. Yippee! Strangely, the Windows file client was trying to connect to port 80 (i.e. HTTP) and getting an immediate reject from the server. I have no idea why it tries to connect to port 80. Another interesting thing I saw was that after a couple of failed attempts at connecting, Windows just sulks. When you click on "connect" it immediately comes back and says "can't" without even sending any messages. I suppose it has cached the failed result, but it's a real problem when you are making configuration changes to try and get it to work.

Then I suddenly remembered something. Windows remote file access uses a protocol called SMB. SMBv1, used up to XP, is a truly awful protocol. It sends literally hundreds of messages, and waits for the round trips, for even the simplest operation. That's why accessing a remote file system over a wide-area connection is so slow and painful. Finally, after a decade or so, this problem was addressed in Vista, with SMBv2, which supposedly makes things better. However Samba still only speaks SMBv1. Now Vista, and Windows 7, are supposed to auto-negotiate, i.e. if the server can't do SMBv2, they fall back to SMBv1. Supposed to, but evidently they don't. If the client doesn't get the answer it's expecting when it tries SMBv2, it just sits and waits an irritatingly long time, then tells you it can't do it. So, the obvious thing to do is look for a way to tell the client always to use SMBv1. I looked everywhere in the "advanced" configuration, but nowhere is there a checkbox that says "don't even think about using SMBv2".

So I Googled, and I found an excellent page on an Israeli IT-help site that says exactly what to do. It just involves typing two unbelievably complex commands at the Windows shell. However this isn't the whole story, because Windows 7 has this great idea that even if you have Administrator privilege, you don't actually get that privilege unless you ask nicely. So after you have typed this humungous command, the response you get is "access denied". Luckily, Google had the answer for that, too.

So the whole procedure for disabling SMBv2, assuming that you have Administrator privilege, is:

1. Right click on the "Command Window" icon, then select "Run as Administrator".
2. Type:
   sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
   sc config mrxsmb20 start= auto
   
   

Don't miss out the spaces after the equal signs - they're important. Someone at MS evidently skipped parser school.

So, after a very frustrating couple of sessions, I can now fully access my work system from home. But (a common refrain I'm afraid), why is it so hard?

That wasn't all though. When I was physically rebuilding my system, I kept noticing that the CD/DVD drives stopped working. Each time, I'd remove all their cables, plug them back in again, and when I rebooted, they worked fine. The cables didn't seem loose or damaged, so it was a bit surprising, but I figured I must be disturbing things somehow. Later, I finally figured out why my DVD drive refused to write DVDs... it isn't a DVD writer, just a reader and a CD writer. Well, that was easy to fix, so it was off to Fry's for a fancy new SATA DVD drive. That was actually an amazingly simple and smooth installation. Absolutely nothing went wrong at all.

Then, while I was trying to solve my VPN problems... the CD drives wouldn't work. When I inserted disks, the lights would flash, and sometimes the drawers would pop open, but nothing showed up for the disks themselves. Now though, they use completely separate cables and adapters, right to the motherboard. So it can't be a cabling problem. Finally, I rebooted the machine... and they worked just fine. Turns out (thanks again to Google) that Windows 7 has a well-known bug that sometimes, CD drives don't work. How on earth did that get through the QA process?