Memory-mapped capture and thinking the packet's still there after a pcap_dispatch()/pcap_loop() callback returns

[Guy Harris <guy () alum mit edu>]

pcap_next() and pcap_next_ex() rely on the packet data pointer handed  
to their pcap_dispatch() callback still pointing to the same packet  
data after the callback returns.

If the packet data is being read into a buffer with read()/getmsg()/ 
recvfrom()/etc., that works.

If, however, the packet data is being fetched from a memory-mapped  
buffer shared with the kernel, so that the pointer points into that  
buffer, it doesn't necessarily work - when the callback returns,  
libpcap might release that entry in the buffer, allowing the kernel to  
reuse it and put new packet data there.

A problem that was probably the result of this was reported in a  
thread titled "Buffer overwrites with pcap_next_ex"; I attempted to  
fix it by, in the Linux memory-mapped capture implementation, not  
releasing the packet until the *next* packet was fetched.

Unfortunately, *that* broke select()/poll(), as reported in a thread  
titled "select() regression in libpcap-devel?"; select() thinks  
there's an unconsumed packet, and always reports that reading a packet  
is available, so I had to back that fix out.

The pcap_next() and pcap_next_ex() problem could be fixed by having  
those routines, when capturing in memory-mapped mode, use a callback  
that copies the packet to a separate buffer and returns a pointer to  
*that* buffer.  This means you do one more copy, but if that bothers  
you, you need to stop using pcap_next()/pcap_next_ex() and just use  
pcap_dispatch()/pcap_loop() and live with having to deal with the  
callback architecture.

Unfortunately, it wouldn't fix any applications that use  
pcap_dispatch()/pcap_loop() and *still* assume that the packet data  
won't be changed until the next packet is read.  I don't know whether  
any such applications exist; given that there is no guarantee that the  
data for packet N is still available after packet N+1 is read (and, in  
fact, there's a good chance that it *isn't* available - a certainty  
when, for example, capturing on Linux in non-memory-mapped mode), I  
*suspect* few applications make that assumption.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.