i2c fun stuff (Previous message: [XCSSA] cases with chassis intrusion sensor)

[xcssa@xcssa.org]

On 8/2/06, xcssa-admin@xcssa.org <xcssa-admin@xcssa.org> wrote:
> So are you saying that using an end adator to hook up one of the usb
> ends of aformentioned devices to a usb to ethernet connection,
> forwarding the tcp/ip packets to some other box, and unwinding the tcp
> packet with the results going on the usb stack as a local drive is not
> feasible or not reasonable?

That clears things up a bit, I had a reaction similar to tweeks when I
started reading this thread.

USB-to-ethernet... to proxy USB commands over an ethernet connection
(well, you'd really want an IP connection so you could route it)?
Hmm, can't say I've ever heard them used that way.  More than likely,
the USB side of things is doing some special protocol that USB
controllers use to talk to communication devices, and so the adapter
is not going to be "two-way and complete" like an impedance-matching
transformer would in an electrical circuit.  Chances are that
USB-to-harddrive connections use different upper layers in the USB
protocol stack which would not be present on a USB-to-ethernet adapter
and would not appear on the ethernet side at all, much like a TFTP
download will not appear on TCP port 80.  Also, it's not clear how to
make arbitrary userland data appear on the USB stack... perhaps there
is some clever hack to do it, like some kind of debugging or
simulation facility.  Creative, but absent any research I'd say it's
unlikely to manifest itself in reality any time soon.

If you have a device that can query the drive for its data on you, you
might as well print the data locally... if you don't, then you can't
ship it somewhere else to be decoded.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484