[tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
I used libpcap function pcap_next() to capture some tcp packets I checked the bytes of the captured packets and notice that the ethernet and ip header of packets are distorted, in a mess with a lot 0's but the TCP header is fine what are potential reasons for this? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Couldn't parse filter scr port 22000: syntax error
Hi, all I used the following filter rules to capture packets, tcpdump -i eth0 src port 22000 it works fine, however, when I used it libpcap functions pcap_compile() and pcap_setfilter() it output an error: Couldn't parse filter scr port 22000: syntax error what is wrong with this? thanks! ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] libpcap: 64bit machine has no compatible 32-bit libpcap library
I want to compile a `.c` file to 32-bit executable using `gcc` option `-m32` with libpcap the machine is linux 64bit fedora 16 however, I get the following error [root@fdf source]# gcc -m32 -o test_tcp test_tcp.c -lpcap /usr/bin/ld: skipping incompatible /usr/lib64/libpcap.so when searching for -lpcap /usr/bin/ld: cannot find -lpcap collect2: ld returned 1 exit status how to solve this problem? thanks! ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] some questions about libpcap , especially with fork() called
I want to use libpcap to capture some packets in my tcp server program
some of the snippets in my program are like:
handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
pcap_setfilter(handle, &fp);
struct pcap_pkthdr pcap_header; // The header that pcap gives
us
const u_char *pcap_packet; // The actual packet
// proxy server listen, waiting for receiver's tcp request
listen(listenfd, 1024);
connfd = accept(listenfd, (struct sockaddr *)&sender_addr,
&sock_len);
pcap_packet = pcap_next(handle, &pcap_header);
pid=fork();
if(pid=0) // child process
{
pcap_packet = pcap_next(handle, &pcap_header);
}
blabla.
listenfd is binding port 3000
my questions are:
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?
2 how is the granularity of the packet?if there are IP fragmentation, are
they IP packets or TCP/UDP packets? how to get only 4-th layer packets?
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? how is the mechanism when there are fork() called?
thanks!
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] some questions about libpcap , especially with fork() called
thanks, I have another question
if I want to capture packets with ACK flag set for EACH INCOMING TCP
connection
so I put accept() in a loop
// proxy server listen, waiting for receiver's tcp request
listen(listenfd, 1024);
while(1) {
connfd = accept(listenfd, (struct sockaddr *)&sender_addr,
&sock_len);
pcap_packet = pcap_next(handle, &pcap_header);
pid=fork();
if(pid=0) // child process
{
pcap_packet = pcap_next(handle, &pcap_header);
}
blabla.
}
in this way, if I put the following code block before accept(), then all
incoming TCP connections may share the same pcap handler
but if I put the following code block in each child process after fork(),
the handler may miss some TCP packets
handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
pcap_setfilter(handle, &fp);
struct pcap_pkthdr pcap_header; // The header that pcap gives
us
const u_char *pcap_packet; // The actual packet
are there any solutions like: just create 1 handler, but split the related
FIFO queue into multip FIFO queues, each of which corresponds to one tcp
connection, and then pcap_next() in each child process just fetch packets
from its corresponding sub-FIFO queue?
or any other solutions?
thanks!
2013/4/8 Guy Harris
>
> 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
[tcpdump-workers] (no subject)
handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
pcap_setfilter(handle, &fp);
struct pcap_pkthdr pcap_header; // The header that pcap gives
us
const u_char *pcap_packet; // The actual packet
while(1){
n=fork();
if(n==0) { // child process
fd_set rdfds;
int pcap_fd = pcap_get_selectable_fd(pcap_handler);
for(;;){
FD_ZERO(&rdfds);
FD_SET(pcap_fd, &rdfds);
FD_SET(sd_proxy, &rdfds); // here is another fd
select(pcap_fd>sd_proxy?pcap_fd+1:sd_proxy+1,
&rdfds, NULL, NULL, NULL)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] parent-child process, selectable file descriptor and pcap
I have a program, part of the source codes are:
handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
pcap_setfilter(handle, &fp);
struct pcap_pkthdr pcap_header; // The header that pcap gives
us
const u_char *pcap_packet; // The actual packet
while(1){
n=fork();
if(n==0) { // child process
fd_set rdfds;
int pcap_fd = pcap_get_selectable_fd(pcap_handler);
for(;;){
FD_ZERO(&rdfds);
FD_SET(pcap_fd, &rdfds);
FD_SET(sd_proxy, &rdfds); // here is another fd
select(pcap_fd>sd_proxy?pcap_fd+1:sd_proxy+1,
&rdfds, NULL, NULL, NULL)
if(FD_ISSET(pcap_fd, &rdfds)) {
pcap_packet = pcap_next(pcap_handler,
&pcap_header);
if(pcap_packet !=NULL)
printf("capture one ACK packet with
length of %d\n", pcap_header.len);
printf("pcap_packet size is %d, length is
%d\n", sizeof(pcap_packet), pcap_header.len);
n = send(sd_proxy,
pcap_packet+ETHERNET_HDR_LEN, pcap_header.len-ETHERNET_HDR_LEN, 0);
if(n<0){
printf("send error: %s\n",
strerror(errno));
goto END;
} //if
//blabla
}//if
}//for
// the child process will always exit the for loop after some
time
close(pcap_fd);
}//if
// parent process
}//while
for the first fork(), I mean for the first child process, it works fine
but for the second and following fork(), I always get "send error: Bad
address"
then I notice that the pcap_header.len is 0
what is the reason for this?
I think the problem may be:
1) there are parent-child process relationship
2) in each child process I used
int pcap_fd = pcap_get_selectable_fd(pcap_handler);
close(pcap_fd);
can anyone give some suggestions on this? thanks!
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] libpcap can't capture IP fragments
I want to capture UDP packets which are destined to a local port, the filtering expression is like udp port 2. I notice if there are IP fragmentation on a UDP packet, libpcap can only capture the first IP fragment. I guess the reason is the second IP fragment are not with UDP header (but with IP header, I think it is the same for TCP), so libpcap can't capture them using the filter express udp port 2. although The second fragment is with IP header but no UDP header. The IP/TCP stack will assembly the first and second IP fragment before it delivers the whole UDP packet to the application. But it seems to me that libpcap can't recognize the second IP fragment. are there any workaround for this? or any other libraries which can capture packets destined to a specific local port? thanks! ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
