On Wed, 12 Nov 2003, Jason Lunz wrote: > For several months now, I've been happily using a cheap 64M usb keychain > with linux 2.4.22 and debian unstable. At home, I connect it to a Via > usb controller, for which I use the usb-uhci module: > > [orr](0) % lspci | grep USB > 00:04.2 USB Controller: VIA Technologies, Inc. USB (rev 10) > 00:04.3 USB Controller: VIA Technologies, Inc. USB (rev 10) > > This is a uniprocessor Athlon. > > At work, my workstation is an SMP pentium III, with a serverworks > chipset and an ohci usb controller: > > [absolut](0) % lspci | grep USB > 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) > > Plugged into the USB controller is a kinesis USB keyboard with a > built-in USB hub. I connect the keychain to the keyboard when I use it. > > [absolut](0) % lsusb > Bus 001 Device 003: ID 05f3:0007 PI Engineering, Inc. > Bus 001 Device 002: ID 05f3:0081 PI Engineering, Inc. > Bus 001 Device 001: ID 0000:0000 > > Both setups worked fine with 2.4.22. The keychain was formatted with > three partitions: one big FAT one at the beginning for compatibility > (though it was only used once under linux), a small ext3 partition for > use under linux, and an ext2 partition intended to be read-only. > > The read-only partition contained ssh keys, and the usb-storage hotplug > script would mount it read-only by uuid, and if it found an active > ssh-agent and X session, would run ssh-askpass connected to them and > load the key with a timeout. The overall effect was that I could plug > my keychain into a workstation, enter a password into the box that > popped up, and have the key loaded into the ssh-agent with a timeout. > > There were always some problems with this under 2.4.22, but they were > never fatal. Sometimes, after inserting the keychain, the kernel would > detect no partitions on the device. Running 'blockdev --rereadpt > /dev/sda' was always enough to fix this, so I added it to the > usb-storage hotplug script. > > Another problem was that sometimes processes run under hotplug would be > killed for no reason, when the same script run manually would work fine. > This always happened at the same point when it happened at all. I never > had time to debug this, but worked around it instead. It > > Last friday, I tried out 2.6.0-test9-bk12 on the dual PIII at work. I > was curious to see if the process-dying problem was cured, so I tried > doing the hotplug thing a few times while tinkering with the script. It > worked a few times, and the process kill problem even seemed to be gone. > Then one time when I plugged in the keychain, there were no partitions. > /proc/partitions only showed /dev/sda. So I tried blockdev --rereadpt a > bunch of times, but still no dice. It was the end of the workday, so I > shrugged and went home. > > At home, with the same 2.4.22 setup that's always worked, it still > wouldn't work. Further investigation showed that the keychain is > completely hosed, even though there was _no_ write access ever attempted > on it under 2.6! > > I've made two copies of the raw device, one with cat and another with dd > using bs=512. They differ. I've combed through them in every way I know > how. There are recognizable things in there, like the copy of putty that > was on the fat partition. But there are no recognizable pieces of ssh > keys (except within the putty binary :), nor do any ext2/3 signatures > remain (i'm looking for the 0xEF53 magic that file(1) uses, in both byte > orders). > > The partition table is completely wiped. The image read with cat is all > 1's up to an offset of 0x50000 (320k). The same area read with dd is > entirely different. The first sector begins with this odd repeating > pattern: > > 0000000: 948b 45f0 8945 988b 45f4 8945 9c8b 45f8 ..E..E..E..E..E. > 0000010: 8945 a08b 45fc 8945 a48b 45e8 8945 a88b .E..E..E..E..E.. > 0000020: 45ec 8945 ac8b 45d0 8945 b08b 45d4 8945 E..E..E..E..E..E > 0000030: b48b 45c4 8945 b88b 45c8 8945 bcc7 45f4 ..E..E..E..E..E. > > so, I have kernel development experience and i'm willing to start > debugging this. But since that will involve reading and writing this usb > key, I want to ask here first if there's any possiblity of recovering > the data that was there. I have some slim hope that someone knows what > happened, and there might be some way to read the key that will return > the original data unmolested. > > any ideas? > > thanks, Jason
Nothing very helpful occurs to me. But I do have one un-helpful idea. > Further investigation showed that the keychain is > completely hosed, even though there was _no_ write access ever attempted > on it under 2.6! > The partition table is completely wiped. The image read with cat is all > 1's up to an offset of 0x50000 (320k). The same area read with dd is > entirely different. These suggest that your keychain just isn't working any more. Lord knows that catastrophic hardware failures _do_ occur from time to time. There was an unhappy experience a year or two ago where I left my computer running during a lunch break, and when I returned it had crashed. Investigation showed that the hard disk wasn't working, and inspection of the drive showed that one of the electronic components had burned up! There were scorch marks plainly visible on the circuit board and on the chip. You can try configuring usb-storage with verbose debugging turned on, and then try your dd copy of the raw device twice in a row. If you don't see any error messages in the dmesg log, and particularly if you get two different outputs from dd, that's a pretty clear indication of a problem in the keychain. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
