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@xxxxxxxxxxx ("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