rupesh gautam wrote:
why changing buffer size is unimplementable on systems with bpf.
It's not *completely* unimplementable.
It can, however, not be done after the BPF device has been bound to a network interface, which means that it cannot be done after "pcap_open_live()".
I don't know why the buffers are allocated at attach time and why they reject attempts to change the buffer size after that rather than, in effect, temporarily detaching the interface from the device (so that no packets are transferred into the buffer that's being freed), freeing the old buffers, allocating new buffers, and reattaching the interface (the detaching and reattaching could be done by setting a "reallocation in progress" flag and ignoring BPF tap calls if the flag is set), other than perhaps because it was simpler to do so and because code can set the buffer size before binding (even though libpcap doesn't support that).
Why libpcap doesn't support that is another matter. LBL's libpcap tried setting it to 32K, but it did have an XXX comment "this should be a user-accessible hook", so they apparently thought it should.
and does packet drop depends upon packet filter??-
A packet filter will discard packets before putting them into the buffer, so if you have a packet filter, it might reduce the number of packet drops by discarding packets deemed uninteresting before they get put into the buffer.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
