Andreas Becker wrote:
we are planing, to develop an new Protocol-Standard, called IP over I²C.
Once upon a time, somebody said something on the order of "any piece of
software expands its capabilities until it's able to read mail" (e.g.,
Emacs).
I wonder whether every single mechanism for transporting bits from one
place to another eventually expands its capabilities until you're able
to send IP packets over it. :-) (Well, to be fair, there are probably
*some* packet transport mechanisms that don't yet support IP and may
never do so. Perhaps a corollary is that those transport mechanisms
that don't expand to support IP eventually get encapsulated inside IP. :-))
For this standard, we think about to extend Etherreal to this new medium.
For the capturing we are bulding an Trace-Box, which provides the sampling
of I²C- Frames and sends them via Ethernet/UDP to an Linux Host.
I.e., encapsulating I2C packets inside UDP?
What schould we do to get thinks working like this?
How difficult is it to change the libpcap? Is it better to use wiretap?
If you're going to have Ethereal capture that traffic by capturing
I2C-over-UDP-over-Ethernet, then you wouldn't need to change libpcap, as
it can capture Ethernet - you'd just add support for I2C-over-UDP.
How difficult is it to implement an new Protocol like I²C-ARP to Etherreal?
Probably not *too* hard. If you have a standard port number, you'd
write a dissector that registered itself with "udp.port" with that port
number. Otherwise, if that traffic can be on some arbitrary UDP port,
you'd have to have a heuristic dissector that can detect I2C-over-UDP
packets by looking at them (putting a signature in those packets, e.g
the first 4 bytes being "I2CU", would help there).
Is there an conceptional error in my mind? (Better use an direct Linux- I²C
Driver?)
If you want to directly capture I2C traffic on the machine that's
sending or receiving the I2C traffic, you could perhaps
1) get a DLT_ value from tcpdump.org (ask tcpdump-workers@xxxxxxxxxxx);
2) add support to libpcap for capturing that traffic, somehow (if you
add a new ARPHRD_ value to Linux for this - which you'll probably need
to do anyhow if you're going to support IP-over-I2C on Linux - and have
I2C interfaces that plug into the Linux networking stack the same way
Ethernet and Token Ring and ATM and PPP and 802.11 and... interfaces do
- then the standard Linux libpcap code should only require that you map
that ARPHRD_ type to the corresponding DLT_ type);
3) add a new Wiretap encapsulation type and add support to Wiretap to
map that DLT_ type to the new Wiretap encapsulation type;
4) add a dissector for the Wiretap encapsulation type;
that'd work as well.
Note that if you add a new ARPHRD_ type you'd want to specify the
link-layer header that would appear on packets with that type, so that
tcpdump, Ethereal, etc. can handle the DLT_ type in question (which
would have that link-layer header).
