hi,
>You never were able to specify a timeout in libpcap; the so-called "read
>timeout" in libpcap has never been guaranteed to be a timeout (except
>perhaps when libpcap ran only with BPF, but I suspect that, back then,
>there *was* no libpcap, that code was just part of tcpdump).
Ouch. :)
I just trusted the manpage. Anyway. When it breaks
on other UNIXes too, it's ok.
I guess any UNIX can use timeout via select() b/c they support
BSD sockets.
On the other hand it might be better to let the application
handle this if they have to multiplex inputs anyway.
>So any application that uses the timeout as a way of being sure it can
>periodically poll for user input is broken. For example, I just changed
Sure it is, but there is other usage of timeout.
Using pcap_next() before ensured (at least on linux as I learned now:)
that it returns after a given timeout, making possible to say
"there was no such packet" to the user.
How do I handle this now?
Obtaining the fd via fileno() and doing select(), then upon return
calling pcap_next()?
>> Thus, checking for EAGAIN error is useless as well.
>
>Not true. The file descriptor could be put into non-blocking mode by
>the application; that's what the version of Ethereal that uses the GTK+
>main loop's "poll()" does.
Well, it's not good idea to mess with data that one doesn't own,
i.e. setting fd's to nonblocking mode from within application.
But I see, ideas are driven by already existing applications.
>From this point it makes sense.
bye,
Sebastian
-=[ cc -Dw=write x.c -- 172 bytes, 1 line ]=-
char s[]="char
s[]=;main(){w(1,s,9);*s=34;w(1,s,1);*s=99;w(1,s,85);*s=34;w(1,s,1);w(1,s+9,76);}";main(){w(1,s,9);*s=34;w(1,s,1);*s=99;w(1,s,85);*s=34;w(1,s,1);w(1,s+9,76);}
-=[ http://www.cs.uni-potsdam.de/homepages/students/linuxer ]=-
-
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
