Vista keeps a log of application and kernel crashes in Control Panel -> Problems Reports and Solutions -> View problem history:

Double clicking on the latest Windows “shut down unexpectedly” shows the blue screen details. These don’t give much useful information, for example which driver was responsible:

Clicking on “View a temporary copy of these files” opens an explorer window with the crash dump file, which you can copy to your own directory.

To analyse the crash dump you’ll need to install the Microsoft Windows Debugging Tools (17MB msi).  This adds a whole set of command line tools under “C:\Program Files\Debugging Tools for Windows (x86)”.  Use the dumpchk.exe tool to analyse the crash file:

And there’s the culprit: “Probably caused by: eacfilt.sys”.  This is the driver used by Nortel’s Contivity VPN client.  I’m using the “vista friendly” version, which worked fine before I applied Vista SP1, but I guess SP1 broke its driver.  The solution to all my problems? Uninstall it!

Hurrah! My T61’s suspend and hibernate work again!

I found a solution on the lenovo forum, apparently the T61’s UPEK fingerprint reader driver 1.9.2.99 can be responsible. I’ve installed version 1.9.2.111 (download directly from UPEK), but I still get blue screens if I hibernate.

Other drivers known to be incompatible with SP1 are listed on Microsoft KB 948343, but I’m pretty sure I’m not running any of them. Any ideas?

Update (16th May 2008): The problem turned out to be Nortel’s Contivity VPN client.  They don’t appear to have released an updated version since SP1 was released.  I no longer have a need for this VPN client, so I simply uninstalled it.  Problem solved!

While I was trying to get to the bottom of this I read many suggestions.  Dodgy memory seems to be a common cause, and this can be checked by booting memcheck and leaving for a few hours.

I found the solution, it’s a simple change in Putty’s settings (Connection -> Data -> Terminal-type string).  By default this is set to “xterm” but changing it to “linux” fixes the home and end keys.

Jan 20 02:59:21 drevil sshd[12803]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:24 drevil sshd[12806]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:27 drevil sshd[12816]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:30 drevil sshd[12820]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:34 drevil sshd[12827]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:37 drevil sshd[12830]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:40 drevil sshd[12833]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:44 drevil sshd[12836]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:47 drevil sshd[12840]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:51 drevil sshd[12843]: error: PAM: Authentication failure for illegal user root from 213.136.100.86

There are several simple ways of reducing the chance of a break-in through this method:

1. Use strong passwords

This is an obvious place to start. The vast majority of these attacks come from automated scanning tools. These attempt to log in using passwords from a commonly used “dictionary”, so avoid simple words like “password”. Using a combination of letters, lower and upper case letters, and even symbols (!”£$%^&*) will give a password that is unlikely to be listed in a “common passwords” dictionary.

2. Restrict the users who can connect via ssh

OpenSSH has the capability to specify a “white list” of allowed users and deny all others. Simply add this line to your /etc/sshd_config and restart the sshd service:

AllowUsers dave mike sarah

This will block attempts to connect as any of the common system users (root, postfix, mysql etc), EVEN if the attacker guesses the correct password. If this list is kept as small as possible, it is much easier to verify these users have strong passwords.

3. Rate limit new ssh connections

A simple iptables script can be used to rate limit new incoming connection attempts. There are two ways of doing this, using the limit and recent iptables modules. Here’s the limit solution:

iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m limit –limit 3/min –limit-burst 3 -j ACCEPT
iptables -A NEW_SSH -j DROP

The third line ensures that connections from the internal network (in this example 10.0.0.0/24) are not subject to rate-limiting. The weakness of this approach is that while an attack is underway, ALL new ssh connections from outside are blocked. The recent module allows a slightly different approach (taken from debian administration):

iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m recent –set
iptables -A NEW_SSH -m recent –update –seconds 60 –hitcount 4 -j DROP
iptables -A NEW_SSH -j ACCEPT

This module “blacklists” IP addresses that exceed the rate limit, while still allowing other IP addresses to connect. If a connection makes it past this rate limiting, we accept it (last line).

4. Run your ssh server on a different port

The automated scanners look for ssh services on the default port (22), so if you move your sshd to a non-standard port less scanners will find you. It’s worth noting that this approach doesn’t improve security at all against a determined attacker. Personally I don’t use this technique, my SSH servers run on port 22.

My old laptop is a Dell D600, so I’m looking at the equivalent D630. When I bought the D600 there were two display options: XGA (1024×768) or SXGA+ (1400×1050). I went with the higher resolution option, and it’s been fantastic.

Reading the product pages, the D630 also has two options: WXGA (1280×800) or WXGA+ (1440×900). I can live with the slightly lower widescreen resolution of 1440×900, but 1280×800 is just too much of a step down.

Unfortunately, this display option is missing from the UK “customise and buy your laptop” section. Only one option is listed, and it’s the low-res one:

A visit to the Dell USA website shows the option exists over there:

I don’t really want the hassle of ordering a laptop over there, getting it shipped over here, replacing the USA keyboard with a UK one…

Ah well, there must be plenty of other laptop manufacturers who WILL give me a high-res screen…

ScottGu wrote his LINQ tutorials based on the Beta2 release of .NET 3.5. Between Beta2 and the final RTM, Microsoft renamed several methods:

• Add is now InsertOnSubmit
• AddAll is now InsertAllOnSubmit
• Remove is now DeleteOnSubmit
• RemoveAll is now DeleteAllOnSubmit

So when I followed Scott’s 3rd tutorial, I thought the methods were missing.

Of course, if you know where to look, this is all documented in the Linq to SQL Beta2 to RTM breaking changes document. But that doesn’t help the huge number of online tutorials already published with the Beta2 naming convention.

Dec 3 06:53:49 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:03:48 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:11:26 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:21:24 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:29:18 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:37:54 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:47:10 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)
Dec 3 07:56:11 drevil named[2765]: zone 20.0.10.in-addr.arpa/IN: serial number (61) received from master 10.0.20.10#53 < ours (62)

The solution is simple: Log onto the windows server, open the DNS management console, find the zone and click “increment” a couple of times on the serial number (SOA). But it’s very annoying, especially when the damn thing reboots itself every month for patch Tuesday!

It seems this was a documented problem in Windows Server 2000 (fixed in SP4): http://support.microsoft.com/kb/304653, but I can’t find any reference to the same problem in Server 2003.

Out of the box, the Shures came fitted with a medium sized plastic end. I tried this and while I initially thought it felt like a good fit, the sound wasn’t right (I couldn’t hear any bass at all!). I switched to the medium black rubber option, which looks nearly identical to the Fontopia, and the sound was much better.

Now I’ve used the Shures nearly every day for a month. Here are some things the Shures do better:

• The sound quality really is superior. They have less bass than the Sonys, but that gives a much more balanced sound (and remember if you can’t hear ANY bass, they’re not fitting well!) . The mids and highs sound fantastic.
• LOADS of different ear fitting options (3 sizes of rubber, 3 of plastic and 3 of foam), should mean they’re suitable for a wider range of ear canal shapes than the Sonys.

But here are some things the Sonys do better:

• They’re much smaller and lighter than the Shures (see photo below). Not only the headphones themselves, but the cable and plug too.
• They’re easier to fit in your ear. This is partly due to the smaller size, but also due to the strange way you’re supposed to loop the cable over your ear with the Shures. I think this is to support the extra weight, but I just find it annoying.
• Once the Sonys are in your ear, they just stay there. Even after a month of everyday use, I still have to fiddle with the Shures to keep them in the right place. I haven’t tried wearing them to the gym, but I don’t think they’d stay in for long if i did.
• They’re cheaper. Especially now the Shures aren’t on offer at Amazon!

To sum up, the Shures do deliver much better sound quality, but it’s at the expense of convenience.

Edit (April 2008): The shure headphones developed a fault after only 3 months so I returned them to Amazon for a full refund. I’m now using Sennheiser CX300 headphones, which are IMHO every bit as good sounding as the Shures, with the size and convenience of the Sony Fontopias. They’re MUCH cheaper too!

I spotted his domain as a new referring site on my Google Analytics stats.  Maybe that means someone else found his site first and clicked the link to me?

drevil:~# dmidecode -t memory
# dmidecode 2.8
SMBIOS 2.3 present.

Handle 0×1000, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: Not Provided
Number Of Devices: 2

Handle 0×1100, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_1
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)

Handle 0×1101, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_2
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)

Thanks to MJ Ray and Stuart Langridge, hopefully this will save me getting the screwdriver out in future!