Re: take over responsibility of the pcap_pkthdr *

[Andrej van der Zee <andrejvanderzee () gmail com>]

Hi,

Thanks for your reply.

> If you mean the callback for pcap_loop() and pcap_dispatch(), that's a question best asked on tcpdump-workers () 
> tcpdump org ("tcpdump-workers" could, in theory, be split into four mailing lists - tcpdump-users, tcpdump-dev, 
> libpcap-users, and libpcap-dev - but it isn't).

Apologies, but confusing indeed ;)


> No.  There is *no* guarantee that either the "struct pcap_pkthdr" pointed to by the second argument to the callback 
> or the pile of raw packet data pointed to by the third argument to the callback is valid after the callback returns; 
> if you want a version of either of those that remains valid after the callback returns, you will have to make a copy 
> of it.

I was afraid of that.

>  (Note that the header or the data might be in a memory-mapped buffer shared between the kernel and userland; if so, 
> the userland code could release it to the kernel as soon as the callback returns, so that userland doesn't hang onto a 
> kernel buffer > resource indefinitely - it's not as if they're necessarily copied into a purely-userland buffer by a 
> read/recvfrom/getmsg/whatever, so that userland could somehow reference-count them.)

Aha memory mapped between kernel and user-space, good. Hopefully I can
write the packets after I copied it to user-space in pcap-format and
load them afterwards in wireshark, for example.

Thanks,
Andrej
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe