You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Ethernet, the physical layer only encodes the beginning and end of frames, all of the details about the frame can be determined from looking at data within the frame itself. However, other protocols do not necessarily work like this. For example, PCIe has both transaction layer packets and link layer packets, and they are differentiated by using different start control characters at the physical layer. Additionally, different encodings are used depending on the link speed (gen 1/2 vs gen 3 use totally different methods for framing). Technically, the framing method is not part of the link layer or transaction layer frame and as such it doesn't really make sense to capture this in the pcap, similar to how the preamble and start/terminate control characters are not captured alongside Ethernet frames.
What is the best way to handle this in the pcap format? Perhaps via some sort of per-packet option in the enhanced packet block? Or should the link layer framing information be included in the pcap, perhaps translated to the "lowest common denominator?"
The text was updated successfully, but these errors were encountered:
Alex Forencich ***@***.***> wrote:
What is the best way to handle this in the pcap format? Perhaps via
some sort of per-packet option in the enhanced packet block? Or should
the link layer framing information be included in the pcap, perhaps
translated to the "lowest common denominator?"
Either you create a meta-link-layer header and you include information in it,
such as the PCIe transaction layer framing information, or you allocate
multiple link-layer headers.
In general, you'd want to do this with PCAP(NG), not PCAP.
For Ethernet, the physical layer only encodes the beginning and end of frames, all of the details about the frame can be determined from looking at data within the frame itself. However, other protocols do not necessarily work like this. For example, PCIe has both transaction layer packets and link layer packets, and they are differentiated by using different start control characters at the physical layer. Additionally, different encodings are used depending on the link speed (gen 1/2 vs gen 3 use totally different methods for framing). Technically, the framing method is not part of the link layer or transaction layer frame and as such it doesn't really make sense to capture this in the pcap, similar to how the preamble and start/terminate control characters are not captured alongside Ethernet frames.
What is the best way to handle this in the pcap format? Perhaps via some sort of per-packet option in the enhanced packet block? Or should the link layer framing information be included in the pcap, perhaps translated to the "lowest common denominator?"
The text was updated successfully, but these errors were encountered: