On Thu, Aug 29, 2002 at 12:35:31PM -0700, Aaron Turner wrote: > I've been trying to use both pcap_loop and pcap_dispatch to read packets, > but I'm running into cases where they never return.
Note that there is no guarantee that they *will* ever return; they might block forever waiting for packets to arrive. > I've also tried using > alarm/signal to do a longjmp back into my code to continue. This actually > works the first time, but pcap_read_packet() seems to be blocking the > SIGALRM the second time. It's not blocking the signal; there's no code in there to do that. On some platforms, however, the loop that reads packets ignores EINTR, so that a signal will *not* break out of the loop. I infer from the comment /* Don't choke when we get ptraced */ in "pcap-bpf.c" that the purported reason for this is that you might get an EINTR return as a result of a signal being delivered when a breakpoint is hit. > I know the "obvious" solution is to use the libpcap code in CVS and use > pcap_setnonblock(), but I'm trying to NOT require code that most people > wont have. "pcap_setnonblock()" is in the 0.7.1 release, not just in the CVS tree. With older libpcap releases, you can just use your own substitute "pcap_setnonblock()" routine, that does what the libpcap version does; that will work, except if there's a libpcap that supports a memory-mapped capture mechanism (such as the 2.4 Linux kernel's mechanism) and doesn't implement "pcap_setnonblock()", as setting non-blocking mode on the descriptor won't help there. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
