Re: pcap_loop() not returning after pcap_breakloop()

[Fabian Schneider <schneifa () net in tum de>]

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: fabian () net in tum de, 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.