Re: Headroom

["Gianluca Varenni" <gianluca.varenni () cacetech com>]

----- Original Message ----- 
From: "Harley Stenzel" <hstenzel () gmail com>
To: <tcpdump-workers () lists tcpdump org>
Sent: Friday, October 06, 2006 12:25 PM
Subject: Re: [tcpdump-workers] Headroom


> On 10/6/06, Gianluca Varenni <gianluca.varenni () cacetech com> wrote:
> > Uhm, what's the purpose of some amount of memory put in front of the 
> > pcap_t
> > structure?
> > Maybe I don't understand your proposal completely...
>
> I don't want the data in front of the pcap_t structure, I want it in
> front of the body of the packet that libpcap gives to a calling
> application.
>
> I maintain a libpcap stack application.  We may perform some action on
> a packet that we receive, and that action may require prepending data
> or additional protocol headers.
>
> Presently, in order to prepend, I have to copy the packet to a larger
> buffer.  I would prefer to not have to copy all the data from every
> packet into a new buffer simply so I can prepend 6 to 28 octets,
> depending on the protocols involved
>
> So, to that end, I want a way to tell libpcap to leave some amount of
> data unused in the buffer, so I can programatically know that it's
> safe to write to that number of octets  in the contiguous block
> leading the packet.
>
> This does not help at all with the classic protocol analyzer
> operation; it is useful for applications which use libpcap for "stack"
> type operations.  This is why headroom of 0 should be default.

One of the main problems in implementing such feature is that the packet 
that libpcap delivers to you (being it through pcap_next_ex or any other 
API) actually comes from a buffer coming directly from the capturing driver 
and containing a batch of packets. If you need to add such trailing empty 
bytes at the beginning of each packet, you either need to modify the 
capturing driver (e.g. bpf under BSDs, the winpcap driver under windows) to 
add such "padding", or performing another copy of each packet within 
libpcap, which is what you want to avoid.

Maybe a better solution is using something based on chained buffers, like 
mbufs or kbufs (not sure about the exact names...).

hope it helps
GV




> > GV
>
> --Harley
>
> [maybe one of these days I'll use the right source address]
> [so hopefully this will confuse the duplicate message filter]
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe. 

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.