Re: Setting the Buffer Size Without Restarting the NIC?

[Hei Chan <structurechart () yahoo com>]

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 <guy () alum mit edu> wrote:

On Feb 6, 2014, at 12:19 AM, Hei Chan <structurechart () 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