libnetfilter_queue hang when flooding

libnetfilter_queue hang when flooding

[Eric Leblond]

[-- Attachment #1.1: Type: text/plain, Size: 1341 bytes --]

Hi,

I've proceed to some stress test of libnetfilter_queue using hping3.

./hping3 -p 5000  --flood localhost


The main issue is that the recv buffer of the netlink socket gets full.
We've got error 105 during recv.
unbinding from queue 0

I provide a patch to print error and avoid printf to be able to test
performance of libnetfilter_queue.

The problem is that when socket is full we disconnect and try to close
the queue :
	got error 105 during recv.
	unbinding from queue 0
It hangs here. gdb shows that we hang in recvmsg.

Here's the backtrace :

#0  0x00002aaaaad98762 in recvmsg () from /lib/libc.so.6
#1  0x00002aaaaaf0aa36 in nfnl_talk (nfnlh=0x502010, n=<value optimized
out>, 
    peer=<value optimized out>, groups=<value optimized out>,
answer=0x0, junk=0, jarg=0x0)
    at libnfnetlink.c:552
#2  0x00002aaaaabc2dff in __build_send_cfg_msg (h=0x5021e0, command=2
'\002', 
    queuenum=<value optimized out>, pf=0) at libnetfilter_queue.c:112
#3  0x00002aaaaabc312d in nfq_destroy_queue (qh=0x502250) at
libnetfilter_queue.c:258
#4  0x0000000000401028 in main ()

In fact, the control message can not be received as the receive buffer
of the socket is full.

I did not find any workaround except brutal cancellation? Any idea are
welcome.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #1.2: nfqnl_test.diff --]
[-- Type: text/x-patch, Size: 1640 bytes --]

Index: utils/nfqnl_test.c
===================================================================
--- utils/nfqnl_test.c	(revision 6652)
+++ utils/nfqnl_test.c	(working copy)
@@ -2,11 +2,14 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
+#include <errno.h>
 #include <netinet/in.h>
 #include <linux/netfilter.h>		/* for NF_ACCEPT */
 
 #include <libnetfilter_queue/libnetfilter_queue.h>
 
+#define PRINT_INFOS 
+
 /* returns packet id */
 static u_int32_t print_pkt (struct nfq_data *tb)
 {
@@ -16,13 +19,17 @@
 	int ret;
 	char *data;
 	
+    id = ntohl(ph->packet_id);
 	ph = nfq_get_msg_packet_hdr(tb);
 	if (ph){
 		id = ntohl(ph->packet_id);
+#ifdef PRINT_INFOS
 		printf("hw_protocol=0x%04x hook=%u id=%u ",
 			ntohs(ph->hw_protocol), ph->hook, id);
+#endif
 	}
 	
+#ifdef PRINT_INFOS
 	mark = nfq_get_nfmark(tb);
 	if (mark)
 		printf("mark=%u ", mark);
@@ -40,7 +47,7 @@
 		printf("payload_len=%d ", ret);
 
 	fputc('\n', stdout);
-
+#endif
 	return id;
 }
 	
@@ -49,7 +56,9 @@
 	      struct nfq_data *nfa, void *data)
 {
 	u_int32_t id = print_pkt(nfa);
+#ifdef PRINT_INFOS
 	printf("entering callback\n");
+#endif
 	return nfq_set_verdict(qh, id, NF_ACCEPT, 0, NULL);
 }
 
@@ -96,12 +105,17 @@
 
 	nh = nfq_nfnlh(h);
 	fd = nfnl_fd(nh);
-
 	while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) {
+#ifdef PRINT_INFOS
 		printf("pkt received\n");
+#endif
 		nfq_handle_packet(h, buf, rv);
 	}
 
+    if (rv<0){
+        printf("got error %d during recv\n",errno);
+    }
+
 	printf("unbinding from queue 0\n");
 	nfq_destroy_queue(qh);
 

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: libnetfilter_queue hang when flooding

[Patrick McHardy]

Eric Leblond wrote:
> Hi,
> 
> I've proceed to some stress test of libnetfilter_queue using hping3.
> 
> ./hping3 -p 5000  --flood localhost
> 
> 
> The main issue is that the recv buffer of the netlink socket gets full.
> We've got error 105 during recv.
> unbinding from queue 0
> 
> I provide a patch to print error and avoid printf to be able to test
> performance of libnetfilter_queue.
> 
> The problem is that when socket is full we disconnect and try to close
> the queue :
> 	got error 105 during recv.
> 	unbinding from queue 0
> It hangs here. gdb shows that we hang in recvmsg.

Its waiting for an ACK from the kernel .. which doesn't seem to
be very reasonable unless measures are taken in case it doesn't
arrive within some timeframe. So I think you could do one of:

- don't require an ACK
- implement timeouts and retransmissions in case ACK doesn't arrive