Re: Setting the Buffer Size Without Restarting the NIC?

[Michal Sekletar <msekleta () redhat com>]

On Thu, Feb 06, 2014 at 02:36:10AM -0800, Hei Chan wrote:
> 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?
Hi,

Activated refers to pcap_t handle. Before you can do capture on the device
you have to have handle and after that capture parameters are set and finally
handle is marked as activated. So it doesn't refer to status of the device in
OS.

> Thanks in advance.

Cheers,

Michal
> 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
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers