Some time ago it was felt that it would be a good idea to extend the file format used by libpcap with a number of different opinions on what extra was needed. From memory, the very least, in terms of additions desired was: a) interface name b) packet going in or out Other information which there was a need felt for was: c) size of a secondary header following each pcap_pkghdr d) offset pointer to some external storage It would seem to me that (d) could be accomodated by (c). The general thrust of implementing (c) is to do away with any special code required in savefile.c to support alternate formats. On the kernel side of this, an application needs to be sure that it can receive and write out a file of records all in the same format. For this to occur, applications like tcpdump need to pass a magic number into the kernel which acts as a filter of sorts, only passing back internal records which match. The requirement for this is that all access to BPF is via /dev/bpf# - a single interface - whereas from the kernel side you may have any number of formats being generated. The alternative to this is to use the DLT types to specify the format of the data. My problem with this is that the DLT types impact on how filtering is done, which may not be ideal in all cases. For example, if three different sources of ethernet packets in the kernel each use a different DLT type, then the BPF code to compare them needs to be know that all three are equivalent rather than just three sources of DLT_ETHER plus some other association of data. In my mind, the changes that would ensure would be grounds for moving the major number of the pcap version to 3, minor 0. I think it's about time something concrete was done about this before we go too much further and find people doing lots of different things in ways which are better supported by the above. Comments ? Darren - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
