On Jan 27, 2009, at 9:17 AM, Benoit wrote:
I've start a simple protocol to communicate with FPGA using only MAC
layer.
This software should run under linux and windows, however i've a
problem
with the timeout of pcap_next_ex() function under linux.
There is no guarantee that, with a timeout value of N milliseconds,
pcap_next_ex() will return within N milliseconds. It might *never*
return if no packets arrive.
The only *guarantee* that libpcap/WinPcap offers is that it will
return within N milliseconds of the arrival of a packet. On some
platforms , the timer starts when pcap_next() or pcap_next_ex() or
pcap_dispatch() or pcap_loop() is called. On other platforms, the
timer starts when the first packet arrives. On other platforms, there
isn't any timer.
The timeout is *NOT* intended to be used to make sure you don't block
forever waiting for a packet. The timeout is intended to be used so
that, on platforms where the underlying packet capture mechanism will
wait some amount of time to try to deliver multiple packets in one
read, rather than waking up the process for every packet (to reduce
the number of wakeups and user->kernel and kernel->user transitions),
it won't wait forever if at least one packet has arrived.
If you want a timeout, so you don't wait forever for a packet to
arrived, I'd suggest using select() or poll() on UN*X systems (other
than *BSD and Mac OS X, where select() and poll() might not work
correctly on BPF devices - and, in the case of Mac OS X, where poll()
doesn't work *at all* on "character" devices such as BPF devices or
ttys).
Moreover sometimes I need to loop 10 times to be sure to receive
correctly the packet,
Why? Does pcap_next_ex() return 0 or a negative value?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.