tcpdump mailing list archives

Re: Request for a DLT code for IPMB packet


From: Guy Harris <gharris () sonic net>
Date: Fri, 22 Mar 2019 19:40:36 -0700

On Aug 13, 2007, at 11:45 AM, Toeung, Chanthy <chanthy.toeung () ca kontron com> wrote:

So presumably the first byte of the packet data will be the slave address, followed by the netFn and LUN, followed 
by the checksum, etc.?
yes. It is correct.

No, it's not.  The test file in this Wireshark bug:

        https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1970

and the "Totalphase Aardvark capture" linked to by this page:

        https://wiki.wireshark.org/IPMB_protocol

both have an extra 2-byte header before the I2C slave address, and the dissector in the Wireshark bug mentioned above 
processes those two bytes - the first is a length (which appears to be the length of the packet in the capture file 
minus 7 bytes, and, as such, redundant) and the second is apparently a port number - the documentation for Total 
Phase's Aardvark and Beagle devices for connecting to an I2C bus speak of "port numbers", which appear either to be USB 
port numbers or serial(?) port numbers.

I don't know whether that header comes from Total Phase hardware/firmware/software or Kontron's code to get caps from 
the Total Phase devices; for now, I'm going to rename LINKTYPE_IPMB and DLT_IPMB to LINKTYPE_IPMB_KONTRON and 
DLT_IPMB_KONTRON, to make it clear that they're *not* raw IPMB packets.

We don't advertise LINKTYPE_IPMB/DLT_IPMB on the "link-layer header types" page, and neither tcpdump nor Wireshark 
currently dissect that link-layer header type, so I suspect that re-designating it as "IPMB with the aforementioned 
2-byte header" (or with just two unspecified bytes for now - the length field is redundant and the "port number" field 
may not be relevant to any form of I2C traffic).
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Current thread: