[tcpdump-workers] Request for a DLT code for IPMB packet

Guy Harris gharris at sonic.net
Fri Mar 22 22:40:36 EDT 2019


On Aug 13, 2007, at 11:45 AM, Toeung, Chanthy <chanthy.toeung at 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).


More information about the tcpdump-workers mailing list