I am following up on a message that one of my engineers sent to the tcpdump list and apparently had difficulty getting through. Please see the message below. We look forward to comments.
Best Regards, Rich From: Dmitry [mailto:d-bazhe...@yandex.ru] Sent: Tuesday, May 27, 2014 8:52 PM To: Guy Harris Cc: tcpdump-workers@lists.tcpdump.org workers; Dmitry Bazhenov Subject: Re: [tcpdump-workers] DLT_ reserve request for IPMI trace captures 28.05.2014 3:24, Guy Harris пишет: On May 18, 2014, at 11:13 PM, Dmitry <mailto:d-bazhe...@yandex.ru> <d-bazhe...@yandex.ru> wrote: Hello, Guy, 17.05.2014 7:24, Guy Harris пишет: On May 9, 2014, at 4:11 AM, Dmitry <mailto:d-bazhe...@yandex.ru> <d-bazhe...@yandex.ru> wrote: ... ----------------------------------------------------------- 10 1 Size of subpacket data. ----------------------------------------------------------- 11 N Data bytes. ----------------------------------------------------------- So what's the format of the data bytes? Presumably some section of the IPMI spec describes how the bytes of the message are laid out in the payload. And what does the size of the subpacket data signify? The format depends on the Trace Data Block Type and IPMI Trace Data type. If the Trace Data Block type is IPMI Trace Packet Data, the format is specified by the IPMI specification besing on the channel type (per IPMI Trace Data type). So Table 6-2, Channel Protocol Type Numbers, indicates where the message formats are described in various specifications? The described message formats are all described in various chapters of the IPMI specification. I.e., the data format could be different for different channel types, rather than all just containing NetFn, LUN, Command, and command data for requests and NetFn, LUN, Command, and Completion Code for responses? For different channel formats varies only the header and footer. Such, for KCS message format there is no responder/request addresses, sequence number or checksum bytes. While the command data stay the same regardless of the channel type. Or is the various framing, etc. for the transport channel removed, with just IPMI messages, in the same format for all channel types, stored in the file? No, it is kept in the file together with the command data. If the Trace Data Block Type = Channel State Change Notification , the format is specified in the PICMG HPM.2 specification. Is there a particular section of the spec to which that should refer? (I don't have a copy of the spec, and I'm not going to spend USD $100 and wait for a printed copy to arrive.) In the HPM.2 specification, the Channel State Change Notification is described in Section 3.11.3 "IPMI Trace Payload data format and protocol" and specifically in the Table 3-21 "IPMB Channel State Change Notification Data Format" with the following fields: Field Size Description ----------------------------------- Data Format 1 0h = Derived from PICMG 3.0 IPMB-0 Sensor Reading Format Other values are reserved. ----------------------------------- State Change 1 [7:4] – Reserved, write as 0 [3] – IPMB Override Status 0b = Override status, bus isolated 1b = Local Control state – IPM Controller determines state of bus. [2:0] = IPMB Local Status 0h = No Failure. Bus enabled if no override in effect. 1h = Unable to drive clock HI 2h = Unable to drive data HI 3h = Unable to drive clock LO 4h = Unable to drive data LO 5h = Clock low timeout 6h = Under test (the IPM Controller is attempting to determine if it is causing a bus hang) 7h = Undiagnosed Communications Failure Information ----------------------------------- If the Trace Data Block Type = Embedded ASCII message, the format is simple ASCII string. The subpacket data size is the length of the embedded message, whether it IPMI message, channel notification or ASCII message. The thing is that the suggested format is an exact copy of the Trace Data Block specified in the HPM.2. Hopefully this is stronger than just "suggested", i.e. hopefully this isn't going to require that, for a capture, the user specify whether the suggestions are being followed or if the messages to dissect are something *other* than said Trace Data Blocks. So are you saying that the packet data, starting with the Trace Data Block Type byte, is in the format specified in some part of HPM.2? Correct. It is specified in the Table 3-20 "Trace Data Block Format" of the HPM.2 specification Regards, Dmitry _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
