Hi, Thanks for your reply.
I forgot to mention my OS -- CentOS 6.5. Now, I look at the word "activated", and I am a bit confused. Does it refer to a device that is enabled in the OS? Or does it refer to a device that is "activated" by pcap_*() such that even a device is enabled in the OS but could be "not activated" before those pcap_*() calls? Thanks in advance. On Thursday, February 6, 2014 6:24 PM, Guy Harris <g...@alum.mit.edu> wrote: On Feb 6, 2014, at 12:19 AM, Hei Chan <structurech...@yahoo.com> wrote: > When I call pcap_set_buffer_size() on an actively using/running NIC, it gives > me an error: > can't perform operation on activated capture > > Is there a way to change the pcap capture buffer size without deactivating it? On at least some platforms, no, there isn't - other than having libpcap close the device and reopen it. > How does this buffer different from SO_RCVBUF? Well, on the machine on which I'm typing this: $ uname -sr Darwin 12.5.0 (better known as $ sw_vers ProductName: Mac OS X ProductVersion: 10.8.5 BuildVersion: 12F45 ) it's different because it's not a socket buffer because it's not a buffer for a socket, and it's set with BIOCSBLEN. That's also true on all current OSes that have the letters "B", "S", and "D" at the end of the name, as well as Solaris 11. (Translation: not all the world is Linux.) And, even on Linux, with sufficiently-modern versions of libpcap (going back to 1.0) and sufficiently modern kernels (going back at least to 2.6.0, I think) it's typically set with a pile of calls that set up a memory-mapped buffer that cannot simply be resized on the fly - you'd have to destroy the buffer and re-create it (and lose packets as a result). > It seems like SO_RCVBUF doesn't matter in this context anymore because > libpcap goes through a different route in receiving packets? Yes, as per the above. The only platforms on which it's a normal socket are 1) Linux if libpcap is so old that it doesn't support memory-mapped captures or the kernel is so old that it doesn't offer memory-mapped captures; 2) IRIX; 3) SunOS 3.x (assuming the code hasn't suffered so much from code rot that it no longer works at all on 3.x); 4) some specialized devices on Linux. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
