On 5/05/11 11:35 AM, Guy Harris wrote:
On May 5, 2011, at 11:28 AM, Darren Reed wrote:
I see - you're concerned about how do you make "tcpdump icmp" work when the
link type is PPI (or pcap-ng)
Presumably meaning "when the link type is PPI or when the file is a pcap-ng
file" (pcap-ng isn't a link type, it's a file format).
and the contents of the file could be a mixture of ethernet, Infiniband and
others. The problem being that the location of the IP header is different in
each, requiring a different program to be generated and applied.
The location of the IP header *and* the location and values of the type field
in the link-layer header are different.
In terms of pcap, I'm becoming more and more of the opinion that DLT_PPI
should not be used for anything other than DLT_IEEE802_11.
The reason being is that it increases the complexity of generating BPF
far in excess of its worth to try and handle the "special case" of
"length == 0" along with the current use of DLT_PPI.
Whilst this may actually serve the purposes of the file format and
printing packets, in terms of a solution for filtering packets of varied
data link types, it just doesn't work.
In terms of pcap, I'd thus like to suggest that we add a DLT_LINK that
has a header like this:
version=0 (8 bits)
reserved=0 (8 bits)
dlt_hdr_len (16 bits)
SAP (32 bits)
DLT (32 bits)
The dlt_hdr_len is the length of the ethernet header or the 802.11
header or the infiniband header or...
The value of the SAP has meaning only for a specific value of the DLT.
Whilst some DLTs may use the same set of values for the SAP field, this
is not guaranteed.
There's no length field because the pcap header already contains the length
For example, an ethernet packet might have SAP=0x0800 (ETHERTYPE_IP) and
DLT=0x1 (DLT_EN10MB)
Why am I not very interested in pcap-ng?
"The pcapng file format specification is still work in progress, see:"
... moving target.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
