Add link-layer header type for USB Type-C Power Delivery

[kristinpaget]

I'm doing some work with the USB-PD protocol (as specified by USB-IF) and while there are link types defined for the USB data protocol itself there does not appear to be one for the PD protocol, which is used to put the Type-C port into a variety of alternate modes. Could you please add a LINKTYPE and DLT header type (perhaps LINKTYPE_USB_TYPE_C_PD) to support the Power Delivery protocol. Thanks!

[guyharris]

So from this USB Power Delivery slideshow I infer that the PD protocol runs over the "CC wire", which presumably means the configuration channel pins (CC1 and CC2) on the USB-C connector.

I.e., it runs over different wires from the wires used by the data protocol.

Is that the case?

[kristinpaget]

Yes, that's correct. Type-C has a differential pair for USB2, four high-speed differential pairs (2 pairs per side), plus a CC wire per side that allows you switch the function of the high-speed pairs (for USB3/4, Thunderbolt, HDMI, etc etc). It's part of the USB specs but is a different PHY on separate wires.

[guyharris]

So is there a specification (final or draft) for the PD protocol?

[kristinpaget]

Revision 3.1 version 1.1 is current, the PDF link is at the top right.

[guyharris]

So would the packets correspond to what's in section 6.2 "Messages"?

If so, would the data be just what's at the "Protocol Layer", or does there need to be additional information in a metadata header, such as the type of SOP, and should the CRC be included?

[kristinpaget]

That's a good question and I'm not sure I'm familiar enough with pcap internals to answer it. Some things to consider:

• Section 6.2 is indeed the message payloads, although note that control messages only contain a header and CRC (not unlike a TCP SYN or ACK)
• Section 5.6 show the layering in more detail, while 5.3 explains PD's version of 4b5b coding.
• For my purposes the CRC value and any invalid symbols/framing are quite important; it's entirely possible to see physical-layer errors (since a lot of this is bitbanged by a microcontroller) which I do want to capture. That would imply that everything within the 4b5b coding should be the "data", giving me the SOP / CRC / EOP within the captured frame. The downside of this is that you somewhat lose out on visibility - if you can see the K-codes that make up the SOP / EOP then you're working with individual symbols which only code for half a byte each, and you need some way to represent an invalid symbol.

I believe 4b5b and 8b10b are fairly commonplace, how does pcap handle packets with invalid coding in other protocols? Certainly errors further up in the stack are easy to capture, but how does pcap handle a frame that's invalid at the physical / coding layer?

[guyharris]

That's a good question and I'm not sure I'm familiar enough with pcap internals

There's pcap the library, and there's pcap/pcapng the file formats. The two are connected, but aren't the same.

Link-layer header types are part of the latter; they assign numbers to be used in the header of a pcap file, and in the Interface Description Blocks of a pcapng file, to indicate the format of the packet data in a pcap packet record or a pcapng Enhanced Packet Block/Simple Packet Block/(deprecated) Packet Block.

So this isn't an issue of the internals of a library that runs atop various capture mechanisms to capture packets (pcap the library - libpcap/WinPcap/Npcap), it's an issue of "how should packets of this type be represented as a sequence of octets?"

I believe 4b5b and 8b10b are fairly commonplace, how does pcap handle packets with invalid coding in other protocols?

By and large, both pcap the library and pcap/pcapng the file formats completely ignore the existence of coding schemes such as 4b5b and 8b10b.

LINKTYPEETHERNET, for example, ignores the PHY entirely (the "10MB" in the corresponding DLT name, DLT_EN10MB, is a historical artifact dating back to the Xerox 3Mb Ethernet vs. the 10Mb D/I/X Ethernet - DLT_EN10MB is for all forms of Ethernet other than the original Xerox one).

pcap-the-library's code to capture Ethernet traffic on various platforms uses either standard OS mechanisms (on UN*Xes) or the WinPcap/Npcap NDIS driver (on Windows) and the WinPcap/Npcap packet.dll library that uses that driver. Those mechanisms, in turn, just receive whatever packets the adapter driver provides, which are the packets that the adapter provides. Errors would, at the adapter level, either be ignored or would provide a "I got a bad packet" indication; the latter are not currently supplied to the pcap library.

LINKTYPE_ETHERNET provides no mechanism to report them.

If you want something that doesn't abstract away the PHY, you're going to need to design a format to represent the additional information you need. This might, for example, mean representing the packet as a sequence of 5-bit symbols (leaving it up to the application reading the file to process them.

[kristinpaget]

So this isn't an issue of the internals of a library ... it's an issue of "how should packets of this type be represented as a sequence of octets?"

Agreed. I'm trying to use libpcap with pcap_open_dead to write a pcap file from my own capture hardware, but the limit of that overlap seems to be the link-layer type.

you're going to need to design a format ... representing the packet as a sequence of 5-bit symbols

This is what I'm using already but it's wildly non-portable. One of my goals is to write a full Wireshark dissector for USB-PD, but first I need to get the PD data into a format that Wireshark can read, hence pcap.

It sounds like I will need to handle two file formats since these requirements seem to be mutually exclusive. One low-level format that captures all the 4b5b and other signaling (something like sigrok), and a higher-level format for pcap that can be fed into wireshark et al. That being the case I would expect that the correct encapsulation for pcap files would indeed be a metadata header with SOP type and checksum, and then the (header + optional extended header + optional data bytes) forming the payload of the packet.

[guyharris]

I'm trying to use libpcap with pcap_open_dead to write a pcap file from my own capture hardware

libpcap is designed so that you can add "modules" to support capture mechanisms other than the OS's default mechanism; there's currently no support for "plugin" modules, so you'd have to compile your own version of libpcap, but you could take the code that reads packets from your capture hardware and incorporate it into libpcap, allowing tcpdump/Wireshark/etc. to directly capture traffic. See the doc/README.capture-module file in the source.

It sounds like I will need to handle two file formats since these requirements seem to be mutually exclusive. One low-level format that captures all the 4b5b and other signaling (something like sigrok), and a higher-level format for pcap that can be fed into wireshark et al.

There's no inherent reason why the low-level format couldn't use pcap/pcapng as a container, or why Wireshark wouldn't be able to read it. It'd be somewhat of a pain to write a Wireshark dissector for it, but not impossible.

That being the case I would expect that the correct encapsulation for pcap files would indeed be a metadata header with SOP type and checksum, and then the (header + optional extended header + optional data bytes) forming the payload of the packet.

So come up with a proposal for the metadata header, write a htmlsrc/linktypes/LINKTYPE_USB_TYPE_C_PD.html file describing the pseudo-header, and provide a pull request for the tcpdump.org web site repository that 1) updates linktypes.html to have an entry for LINKTYPE_USB_TYPE_C_PD, using the next currently available linktype number (updated if necessary if other types are added after you make the pull request), and saying something such as "Pseudo-header for USB Type C Power Delivery packets, followed by a Power Delivery packet as specified by section 6.2 "Messages" of the Universal Serial Bus Power Delivery Specification, revision 3.1, version 1.1", with "Pseudo-header for USB Type C Power Delivery packets" linking to linktypes/LINKTYPE_USB_TYPE_C_PD.html , and "the Universal Serial Bus Power Delivery Specification, revision 3.1, version 1.1" linking to, for example, https://www.usb.org/document-library/usb-power-delivery.