Guy Harris wrote: > > On Feb 2, 2005, at 6:01 PM, Gregor Maier wrote: > >> We'd like to get two DLTs, namely DLT_ERF_ETH and DLT_ERF_POS. The DAG >> range of network monitoring cards prepend an additional ERF header (see >> http://www.endace.com/support/EndaceRecordFormat.pdf for further >> information) to the actual link layer data, so we would need these new >> DLTs for correct filtercode generation and for printing in tcpdump. > > > So would a packet in a file with those DLTs have both the standard > libpcap "struct timeval" time stamp and the ERF time stamp, and have > both the standard libpcap captured and real length values and the > rlen/wlen values? yes it would. It's a bit superfluous (although ERF timestamps are more accurate) but the main reason we need the DLTs is to get the correct offsets (off_nl, off_mac, etc.) in gencode.c. At the moment these cards use the "native" DLTs of the interface and filtering is done using bpf_filter() by ommitting/replacing the ERF-header with a pcap_pkthdr but we are working on a BPF implementation in hardware and we can't the ommit the ERF-header there (at least not in an efficient way).
It is planned that in the "final version" the cards will have two DLTs (for ethernet: EN10MB and ERF_ETH). > And should there be DLT_ values for TYPE_ATM, TYPE_AAL5, or any of the > other types? Not in the foreseeable future, since only the cards for eth and pos currently have the resources for bpf filtering in hardware. Traces for the other will continue to use the ommiting/replacing method. Or do you think it would be a good idea to add these types too, to keep it more consitent? cu Gregor -- Gregor Maier [EMAIL PROTECTED] Endace Technology Ltd., 12 Knox Street, Hamilton, New Zealand - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
