While investigating "strange behavior of using pcap.h", I ran across another bit of strange behavior --- pcap_next (and 
also pcap_next_ex) frequently returns immediately with a timeout indication.

The code in pcap_read_bpf (in pcap-bpf.c) expects the byte count returned by BPF to be word aligned, but BPF inserts the
 alignment space BEFORE it adds a packet to the buffer, not AFTER it adds the packet.  So the end of the buffer may not 
be word aligned.  There are two tests in pcap_read_bpf to check for more data in the buffer: one of them, "if (p->cc == 
0) {"  tests a counter that gets decremented by the word aligned length of each packet --- a counter that will go 
negative at the end of the buffer three out of four times on random length data; the other test, "while (bp < ep) {" 
tests that the packet pointer hasn't been incremented past the end of the data.  So, whenever the byte count from BPF is
 not word aligned, after the last packet is read from the buffer, the next call to pcap_next finds the counter negative,
 and since the test is for exactly zero, another read is NOT started, and the code goes on to loop through the packet; 
but the pointer test correctly determines that there are no more packets in the buffer, and returns no data, indicating 
a timeout.

There are several ways to correct this "problem", and the selection may be based more on politics than on technical 
issues.  I would judge pcap_read_bpf, with its two different tests for the same condition, to be broken: a quick fix 
would be to change the p->cc == 0 test to p->cc <= 0.  But I suppose others might argue that BPF should always return a 
word aligned value, and that should work too.

In any case, it's hard to imagine these false timeouts causing a serious problem in any application, but still, it's 
just not quite right.

Murf