Gregor Maier wrote:
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).
I.e., it'll support Ethernet both with and without the ERF header?
I've added DLT_ERF_ETH with the value 175 and DLT_ERF_POS with the value 176 (I assume that's "Packet-over-SONET", not, for example, some other expansion of the abbreviation "POS" - did whoever first started calling Packet-over-SONET "POS" know that "POS" stood for something else, at least in some countries, before Packet-over-SONET was devised? :-)).
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?
No, they could be added later if they ever are needed. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
