Re: bpf/pcap performance

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

On Apr 12, 2004, at 4:43 PM, Darren Reed wrote:

> The problem with pcap_next_ex() is the man page description:
> "reads the next packet and returns a success/failure indication"

Well, it says more than that - it indicates what the values of the 
success/failure indication mean, and says what is supplied through 
"*pkt_header" and "*pkt_data" on success.

> This is the first problem.  I don't really know what it does,
> so how can I use it properly ?

What more information is needed?

> btw, on examining the code for pcap more, I find a disturbing
> name problem: pcap.h (the external interface) documents pcap_pkthdr
> as the structure used in the dump files,

OK, I'll fix the header to note that it's what's supplied to or by 
API's and say nothing about it being what's actually stored in dump 
files.

> except if you look in savefile.c, it uses pcap_sf_pkthdr instead.

I.e., it stores a "pcap_sf_pkthdr", which is what it *should* do.

>  To me, this is around
> the wrong way, at best.  I understand what is trying to be done
> here and that is to make sure the saved file always has the same
> format regardless of what is coming in to the pcap_dump() function.

...or what is supplied by "pcap_{dispatch,loop,next,next_ex}()", i.e. 
regardless of what the sizes of the members of a "struct timeval" are.

> But in my opinion, pcap_dump() should be using pcap_pkthdr to store
> things going out

...which would require that "pcap_pkthdr" be changed to begin with a 
"struct pcap_timeval".  If it's OK to, on platforms where, for example, 
"ts_sec" is 64 bits, break binary compatibility with applications 
dynamically linked with libpcap, we could do that - but, if not, we 
need both structures.

> Do we have any feeling for whether or not the likes of IBM are open
> to taking changes that enhance BPF whilst maintainng backward
> compatibility ?

The mail archives with the mail in question are at home, but I think 
I've exchanged mail with some IBM person and not seen anything come of 
it.  If they *are* open, the first enhancement I'd like to see would be 
bug fixes for the problems people have reported, e.g. random EFAULTs 
from reads on BPF devices and the failure of timeouts to work as you 
reported ages ago.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.