Guy,
Thanks!
Yes, I noted the DLT_IPMB value. However, our captures also contain
message flags (as passed by the driver), and driver events - which
DLT_IPMB format doesn't allow for.
Best regards,
Alexey.
On 22 December 2007 Guy Harris wrote:
> Alexey Neyman wrote:
> > Okay, I am convinced. L
Alexey Neyman wrote:
Okay, I am convinced. Let it be DLT_IPMB_LINUX then.
OK, I've added it, with the value 209.
(Note that there's also a DLT_IPMB, in which the packet begins with the
I2C slave address, followed by the netFn and LUN, etc.; presumably yours
is different.)
-
This is the tcp
Guy,
> Well, that would have the advantage that files are self-identifying.
> If the file is only ever read once, that's just a question of whether
> to indicate the file type when you do the capture or when you read
> the file; however, if it's read more than once, with a link-layer
> type that
Alexey Neyman wrote:
If you think that choosing the type of protocol in reading application
is not enough - well, let's call it DLT_IPMB_LINUX; we'll add the
ability to select the DLT_ value in the capture utility.
Well, that would have the advantage that files are self-identifying. If
the
Guy,
> So if it were to be used for other I2C-based buses, would the
> expectation be that you'd have to configure the application reading
> the file to indicate what protocol is being used?
Yes, in the Wireshark changes that we'll submit it is possible to select
the protocol being used on I2C b
Alexey Neyman wrote:
It can be used for any other I2C-based bus, though we only use it to
capture IPMB traffic. The capture utility is agnostic of the traffic
type - so traffic type is not present in the pseudo-header.
So if it were to be used for other I2C-based buses, would the
expectation
Guy,
> So would this be usable for any other I2C-based buses? If not,
> perhaps the name should include IPMB. If so, does the pseudo-header
> indicate what type of traffic it is?
It can be used for any other I2C-based bus, though we only use it to
capture IPMB traffic. The capture utility is a
Alexey Neyman wrote:
They bit values are not specific themselves (e.g. status bits
include "Controller lost attachment to bus", "Controller had
promiscuous mode set/cleared", etc) - most likely, these bits will be
available on different OS, too. However, the definitions of these
status bits m
Guy,
Is this request being processed/queued?
Best regards,
Alexey.
On 29 November 2007 Alexey Neyman wrote:
> Guy,
>
> On 29 November 2007 Guy Harris wrote:
> > > The format of the capture is a 5-byte pseudo header followed by
> > > the actual I2C data. The MS bit of 1st byte of pseudo-header
>
Guy,
On 29 November 2007 Guy Harris wrote:
> > The format of the capture is a 5-byte pseudo header followed by the
> > actual I2C data. The MS bit of 1st byte of pseudo-header indicates
> > whether the packet contains data or is an event detected on the I2C
> > controller. The remaining 7 bits con
Alexey Neyman wrote:
The format of the capture is a 5-byte pseudo header followed by the
actual I2C data. The MS bit of 1st byte of pseudo-header indicates
whether the packet contains data or is an event detected on the I2C
controller. The remaining 7 bits contain the minor number of the I2C
Hi,
We have an utility that allows capturing the I2C traffic over the IPMB
bus; that utility generates capture files in libpcap format for later
use with WireShark for analysis. We would like to have a link type
number assigned for such captures. We are going to submit the necessary
changes f
12 matches
Mail list logo
