On Jun 14, 2004, at 7:11 AM, fcarone wrote:
Hello! Im new in programming with libpcap and im using the libpcap0.8.3, and iŽd like to know if the timeout works in linux RH9 kernel 2.4.20.
No, it does not. The timeout is passed on to the underlying OS's packet capture mechanism, if it supports a timeout; Linux's PF_PACKET sockets don't.
It works on Solaris - but *NOT* in the way people might expect it to work; in Solaris, the timer doesn't start until at least one packet is received, it does *NOT* start as soon as you try to read from the descriptor.
The only platforms I know of on which the timer will go off even if *NO* packets have been received are:
the BSDs (including Mac OS X);
AIX, I think, *if* libpcap is using BPF (*NOT* if it's using DLPI);
Digital UNIX, I think;
Windows.
Applications should *NOT* rely on the timeout if they want to keep from waiting forever for a packet to arrive, except on the platforms in question. If they want to, for example, multiplex input from libpcap and some other input source, they should use "select()" or "poll()" on UN*X and "WaitForMultipleEvents()" or "MsgWaitForMultipleEvents()" on Windows.
To get from a "pcap_t *" a descriptor that can be used for "select()" or "poll()", use "pcap_get_selectable_fd()" if the version of libpcap you're using has it, otherwise use "pcap_fileno()".
Note that "pcap_get_selectable_fd()" can return -1 if, for example, "select()" on the "pcap_fileno()" descriptor won't work; it won't work, for example, on some releases of FreeBSD.
Note also that, in some releases of all of the BSDs, "select()" and "poll()" work on it, but not completely correctly. To quote the libpcap 0.8 man page:
Note that on most versions of most BSDs (including Mac OS X) select()
and poll() do not work correctly on BPF devices;
pcap_get_selectable_fd() will return a file descriptor on most of those
versions (the exceptions being FreeBSD 4.3 and 4.4), a simple select()
or poll() will not return even after a timeout specified in
pcap_open_live() expires. To work around this, an application that
uses select() or poll() to wait for packets to arrive must put the
pcap_t in non-blocking mode, and must arrange that the select() or
poll() have a timeout less than or equal to the timeout specified in
pcap_open_live(), and must try to read packets after that timeout
expires, regardless of whether select() or poll() indicated that the
file descriptor for the pcap_t is ready to be read or not. (That
workaround will not work in FreeBSD 4.3 and later; however, in FreeBSD
4.6 and later, select() and poll() work correctly on BPF devices, so
the workaround isn't necessary, although it does no harm.)
On Windows, use "pcap_getevent()" to get a HANDLE that should be usable with "WaitForMultipleEvents()" or "MsgWaitForMultipleEvents()", although note that on older versions of WinPcap (2.3 and before, I think, although this bug might have been fixed in 2.3, I don't remember), it does *not* return a valid HANDLE on Windows NT 4.0/2000/XP/2003 Server. I *think* that works in 3.0, on both Windows 95/98/Me and NT 4.0/2000/XP/2003 Server, but I haven't tested it.
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
