[tcpdump-workers] Request to add MCTP and PCI_DOE to PCAP link type

[Yao, Jiewen via tcpdump-workers]

--- Begin Message ---
Hi
I write this email to request to below 2 link types.


  1.  MCTP

Management Component Transport Protocol (MCTP) is an industry standard defined 
by Distributed Management Task Force (DMTF) Platform Management Communication 
Interface (PMCI) working group (https://www.dmtf.org/standards/pmci)

DSP0236 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.1.pdf)
 is the Management Component Transport Protocol (MCTP) Base Specification. It 
defines the MCTP transport header.
DSP0239 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0239_1.7.0.pdf)
 defines the Management Component Transport Protocol (MCTP) IDs and Codes. It 
defines the MCTP message type in a MCTP packet payload.

Proposal:

LINKTYPE_ name
LINKTYPE_ value
Corresponding DLT_ name
Description
LINKTYPE_MCTP
XXX
DLT_MCTP
MCTP packet is defined in DMTF PMCI working group Management Component 
Transport Protocol (MCTP) Base 
Specification(https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.1.pdf)
 8.1 MCTP packet fields. It starts with MCTP transport header in Figure 4 - 
Generic message fields.



  1.  PCI_DOE

PCI Data Object Exchange (DOE) is an industry standard defined by PCI-SIG 
(https://pcisig.com/) Data Object Exchange (DOE) 
ECN 
(https://members.pcisig.com/wg/PCI-SIG/document/14143).


Proposal:

LINKTYPE_ name
LINKTYPE_ value
Corresponding DLT_ name
Description
LINKTYPE_PCI_DOE
XXX
DLT_PCI_DOE
PCI Data Object Exchange (DOE) is defined in PCI-SIG Data Object Exchange (DOE) 
ECN (https://members.pcisig.com/wg/PCI-SIG/document/14143) 6.xx.1 Data Objects. 
It starts with DOE Data Object Header 1 in Figure 6-x1: DOE Data Object Format.



The reason I submit this request is because we are implementing a "SpdmDump" 
tool to dump the SPDM message defined in DMTF PMCI Security Protocol and Data 
Model (SPDM) Specification DSP0274 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.1.0.pdf).
SPDM is similar to network Transport Layer Security (TLS) protocol. It is a 
transport layer protocol.
The MCTP and the PCI_DOE are the transport layer binding to send message to 
hardware device (MCTP capable device or PCI_DOE capable device).

We did a prototype for the SpdmDump tool 
(https://github.com/jyao1/openspdm/blob/master/Doc/SpdmDump.md). We can 
generate a PCAP file and parse it offline.
In our prototype, we use below definition:
#define LINKTYPE_MCTP  290  // 0x0122
#define LINKTYPE_PCI_DOE   291  // 0x0123
If you can assign same number, it will be great.
If different number is assigned, we will change our implementation accordingly.

Thank you
Yao Jiewen



--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] testing 1.2.3

[mcr--- via tcpdump-workers]

--- Begin Message ---
testing 1.2.3.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] testing 1.2.3

[mcr--- via tcpdump-workers]

--- Begin Message ---
testing 1.2.3.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] testing 1.2.3

[mcr--- via tcpdump-workers]

--- Begin Message ---
testing 1.2.3.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] sorry for all the testing

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Simple tests like:
  echo "testing 1.2.3." | Mail -s "testing 1.2.3" 
tcpdump-workers@lists.tcpdump.org

are working, but complex emails are not.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] pcap_open_offline_... and options and the like

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
trying without GPG signature

{Hi, my email never made it through the list earlier.
Francois' email went through earlier today, so I am at a loss
as to what has happened.  And other lists worked.  I thought mailman was
stuck, but I dunno.  I backed up the list configuration, and list names, and
remade the list, and then I found other postfix vs mailman issues that seemed
to affect only lists hosted at lists.tcpdump.org.  Moving on, I hope}


We have:
   pcap_t *
   pcap_open_offline_with_tstamp_precision(const char *fname, u_int precision,
char *errbuf)

and:
  pcap_t *
  pcap_open_offline(const char *fname, char *errbuf)

and then we have:
 #ifdef _WIN32
  pcap_t* pcap_hopen_offline_with_tstamp_precision(intptr_t osfd, u_int 
precision,
  char *errbuf)

And we have a pull request
https://github.com/the-tcpdump-group/libpcap/pull/982 that I just rebased
that adds a "hidden" option.
Code originally from Ray Bellis, and a lot of the root DNS operators want this.
Note that this loads a .so file to do the work.
  Examples are at:
https://github.com/DNS-OARC/dnscap/blob/develop/src/dumper.c
https://github.com/raybellis/libpcap-gzip

Ray went in that direction when we complained that distros might not want an
additional dependancy upon -lz or something else.

  { So I come to believe that I erred here: the dependancy upon -lz might have
been better than this.  But.}

The pcap_open_offline() patched starts with:
const pcap_ioplugin_t *plugin = 
pcap_ioplugin_init(getenv("PCAP_IOPLUGIN_READ"));

And I really don't want to do it this way with the environment variable.
(Convince me otherwise)

I really think that changing behaviour of programs via environment variables
is a recipe for security holes.   I would much happier if this was a --option
for tcpdump, and if anyone wants to pull it from an an environment variable
that they put that into the application rather than the library.

So I would prefer if the code instead did some new pcap_open_offline_with..(new 
argument).
Something that we could expand without continuing to make new functions!

For many things, the best situation is if we can do a pcap_set_XXX().
For timestamps, we didn't do that, because we need the precision in order to
help validate the pcap header.  Perhaps we could have done this another way.

For live captures, we have the sequence pcap_create/pcap_activate split,
and perhaps there is a way that we can make use of the same kind of flow.
(Note that the pcap(3) page is vague as to what things can be between
pcap_create() and pcap_activate)

Options that I see are:
  1) do nothing for input, we can solve this later.
 The major win is on output, and just create pcap_dump_compressed_open()
 for now.

  2) rework input and output so that a pcap_t */pcap_dumper_t * could be
 returned, uninitialized, accept some set_options, and then be activated.

  3) more extensive rework so that pcap_create() could create handle for
 live and offline captures, and that specifying the capture type was
 just another set.

These are not mutually exclusive.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] pcap_open_offline_... and options and the like

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Michael Richardson via tcpdump-workers wrote:
> trying without GPG signature

YUP. That's it.  So mailman2 will have to get replaced finally.
It eats emails with signature attachments, I think.  This is new.

After a few hours thinking about my previous email I wanted to reply about my
current thinking, and then was surprised not to see my email having got
through.

The distro on my list machine doesn't have mailman3, so maybe it is getting
upgraded too!.

In https://github.com/the-tcpdump-group/libpcap/pull/983
Guy asked:

guy> "Would affect" as in "those would be changed in separate commits"?

guy> This is similar to some stuff I've been thinking about, based on
guy> some long-ago requests for device-specific options.

guy> The stuff I've been working on gave a name and description for
guy> each option; the name is for use on the command line, e.g. with a
guy> --capture-option flag, e.g. --capture-option channel=XXX, and the
guy> description would be for use in 1) GUI applications such as Wireshark
guy> and 2) a --show-capture-options flag that would give a list, for a given
guy> device, of the available options, giving the name and the description.

guy> Presumably:

guy> this would affect pcap_init() by having a set of global pcap options to
guy> apply (in an argument to pcap_init()?;

guy> this would affect 'pcap_activate()by having a per-device list of
guy> options, with calls to set the options being made afterpcap_create()and
guy> beforepcap_activate()`;

guy> this would affect pcap_open_offline() by having something such as a
guy> pcap_open_offline_with_options() call that takes a list of options as an
guy> argument;

guy> this would affect pcap_dump_open*() by having similar
guy> pcap_dump_open*_with_options() routines.
guy> There would presumably be calls to indicate which options are available 
for a particular context.

To which I replied:

> The stuff I've been working on gave a name and description for each option;
> the name is for use on the command line, e.g. with a --capture-option flag,
> e.g. --capture-option channel=XXX, and the description would be for use in
> 1) GUI applications such as Wireshark and 2) a --show-capture-options flag
> that would give a list, for a given device, of the available options,
> giving the name and the description.

I think that it could support such use case with some additional calls.
There is perhaps a chicken and egg issue with not knowing which options apply
until a device has been selected.
But at least, compile time options in libpcap would become apparent.

> There would presumably be calls to indicate which options are available for a 
> particular context.

yes, I think so.
See what I roughed out in this pull request, which is the minimum I think I
need to do the ioplugin.
Strings and integers and an ENUM. Maybe we want to have a call to find out if
an enum is valid (i.e. not #ifdef out).

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers