1
votes

I'm writing a TCP proxy server program, it has code some snippets like:

// proxy server listen, waiting for incoming tcp requests
listen(listenfd, 1024);

while(1) {
connfd = accept(listenfd, (struct sockaddr *)&sender_addr, &sock_len);

pid=fork();
if(pid=0)  // child process
 {
  // processing this connection
 }   
 blabla.....
}

when a HTTP client initiates a TCP connection with the proxy, the process is

client ------ TCP SYN ---------> proxy
client <------TCP SYN/ACK ------ proxy             
client -------TCP ACK ---------> proxy
client ------HTTP request -----> proxy  

what I want to do between the proxy and webserver has nothing to do with this question Anyway, the client will send a TCP SYN packet, TCP ACK packet and a HTTP request packet sequentially.

The proxy may accept a lot of incoming TCP 3-way handshake and HTTP request from many clients. I want to get the TCP ACK packet and the HTTP request packet(it is also a TCP packet) for EACH incoming TCP connection, including the IP header and TCP header. If I can't get the TCP ACK, at least, I want to get the HTTP request packet(including the IP header and TCP header) .

one way is to use libpcap to capture packets with ACK flag set for EACH INCOMING TCP connection (filter_exp is like tcp[tcpflags] & (tcp-ack) != 0)

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 good solutions which meet my requirements? thanks!

1

1 Answers

1
votes

Your requirements are not completely clear to me, however, if you start up a thread that does pcap_loop you should get a callback for each packet. You can then deal with that data as you will. You probably don't want to open up a new capture for each accept as buffering/scheduling may mean you'll lose packetts.