I like Parallels, even if it can be a real memory hog, but even the latest version doesn’t have very good USB support. Unfortunately, there’s a Windows application I want to use that requires good USB support. Even more unfortunately, it will never, ever run under Vista.

Why not? Because Minolta sold off their entire camera business to Sony, who has no interest in updating the remote-control software for the Dimage A2.

I don’t currently own any computers that run Windows XP, and I don’t particularly want to. But if I ever find the free time to start playing with studio lighting again, I’ll want to remote-control the A2, and with XP gradually disappearing from the market, now’s the time to figure out how.

With the latest Parallels 3.0 build, plugging the camera in while it’s in remote-control mode locks up the virtual machine.VMware Fusion not only handles the camera correctly, it seems to use about half as much memory.

[Note that there is an abandoned open-source project to decipher the Minolta protocol and write a GUI capture tool. I’m not really interested in hacking on it.]

Via Samurai Soapbox.

Okay, I’m stumped. We have a ReadyNAS NV+ that holds Important Data, accessed primarily from Windows machines. Generally, it works really well, and we’ve been pretty happy with it for the last few months.

Monday, the Windows application that reads and writes the Important Data locked up on the primary user’s machine. Cryptic error messages that decrypted to “contact service for recovering your corrupted database” were seen.

Nightly backups of the device via the CIFS protocol worked fine. Reading and writing to the NAS from a Mac via CIFS worked fine. A second Windows machine equipped with the application worked fine, without any errors about corrupted data. I left the user working on that machine for the day, and did some after-hours testing that night.

The obvious conclusion was that the crufty old HP on the user’s desk was the problem (it had been moved on Friday), so I yanked it out of the way and temporarily replaced it with the other, working Windows box.

It didn’t work. I checked all the network connections, and everything looked fine. I took the working machine back to its original location, and it didn’t work any more. I took it down to the same switch as the NAS, and it didn’t work. My Mac still worked fine, though, so I used it to copy all of the Important Data from the ReadyNAS to our NetApp.

Mounting the NetApp worked fine on all machines in all locations. I can’t leave the data there long-term (in addition to being Important, it’s also Confidential), but at least we’re back in business.

I’m stumped. Right now, I’ve got a Mac and a Windows machine plugged into the same desktop gigabit switch (gigabit NICs everywhere), and the Mac copies a 50MB folder from the NAS in a few seconds, while the Windows machine gives up after a few minutes with a timeout error. The NAS reports:

smbd.log: write_data: write failure in writing to client 10.66.0.151. Error Connection reset by peer smbd.log: write_data: write failure in writing to client 10.66.0.151. Error Broken pipe

The only actual hardware problem I ever found was a loose cable in the office where the working Windows box was located.

[Update: It’s being caused by an as-yet-unidentified device on the network. Consider the results of my latest test: if I run XP under Parallels on my Mac in shared (NAT) networking mode, it works fine; in bridged mode, it fails exactly like a real Windows box. Something on the subnet is passing out bad data that Samba clients ignore but real Windows machines obey. The NetApp works because it uses licensed Microsoft networking code instead of Samba.]

[8/23 Update: A number of recommended fixes have failed to either track down the offending machine or resolve the problem. The fact that it comes and goes is more support for the “single bad host” theory, but it’s hard to diagnose when you can’t run your tools directly on the NAS.

So I reached for a bigger hammer: I grabbed one of my old Shuttles that I’ve been testing OpenBSD configurations on, threw in a second NIC, configured it as an ethernet bridge, and stuck it in front of the NAS. That gave me an invisible network tap that could see all of the traffic going to the NAS, and also the ability to filter any traffic I didn’t like.

Just for fun, the first thing I did was turn on the bridge’s “blocknonip” option, to force Windows to use TCP to connect. And the problem went away. I still need to find the naughty host, but now I can do it without angry users breathing down my neck.]

Windows Vista really likes IPv6 (even tunneling it over IPv4 for you, quietly bypassing your NAT firewall). Outlook 2007 also likes IPv6, and if it’s available, will always try to use it to connect to an Exchange server.

We don’t have an IPv6 infrastructure. One of our wireless access points was configured to hand out IPv6 addresses. Connect the dots.

…Grindhouse-style.

Yesterday, a user’s VAIO BX640 dropped dead in the middle of a meeting. It didn’t come back, and by that I mean “nothing happens when you press the power button”. After swapping in different battery and power supply, I called for service.

This afternoon, another user reported that he wasn’t getting sound out of his BX640, and the headphone jack just made ticking noises. It doesn’t even make the magical VAIO noise when you power it on. I swapped parts around, reset the BIOS, etc. No luck. This isn’t a critical issue, so I’ll wait until Monday to ship it off for service, but it’s disturbing, because they’re both motherboard problems. And so was the only other one of my (more than a dozen) BX640s to fail so far, several months ago…

Judging from the first three pages, I’d say the editor:

As their eyes grew accustomed to the lack of light, they were drawn upward to the strangest feature of the scene...

[and, no, I didn’t wait in line last night; I fought past the rodeo crowds to get to Costco this morning to buy steak and garlic bread, and found a giant pile of Potters at the end of an aisle. As expected.]

[I’ll read it tomorrow, perhaps]

Once there was enough caffeine in my system, I remembered the first rule of system administration, and carefully reread the twice-forwarded email. Thanks, Walt; if you hadn’t passed on that key detail, we’d still be looking in the wrong place.

Oh, the rule? “Never let the user diagnose the problem.”