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

[Yao, Jiewen via tcpdump-workers]

--- Begin Message ---
Hello
Any response ?

Thank you
Yao Jiewen

From: Yao, Jiewen 
Sent: Thursday, December 17, 2020 12:10 PM
To: tcpdump-workers@lists.tcpdump.org
Cc: Yao, Jiewen 
Subject: Request to add MCTP and PCI_DOE to PCAP link type

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

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
> (The existence of libtool is an indication that shared libraries have
> gotten messy on UN*X.)

> Perhaps for this particular case the right thing to do is to set
> LD_LIBRARY_PATH when running the temporarily-installed tcpdump.

Effectively, this is what libtool tries to do.
I would rather just be explicit about it somehow.

Maybe that goes into how we use "make check", but I'm not sure where else it 
matters.

--
]   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] libpcap detection and linking in tcpdump

[Guy Harris via tcpdump-workers]

--- Begin Message ---
On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers 
 wrote:

> I'll try experimenting with one of my Ubuntu VMs.

Welcome to Shared Library Search Hell.

Most UN*Xes have a notion of RPATH (with, of course, different compiler 
command-line flags to set it).

pcap-config provides one if the shared library isn't going to be installed in 
/usr/lib.

The pkg-config file doesn't provide one, however, and some searching indicates 
that the pkg-config maintainers recommend *against* doing so.  They recommend 
using libtool when linking, instead.  Part of the problem here may be that 
setting the RPATH in an executable affects how it searches for *all* libraries, 
so it could affect which version of an unrelated library is found.

(The existence of libtool is an indication that shared libraries have gotten 
messy on UN*X.)

Perhaps for this particular case the right thing to do is to set 
LD_LIBRARY_PATH when running the temporarily-installed tcpdump.

The macOS linker appears to put absolute paths for shared libraries into the 
executable by default:

$ otool -L /bin/cat
/bin/cat:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 1281.100.1)

so this may not be an issue there.

(Also, the existence of the term "DLL hell" is an indication that shared 
libraries have gotten messy on Windows, but I digress :-))--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
>> $ /tmp/libpcap/bin/pcap-config --libs -L/tmp/libpcap/lib
>> -Wl,-rpath,/tmp/libpcap/lib -lpcap

> So that *should* cause /tmp/libpcap/lib to be added to the executable's
> path, which *should* cause it to look in /tmp/libpcap/lib for shared
> libraries.

I have never seen this work since the move from SunOS-style
shared-library/AOUT to ELF twenty years ago.
-R/tmp/libpcap/lib is what I used to do, but AFAIK, this is equally a no-op.

> I'll try experimenting with one of my Ubuntu VMs.

> In the meantime, for some fun head-exploding reading, take a look at
>   https://en.wikipedia.org/wiki/Rpath
> and perhaps some other documents found by a search for

Yeah... I don't even know what to say.

--
]   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] Any way to filter ether address when type is LINUX_SLL?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
> I've been thinking about a world in which we have more pcapng-style
> APIs.  With a capture API that can deliver, for each packet, something
> similar to a pcapng Enhanced Packet Block, with an interface number
> from the capturing program can determine a link-layer header type, so
> that not all captured packet have to have the same link-layer header
> type, it might be possible to generate a filter program that:

I like this as an idea for an API.

>   could use one of the SKF_ magic offsets to fetch the "next protocol
> type" value for the protocol after the link-layer protocol, so
> link-layer-type-independent code could be used to check for common
> "next protocol type" values such as IPv4, IPv6, and ARP;

>   could use one of the SKF_ magic offsets to fetch the offset, relative
> to the beginning of the raw packet data, of the first byte past the
> link-layer header, so that link-layer-type-independent code could be
> used to check for anything at the next protocol layer (IP address,
> etc.);

That would be very nice.
The kernel already has done all the L2 processing, might as well leverage it.

>   could use one of the SKF_ magic offsets to fetch the ARPHRD_ type
> giving the link-layer header type, and, based on that run different
> code to check fields in the link-layer header.

> This would be done by using a raw socket (PF_PACKET/SOCK_RAW) rather
> than a cooked socket.

> With all of that, we could do live-capture filtering of MAC addresses
> (source *or* destination).

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