On Apr 7, 2013, at 3:25 PM, wen lui wrote:
> 1 I don't know how pcap handler works, my understanding is: when
> pcap_open_live() function is called and the filter is set, it will capture
> all matching packets and put them in a FIFO queue somewhere. Then, each
> time I call pcap_next(), the packet in the head of the FIFO queue is
> fetched. Is it correct or not?
It's basically correct. pcap_open_live() starts the capture process, and
setting the filter changes the filter used by the capture process (discarding
some not-yet-read packets); the packets that arrive are put into a FIFO buffer
(there might be separate OS-level buffers and libpcap-level buffers, but the
overall effect is that of a FIFO buffer). pcap_next() will extract the oldest
packet from the buffer.
> 2 how is the granularity of the packet?if there are IP fragmentation, are
> they IP packets or TCP/UDP packets?
They're *probably* link-layer packets, so, if there's IP fragmentation, each
fragment will be a separate packet.
However, if the network adapter is doing IP reassembly or TCP reassembly, you
might get a packet that looks like a link-layer packet but is really a "fake"
link-layer packet with a fully-reassembled IP datagram or with multiple TCP
segments, so that multiple link-layer packets are combined into one packet.
> how to get only 4-th layer packets?
By using something other than libpcap or the mechanism it uses, or by doing
whatever reassembly is involved by yourself. There's no way to do that in
libpcap unless your adapter happens to do it for you.
> 3 when there are incoming TCP connections, for each connection I want to
> capture the final ACK packet and the following data packets and FIN/ACK
> packets, which are all with ACK flag set to 1 , so the filter_exp is
> something like "port 54000 and tcp[tcpflags] & (tcp-ack) != 0"
>
> the problems is, when in the child process, will the pcap handler still
> work?
On *most* platforms, it should work in the child process; do *NOT*, however, do
anything with the pcap_t in the parent process until the child process has
exited, and don't use monitor mode on a Wi-Fi device if you're going to do any
forking.
I'm not sure whether it'll work on Linux if the memory-mapped capture mechanism
is being used; the memory-mapped capture mechanism will be used on current
versions of Linux. I *think* it should work, as the region is mapped
MAP_SHARED and hasn't been flagged as MADV_DONTFORK. Again, once the child
process has been forked, don't do *anything* in the parent process.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
