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