On Thursday 30 Sep 2004 3:33 pm, Andreas Becker wrote:
> > As far as I remember I2C,
> > a. it was a 2 wire protocol?
> > b. the address of the devices was the 1st 4 bits? (this is from
> > what i remember on the intel 80552, I dont know what the philips
> > bus follows or the latest standard now)
>
> You are right. (Adress is 7 or 10 bit's)
>
> > However if you are sampling from a I2C wire-tapping box, just
> > define your own protocol type for TCP/UDP , send it to a PC over
> > TCP/UDP, and write any standard dissector to dissect on top of
> > those ports.
>
> Ok. The "Dissector" is the word I'm looking for? Is it a part of the
> libpcap or it is a part of ethereal?
It's part of Ethereal. Out of the box Ethereal would give you your I2C
message as hex bytes. It is fairly simple to write a dissector for
Ethereal that decodes the I2C protocol and gives you the address and
the flags as separate fields. If you have a specific protocol over I2C
it could also decode that. Nobody's done that yet, of course; you'd
have to do it.
> I am thinking about the IC-MAC Adresses ( 7/10 Bit) ( Link Layer) is
> this stuff done by the dissector ?
If you wrote it, yes.
> > You would probably also need a way to build a "conversation tree"
> > between 2 devices on the bus.
>
> Good to keep this in mind. Pehaps we expand the IC protocol, so that
> every sender has to send his own device-address with every Packet
> send. (Like Ethernet does.)
Yes, but unless you have a good reason to do so, it would reduce the
utility. You couldn't use it for standard I2C.
> > A simpler way could to treat the transaction between the 2 devices
> > as one "conversation", terminate it with a fin when sending it to
> > the PC and let the ethereal's conversation-handler with &pinfo to
> > match the TCP fin and that can handle it for you.
> >
> > hope this helps, (if my memory is correct).....
>
> Yea, I'm looking forward.
It would be simpler and more generic to treat all messages to a given
chip as a single conversation. IIUC, that would be OK in most cases,
and in the remainder it just redefines "conversation" a little. It's
still useful, in that it partitions each device into its own
compartment. If you can arrange the destination IP address to be an
encoding of the I2C address, then the UDP conversation code should do
the job for you, but you would need to connect the Linux machine to the
box using a dumb hub or a direct patch lead; putting a switch in there
would mean that the Linux box wouldn't see the traffic. (Most cheap
"hub" these days are switches.) If that frob is too ugly you would have
to write the conversation code yourself. I don't know how hard that is,
but it's probably fairly straightforward.
Have you considered yet how the converter box is going to work? It could
do some degree of decoding there.
--
Richard Urwin
