Date: Sat, 21 May 2005 12:56:49 -0400 From: Charles Swiger <cswiger@mac.com> To: Daniel Valencia <fetrovsky@yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: sending MAC packets --- again, and again Message-ID: <1e68f176b1351a2d8e697ee599ca2c2f@mac.com> In-Reply-To: <20050521162738.29477.qmail@web53905.mail.yahoo.com> References: <20050521162738.29477.qmail@web53905.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 21, 2005, at 12:27 PM, Daniel Valencia wrote:
> [ ...pcap reading code stalling... ]
>
> Is this normal pcap behaviour, or is it some
> FreeBSD-specific behaviour, or is it just me?
It's unfortunately normal. You're running into this (from "man pcap"):
NOTE: when reading a live capture, pcap_dispatch() will not
necessarily
return when the read times out; on some platforms, the read
timeout
isn't supported, and, on other platforms, the timer doesn't
start until
at least one packet arrives. This means that the read timeout
should
NOT be used in, for example, an interactive application, to
allow the
packet capture loop to ``poll'' for user input periodically, as
there's
no guarantee that pcap_dispatch() will return after the
timeout
expires.
You can help prompt the pcap timeout to work better by *sending* a
packet just before you try to sniff packets. However, in the end
you'll probably find yourself either going multithreaded or using
alarm() and a signal handler to periodicly wake the program up to pay
attention to other things if the pcap sniffing goes into long
hibernation. Or maybe both. :-)
But then, the standard calls for getting hostnames (getaddrinfo,
gethostbyname) block, too, so you maybe you'll throw DNS lookup code
into another thread anyway, or else end up crafting your own DNS
resolver code since you're already sniffing the packets....
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e68f176b1351a2d8e697ee599ca2c2f>