Re: Directly accessing packet buffer

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

On Mar 28, 2011, at 11:18 PM, Rayne wrote:

> I would like to be able to directly access the buffer where packets are stored when they're received. After some 
> googling, I think perhaps libpcap with mmap would be the solution. Does libpcap 1.0 and above support mmap?

Libpcap 1.0 and above support, on those OSes where the underlying packet capture mechanism supports memory mapping 
(versions of the Linux kernel with the "turbopacket" mechanism, and FreeBSD 8.x and later), the memory-mapped capture 
mechanisms.

Libpcap does not, however, use mmap when reading a capture file ("savefile").

> From my understanding, mmap would allow me to directly access the buffer without having to explicitly copy the packet 
> to another buffer for me to do processing. I would also appreciate it if someone can let me know where I can find 
> examples of such applications, as many examples of mmap I've found involves mapping a buffer for file operations, 
> rather than integrating it with pcap functions like pcap_loop, pcap_next_ex etc.

If you are running on a platform with a memory-mapped capture mechanism, and are using libpcap 1.0 or later, then, if 
you use pcap_loop() or pcap_dispatch(), your callback routine will be called with the packet data pointer argument 
pointing into the memory-mapped buffer.

If, however, you use pcap_next() or pcap_next_ex() on Linux, you will be handed a pointer to a buffer into which the 
packet was copied from the memory-mapped buffer.  If they were to hand you a pointer into the memory-mapped buffer, 
that slot in the memory-mapped buffer could not be released until your code was done with the packet - and the only way 
to indicate that you're done with the packet is to call pcap_next() or pcap_next_ex() again.  Using that as the 
"release the packet" indication was (for reasons I don't remember, but I could reconstruct if necessary) not really 
acceptable, and releasing the packet *before* you read the next packet means that the packet data could be overwritten 
while you're processing it.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.