Re: [tcpdump-workers] pcap_loop() not returning after pcap_breakloop()

2006-06-27 Thread Fabian Schneider

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.


Re: [tcpdump-workers] pcap_loop() not returning after pcap_breakloop()

2006-06-27 Thread Guy Harris

Fabian Schneider wrote:

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.


Really?  I think you have it backwards; see below.

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.


Yes, I know - I wrote that section, and did so to discourage people from 
thinking the timer is guaranteed to


1) exist

and

2) be started when you do a read.

The timer first appeared in BPF (so it *IS* interpreted by the BSDs; I 
think you have it backwards above).  It's used to do batching of 
packets, so that one read() call can deliver multiple packets, reducing 
CPU overhead; the timer is there to keep the read() from waiting forever 
for enough packets to arrive.


For some unknown reason, the BPF timer is started at the time you do a 
read, rather than when the first packet arrives.  That can lead people 
to believe that the timer guarantees that a call such as 
pcap_dispatch(), pcap_next(), or pcap_next_ex() will block for no longer 
than the specified timeout period.


The timing mechanism in Solaris's bufmod is similar - but the timer 
starts when the first packet arrives; that means there is *NO* maximum 
amount of time that pcap_dispatch(), pcap_next(), or pcap_next_ex() will 
block - if no packets arrive, they'll stay blocked.


Linux PF_PACKET sockets have no buffering or timeout mechanism.


 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.


If the application is shutting down, the threads will be terminating 
anyway; I think that was the case the person who asked about this was 
talking about.


The *ideal* would be if all packet capture mechanisms had a way in which 
some OS call could cause a blocking read/recvfrom/whatever to terminate 
prematurely with a call was terminated early indication.


If pcap_breakloop() is called in a signal handler, and the signal in 
question isn't set up to restart system calls, that should let the loop 
terminate cleanly.  If it's not called in a signal handler, i.e. if 
there's no signal that was delivered to the process, that won't help.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] pcap_loop() not returning after pcap_breakloop()

2006-06-27 Thread Richard Hansen
 If pcap_breakloop() is called in a signal handler, and the signal in 
 question isn't set up to restart system calls, that should 
 let the loop terminate cleanly.  If it's not called in a signal 
 handler, i.e. if there's no signal that was delivered to the process, 
 that won't help.

Can I send a signal myself to get it to terminate cleanly?  If so, is there a 
good reference for how to do this?  (Sorry, I'm new to C and *nix programming 
and I don't know much about signals.)

Thanks,
Richard


-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] pcap_loop() not returning after pcap_breakloop() until another packet arrives

2006-06-26 Thread Guy Harris


On Jun 24, 2006, at 10:50 PM, Richard Hansen wrote:

I have one thread that sits in pcap_loop() and another thread that  
calls pcap_breakloop() when it is time to shut down.  My code works  
well on Windows (WinPcap 3.1).


Well, sort of.  I suspect that pcap_breakloop() doesn't *immediately*  
break you out of the loop - it's probably delayed until a packet  
arrives *or* the timeout expires.


  On Linux (libpcap 0.9.4, kernel 2.6.16) the pcap_loop() doesn't  
return after calling pcap_breakloop() until another packet  
arrives.  Is this expected or proper behavior?


Expected, yes.  Linux's packet capture mechanism doesn't have the  
timeouts that the WinPcap driver, BPF, etc. do.


  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).

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.