Add LINKTYPE_MCTP/DLT_MCTP and LINKTYPE_PCI_DOE/DLT_PCI_DOE

[jyao1]

Those are media type for DMTF Secure Protocol and
Data Model (SPDM) messages.

[mcr]

It's annoying not to have a PCISIG reference, but I think that we can perhaps live with that.

[infrastation]

This DLT request has been in the queue for a while.

[infrastation]

The MCTP link-layer header includes neither the medium-specific header nor the medium-specific trailer, correct?

[guyharris]

DMTF Secure Protocol and Data Model (SPDM) messages

Presumably that's the DMTF Security Protocol and Data Model (SPDM).

If so, presumably the packet contents for LINKTYPE_MCTP are described by section 4.7.1 "Generic SPDM message format", so the first octet of packet data is an octet containing the SPDM major and minor versions, followed by an octet containing the Request Response Code, and so forth.

[guyharris]

And presumably LINKTYPE_PCI_DOE is for the PCI Data Object Exchange. Sadly, the PCI SIG allows only members of organizations that are members of the PCI SIG to get at the documents for it, but the entry for it on the link-layer header types page should at least mention the names of the specifications on the PCI SIG Specifications page, so people who work for organizations that are members of the PCI SIG can get at them.

(And note that either tcpdump or Wireshark code to dissect them are subject to changes due to either tcpdump or Wireshark dissector programming interface changes; absent a spec that's available to the public, either for free or for a not-too-unreasonable fee, that runs the risk of the people making the code changes having to make guesses.)

[guyharris]

You might want to first make a pull request for the link-layer header types page in the tcpdump.org Web site GitHub repository. See the instructions on how to make such an update.

[guyharris]

Or, rather, make two separate pull requests for the link-layer header types page, one for LINKTYPE_MCTP and one for LINKTYPE_PCI_DOE; there's no reason to tie the two together, as each one can be added without the other.

[mcr]

(And note that either tcpdump or Wireshark code to dissect them are subject to changes due to either tcpdump or Wireshark dissector programming interface changes; absent a spec that's available to the public, either for free or for a not-too-unreasonable fee, that runs the risk of the people making the code changes having to make guesses.)

tcpdump mostly does not seem to gain new L2 dissectors very often, which is arguably a bug.
wireshark does.
It would be good to have the above sentence as a policy on the wireshark web site.
Myself, I would just drop dissectors when APIs change that don't have accessible specifications :-)