Discussion:
DLT_ reserve request for IPMI trace captures
Dmitry
2014-05-08 16:07:42 UTC
Permalink
Hello, all,

Can I expect any reply (better positive :)) regarding my question?
If more details are required in order to get progress on the request, I
can submit them.

Looking forward for any comments.

Regards,
Dmitry
Hello, PCAP library maintainers,
Please, reserve a DLT_ number for IPMI message trace captures used by
the Pigeon Point Systems ipmb_traced utility.
The ipmb_traced utility is capable to capture IPMI traces from several
IPMI channels simultaneously. The traced IPMI channels may have
different messaging protocols.
The captured data includes meta-data which describes each trace
packet: which channel the packet is from, its direction, protocol
format, and other characteristics.
The capture data format differs from formats of already defined DLT_
types (199 and 209), thus, the new DLT_ value is needed.
My suggestion is to name the new value as DLT_IPMI_TRACE.
With regards,
Dmitry Bazhenov
Guy Harris
2014-05-08 19:47:53 UTC
Permalink
Post by Dmitry
Can I expect any reply (better positive :)) regarding my question?
You can't expect a reply until people see your message. :-)

Your original message never arrived in my mailbox, and may never have made it to the list (moderation?), so I didn't see anything until today.
Post by Dmitry
If more details are required in order to get progress on the request, I can submit them.
Looking forward for any comments.
Regards,
Dmitry
Hello, PCAP library maintainers,
Please, reserve a DLT_ number for IPMI message trace captures used by the Pigeon Point Systems ipmb_traced utility.
The ipmb_traced utility is capable to capture IPMI traces from several IPMI channels simultaneously. The traced IPMI channels may have different messaging protocols.
The captured data includes meta-data which describes each trace packet: which channel the packet is from, its direction, protocol format, and other characteristics.
Please give a detailed description of the meta-data format, with the byte order of multi-byte integral-valued fields specified.
Dmitry
2014-05-09 11:11:03 UTC
Permalink
Hello, Guy,

I guess there was some race between my authorization in the
tcpdump-workers mailing list and my first mail.

Here is the meta-data structure:

Offset Size Description
-----------------------------------------------------------
0 1 Trace Data Block Type
[7:6] Reserved
[5:4] Packet Type
0 – IPMI Trace Packet Data.
1 - Channel State Change Notification.
2 - Embedded ASCII message.
3 - Reserved.
[3:0] – IPMI Channel Number being traced.
-----------------------------------------------------------
1 4 Timestamp (seconds part), little endian
-----------------------------------------------------------
5 2 Timestamp (milliseconds part in the range 0 to 999),
little endian
-----------------------------------------------------------
7 1 Trace Data Type(IPMI Channel Protocol Type)
See IPMI 2.0 Table 6-2, “Channel Protocol Type
Numbers”.
The following values are defined in the IPMI 2.0
specification:
00h - n/a
01h - IPMB-1.0
02h - ICMB-1.0
03h - reserved
04h - IPMI-SMBus
05h - KCS
06h - SMIC
07h - BT-10
08h - BT-15
09h - TMode
1Ch-1Fh – OEM Protocol 1 through 4
All other - reserved
-----------------------------------------------------------
8 2 Additional Protocol-specific data, little endian
Additional data. Depends on the IPMI Channel
Protocol Type for this packet.
For protocol = IPMB-1.0
Byte 1
[7] - Direction
0 – From IPM Controller to target device.
1 – From target device to IPM Controller.
[6] – Redundant channel indicator. When IPMI
Channel does not support
redundancy, 0 must be returned.
0 – First channel. (IPMB-A in the case of redundant
IPMB-0)
1 – Second channel. (IPMB-B in the case of
redundant IPMB-0)
[5:0] – Radial IPMB Link Number (0 if IPMB is
bussed), see below.
Byte 2
[7:0] – Reserved.
NOTE: For the IPMB-1.0 protocol, the connection
topology can be either
radial or bused. In the case of a radial topology,
each IPMB device (or
possibly group of IPMB devices) is connected with a
radial hub via a
separate link. If an IPMB radial hub is traced, the
number of the link over
which the packet is sent or received is included in
byte 1 of the additional
data.
For Host-Interface (KCS, SMIC, BT-10, BT15)
Byte 1
[7] - Direction
0 – From IPM Controller to host.
1 – From host to IPM Controller.
[6:0] – Reserved.
Byte 2
[7:0] – Reserved.
-----------------------------------------------------------
10 1 Size of subpacket data.
-----------------------------------------------------------
11 N Data bytes.
-----------------------------------------------------------

Regards,
Dmitry
Post by Guy Harris
Post by Dmitry
Can I expect any reply (better positive :)) regarding my question?
You can't expect a reply until people see your message. :-)
Your original message never arrived in my mailbox, and may never have made it to the list (moderation?), so I didn't see anything until today.
Post by Dmitry
If more details are required in order to get progress on the request, I can submit them.
Looking forward for any comments.
Regards,
Dmitry
Hello, PCAP library maintainers,
Please, reserve a DLT_ number for IPMI message trace captures used by the Pigeon Point Systems ipmb_traced utility.
The ipmb_traced utility is capable to capture IPMI traces from several IPMI channels simultaneously. The traced IPMI channels may have different messaging protocols.
The captured data includes meta-data which describes each trace packet: which channel the packet is from, its direction, protocol format, and other characteristics.
Please give a detailed description of the meta-data format, with the byte order of multi-byte integral-valued fields specified.
Dmitry
2014-05-16 12:59:27 UTC
Permalink
Hello, Guy,

Did you get the mail with the format details?

I'm looking forward to your comments.

Regards,
Dmitry
Post by Dmitry
Hello, Guy,
I guess there was some race between my authorization in the
tcpdump-workers mailing list and my first mail.
Offset Size Description
-----------------------------------------------------------
0 1 Trace Data Block Type
[7:6] Reserved
[5:4] Packet Type
0 – IPMI Trace Packet Data.
1 - Channel State Change Notification.
2 - Embedded ASCII message.
3 - Reserved.
[3:0] – IPMI Channel Number being traced.
-----------------------------------------------------------
1 4 Timestamp (seconds part), little endian
-----------------------------------------------------------
5 2 Timestamp (milliseconds part in the range 0 to 999),
little endian
-----------------------------------------------------------
7 1 Trace Data Type(IPMI Channel Protocol Type)
See IPMI 2.0 Table 6-2, “Channel Protocol Type
Numbers”.
The following values are defined in the IPMI 2.0
00h - n/a
01h - IPMB-1.0
02h - ICMB-1.0
03h - reserved
04h - IPMI-SMBus
05h - KCS
06h - SMIC
07h - BT-10
08h - BT-15
09h - TMode
1Ch-1Fh – OEM Protocol 1 through 4
All other - reserved
-----------------------------------------------------------
8 2 Additional Protocol-specific data, little endian
Additional data. Depends on the IPMI Channel
Protocol Type for this packet.
For protocol = IPMB-1.0
Byte 1
[7] - Direction
0 – From IPM Controller to target device.
1 – From target device to IPM Controller.
[6] – Redundant channel indicator. When IPMI
Channel does not support
redundancy, 0 must be returned.
0 – First channel. (IPMB-A in the case of
redundant IPMB-0)
1 – Second channel. (IPMB-B in the case of
redundant IPMB-0)
[5:0] – Radial IPMB Link Number (0 if IPMB is
bussed), see below.
Byte 2
[7:0] – Reserved.
NOTE: For the IPMB-1.0 protocol, the connection
topology can be either
radial or bused. In the case of a radial topology,
each IPMB device (or
possibly group of IPMB devices) is connected with
a radial hub via a
separate link. If an IPMB radial hub is traced,
the number of the link over
which the packet is sent or received is included
in byte 1 of the additional
data.
For Host-Interface (KCS, SMIC, BT-10, BT15)
Byte 1
[7] - Direction
0 – From IPM Controller to host.
1 – From host to IPM Controller.
[6:0] – Reserved.
Byte 2
[7:0] – Reserved.
-----------------------------------------------------------
10 1 Size of subpacket data.
-----------------------------------------------------------
11 N Data bytes.
-----------------------------------------------------------
Regards,
Dmitry
Post by Guy Harris
Post by Dmitry
Can I expect any reply (better positive :)) regarding my question?
You can't expect a reply until people see your message. :-)
Your original message never arrived in my mailbox, and may never have
made it to the list (moderation?), so I didn't see anything until today.
Post by Dmitry
If more details are required in order to get progress on the
request, I can submit them.
Looking forward for any comments.
Regards,
Dmitry
Hello, PCAP library maintainers,
Please, reserve a DLT_ number for IPMI message trace captures used
by the Pigeon Point Systems ipmb_traced utility.
The ipmb_traced utility is capable to capture IPMI traces from
several IPMI channels simultaneously. The traced IPMI channels may
have different messaging protocols.
The captured data includes meta-data which describes each trace
packet: which channel the packet is from, its direction, protocol
format, and other characteristics.
Please give a detailed description of the meta-data format, with the
byte order of multi-byte integral-valued fields specified.
Guy Harris
2014-05-17 01:24:40 UTC
Permalink
On May 9, 2014, at 4:11 AM, Dmitry <d-***@yandex.ru> wrote:

...
Post by Dmitry
-----------------------------------------------------------
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?
Rich Vasse
2014-06-06 15:44:32 UTC
Permalink
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-***@yandex.ru]
Sent: Tuesday, May 27, 2014 8:52 PM
To: Guy Harris
Cc: tcpdump-***@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-***@yandex.ru> <d-***@yandex.ru> wrote:


Hello, Guy,

17.05.2014 7:24, Guy Harris пишет:

On May 9, 2014, at 4:11 AM, Dmitry <mailto:d-***@yandex.ru> <d-***@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
Guy Harris
2014-06-07 20:17:17 UTC
Permalink
Post by Rich Vasse
Post by Rich Vasse
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
OK, so all we would need to say on http://www.tcpdump.org/linktypes.html would be:

LINKTYPE_whatever {number} DLT_whatever Trace data blocks, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification

with "PICMG HPM.2 specification" linking to http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=12 (that being the closest thing we can provide to a link to the spec)?

And a trace data block begins with

0 1 Trace Data Block Type
[7:6] Reserved
[5:4] Packet Type
0 – IPMI Trace Packet Data.
1 - Channel State Change Notification.
2 - Embedded ASCII message.
3 - Reserved.
[3:0] – IPMI Channel Number being traced.

and the HPM.2 spec describes the format of IPMI Trace Packet Data (either directly or by referring to IPMI specs), the format of Channel State Change Notifications, and the format of embedded ASCII messages?

Correct?

Also, are the time stamps in pcap records or pcap-ng packet blocks significant, given that the trace blocks contain their own time stamps?
Dmitry
2014-06-09 05:22:16 UTC
Permalink
Hello, Guy,

Please, see below
Post by Guy Harris
LINKTYPE_whatever {number} DLT_whatever Trace data blocks, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification
with "PICMG HPM.2 specification" linking to http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=12 (that being the closest thing we can provide to a link to the spec)?
Correct.
Post by Guy Harris
And a trace data block begins with
0 1 Trace Data Block Type
[7:6] Reserved
[5:4] Packet Type
0 – IPMI Trace Packet Data.
1 - Channel State Change Notification.
2 - Embedded ASCII message.
3 - Reserved.
[3:0] – IPMI Channel Number being traced.
and the HPM.2 spec describes the format of IPMI Trace Packet Data (either directly or by referring to IPMI specs), the format of Channel State Change Notifications, and the format of embedded ASCII messages?
Correct?
Correct.
Post by Guy Harris
Also, are the time stamps in pcap records or pcap-ng packet blocks significant, given that the trace blocks contain their own time stamps?
They would not be significant, if Wireshark did not use them for
displaying packet times. But, since Wireshark does use them, then for
the sake of usability they are in fact significant and should match the
time stamps in the captured trace data blocks.
Guy Harris
2014-06-09 07:43:35 UTC
Permalink
Post by Rich Vasse
Post by Guy Harris
LINKTYPE_whatever {number} DLT_whatever Trace data blocks, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification
with "PICMG HPM.2 specification" linking to http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=12 (that being the closest thing we can provide to a link to the spec)?
Correct.
OK, I've assigned 260 to LINKTYPE_IPMI_HPM_2/DLT_IPMI_HPM_2, with a description of:

IPMI trace packets, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification.

with the link done as specified.
Post by Rich Vasse
Post by Guy Harris
Also, are the time stamps in pcap records or pcap-ng packet blocks significant, given that the trace blocks contain their own time stamps?
They would not be significant, if Wireshark did not use them for displaying packet times. But, since Wireshark does use them,
As will other programs that read pcap or pcap-ng files and don't treat LINKTYPE_IPMI_HPM_2 specially (one reason for this registry is to allow other programs to process whatever pcap/pcap-ng link-layer header types the developers choose; the goal is to *avoid* tying link-layer header types to tcpdump or Wireshark or any other program - it should be possible for people to write code to read or write packets of any given link-layer header type without ever having to see any tcpdump/Wireshark/etc. code that reads or writes them).
Dmitry
2014-06-09 08:03:51 UTC
Permalink
Hello, Guy,

Please, see below.
Post by Guy Harris
IPMI trace packets, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification.
with the link done as specified.
Thanks.
Post by Guy Harris
Post by Rich Vasse
Post by Guy Harris
Also, are the time stamps in pcap records or pcap-ng packet blocks significant, given that the trace blocks contain their own time stamps?
They would not be significant, if Wireshark did not use them for displaying packet times. But, since Wireshark does use them,
As will other programs that read pcap or pcap-ng files and don't treat LINKTYPE_IPMI_HPM_2 specially (one reason for this registry is to allow other programs to process whatever pcap/pcap-ng link-layer header types the developers choose; the goal is to *avoid* tying link-layer header types to tcpdump or Wireshark or any other program - it should be possible for people to write code to read or write packets of any given link-layer header type without ever having to see any tcpdump/Wireshark/etc. code that reads or writes them).
Since the proposed capture format is generated by a proxy agent which
transforms the captured data from the UDP-based connection, time stamps
in pcap records/pcap-ng packet blocks may be interpreted as times of
receiving of the encapsulated trace data blocks by the proxy from the
capturing device, while the trace data block contain time stamps for the
captured trace messages.
The only utility which I know generates data in the proposed capture
format, makes the timestamps in pcap records equal to the stamps in the
trace data blocks which is convenient when browsing the captured data in
Wireshark. However, in general, this is not required. In that sense, the
proposed capture format is not tied to any analyzing program.

Regards,
Dmitry

Loading...