Re: timeouts within pcap_open_live() a rare privilege? :)

[Guy Harris <guy () netapp com>]

On Thu, Oct 31, 2002 at 04:57:37AM -0800, Radu Negut wrote:
> Is there a list of platforms which support the
> pcap_open_live() timeout parameter?

There can be multiple lists, depending on what you mean by "support".

If by "support" you mean "uses the value to set a timeout of some sort",
the answer is

        BSD

        Digital UNIX

        Windows with WinPcap

        SunOS (3.x, 4.x, and 5.x)

If, however, by "support" you mean "uses the value to set a timeout such
that, when the timeout expires, 'pcap_dispatch()' returns regardless of
whether any packets arrived during that time", the answer is, I think,

        BSD

        Digital UNIX

        Windows with WinPcap

I.e., SunOS 5.x *does* have a timeout, which allows you to request that
packets not be delivered immediately, but be "batched up" with the batch
released when it's full or when the timeout expires (just as the BSD
and Windows/WinPcap and possibly Digital UNIX timeouts do).

However, if the batch is empty, 5.x keeps waiting - it does *not*
deliver the batch.

I suspect that may have been the case with 3.x's NIT and 4.x's STREAMS
NIT, but I don't know for certain; if so, then the list is correct,
otherwise, the list gets "SunOS (3.x and 4.x)" added to it, but most
machines these days are probably running some version of 5.x, so....

> I believe mine
> isn't on such a list , so my question is what can be
> done about it?

The first question should be "what *needs* to be done about it?"

Some applications, e.g. tcpdump, don't care, as they're just looping and
capturing.

Applications that are interactive and allow the user to supply input
while capturing packets can, for example:

        on UNIX, take the file descriptor returned by "pcap_fileno()"
        and use it in the "select()" or "poll()" in the application's
        main loop (modulo some BSD issues which I'll describe later) -
        e.g., supply the descriptor to a GUI toolkit as something to
        poll in the main loop;

        on Windows, take the handle returned by "pcap_getevent()" and
        use it in the main loop.

There may be other alternatives for other applications; what alternative
is right for your application depends on why your application needs to
do something other than read packets and process them.

(The BSD issue is that "select()" and "poll()" don't work on BPF devices
except in recent versions of some BSDs.  A workaround that probably
works on most BSDs - although I suspect it won't work on FreeBSD 4.5;
the workaround isn't necessary on 4.6 - is to:

        put the file descriptor into non-blocking mode (preferably using
        the "pcap_setnonblock()" API in libpcap 0.7 and later; if the
        version of libpcap with which you're building lacks that API,
        just do the same "fcntl()" stuff that "pcap_setnonblock()"
        does);

        supply the timeout as the timeout argument to "select()" or
        "poll()";

        attempt to read stuff from the "pcap_t" regardless of whether
        "select()" or "poll()" says you can read it or not.

GUI tookits typically have their own mechanism for adding timeout
callbacks to the main loop.)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe