Hi, > Expected, yes. Linux's packet capture mechanism doesn't have the timeouts > that the WinPcap driver, BPF, etc. do.
I thought (and i have a programm running with this) that you can use the to_ms value in pcap_open_live() to set such a timeout. The value won't be interpreted by some OS'ses like FreeBSD or if you are using the libpcap-mmap patch, resulting in a normal behaviour. But with Linux everything works. So i set the to_ms value to 100, and everything works fine. The problem with this solution is, that this to_ms parameter is not meant to be used like this (exerpt form the man page:) -------------------------------------------------------- pcap_open_live() ... to_ms specifies the read timeout in milliseconds. The read timeout is used to arrange that the read not necessarily return immediately when a packet is seen, but that it wait for some amount of time to allow more packets to arrive and to read multiple packets from the OS kernel in one operation. Not all platforms support a read timeout; on platforms that don't, the read timeout is ignored. A zero value for to_ms, on platforms that support a read timeout, will cause a read to wait forever to allow enough packets to arrive, with no timeout. ... --------------------------------------------------------- > > How can I tell Linux to return from that readfrom() call that it's > > blocking on? > > You *might* be able to do it with pthread_cancel(), although that will, > ultimately, terminate the thread (unless a cleanup handler never returns). And this sound like a dirty hack, where additional effort is required to perform the normal cleanup at the end. regards Fabian Schneider -- Fabian Schneider, Technische Universität München address: Boltzmannstr. 3, 85748 Garching b. Münchenn e-mail: [EMAIL PROTECTED], WWW: http://www.net.in.tum.de/~schneifa phone: +49 89 289-18012, mobile: 0179/2427671- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.