Re: [tcpdump-workers] bpf/pcap performance

2004-04-14 Thread Guy Harris
(Noise inserted in the hopes that that the mailing list software doesn't think that this is a duplicate of my previous message, which I sent from my sonic.net address and which thus didn't get through, and thus prevent it from getting to the list.) On Wed, Apr 14, 2004 at 12:30:45PM +1000, Darren

Re: [tcpdump-workers] bpf/pcap performance

2004-04-13 Thread Darren Reed
In some email I received from Guy Harris, sie wrote: 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

Re: [tcpdump-workers] bpf/pcap performance

2004-04-12 Thread Michael Richardson
Darren == Darren Reed [EMAIL PROTECTED] writes: Darren In some email I received from Guy Harris, sie wrote: On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote: And there's also BPF_MAXBUFFERSIZE. I see pcap_getbuff() as being essential to getting code to work

Re: [tcpdump-workers] bpf/pcap performance

2004-04-12 Thread Guy Harris
On Apr 12, 2004, at 5:07 PM, Guy Harris wrote: ...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