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
-------------------------------------------------------
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
