Re: asking for a new link-layer header type value

[Guy Harris <guy () alum mit edu>]

On Jul 20, 2011, at 9:36 AM, Guy Harris wrote:

> The pcap file header is of a fixed length, and if you add a new field without, in effect, defining a new pcap format 
> with a new magic number, you will end up with files that cannot be read by *any* programs that know the old format, 
> such as tcpdump, Kismet, Wireshark, and so on.

I.e. i.e., if you want it in the *file* header, that's not a new link-layer header type.  In addition to all the 
problems I described in my previous message, that would also mean that you'd have only one drop count, once the capture 
was done, *and* it'd require that the program writing the capture seek backwards and update the header when the capture 
is done, which would mean that it wouldn't work if, for example, tcpdump were writing a dump file to the standard 
output ("-w -") and were piping to another program.

If this were done with new link-layer header type values, it would require new link-layer header type values for each 
link-layer type for which you'd want that count, *and* it would have all the problems I described that you'd have using 
pcap-ng's built-in capability for this:

> pcap-ng format has the ability to store that, although, unfortunately, I don't think any of the underlying capture 
> mechanisms libpcap supports supply packet-drop counts along with the packets, so
>
>       1) that would require an extra system call, to get the drop counts, for every group of packets that's read;
>
>       2) that system call is done after packets are queued up to be read by libpcap, so the value it would get if 
> libpcap were to make it when processing a packet won't necessarily reflect the number of packets dropped by the 
> kernel when the packet it's processing had arrived;
>
> so there would be a performance hit and it wouldn't give you an accurate value in any case.  Fixing that would 
> require a change to Linux's PF_PACKET socket code, *BSD's and Mac OS X's BPF code, and so on.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.