Hi, the quick answer: 1. don't die when you get "recv - failed" since it mean's you're buffer is done, keep on the loop. 2. don't do any heavy work on the callback. 3. try to minimize I/O operations in you're callback, since they are considered heavy, for example, writing to log will take "TONS" of time... the "no buffer space available" issue is due to the program not receiving packets fast enough and the allocated kernel buffer is filling up with message's until you'll receive messages will keep on dropping. what you should do is finish the callback function asap. you could either: 1. issue verdict faster.. 2. if you need to do some work on the packet before issue a verdict, you could save that message in you're own userspace queue and issue verdict later... the problem with the 2nd option is that now the "Queue length" of the libnetfilter_queue will be filled... you could increase it too when you initialize the queue, or when you with recv... Hope i've helped. Kind regards, Yechiel Levi On Thu, Sep 30, 2010 at 10:34 PM, Shihwei Li <lishihwei@xxxxxxxxx> wrote: > Hi, > > More information about the problem. I added perror() to the > nfqnl_test.c, it seems that there no buffer space available. Anyway to > increase the buffer space? Thanks. > > --peter > > entering callback > pkt received > hw_protocol=0x0800 hook=3 id=148 outdev=2 payload_len=1500 > entering callback > recv:: No buffer space available > unbinding from queue 0 > rv=-1 > , errorno=29 > > > 2010/9/30 Shihwei Li <lishihwei@xxxxxxxxx>: >> Hi, >> >> I am new to libnetfilter_queue and I need some helps. In short, I used >> the distributed nfqnl_test.c to monitor some HTTP/TCP packets and the >> nfqnl_test exits abnormally. >> >> I will try to describe my situation as accurately as possible. >> >> I plan to develop a program upon libnetfilter_queue to filter/inspect >> some HTTP/TCP packets. >> As a starter, I tried to run the test program, nfqnl_test.c from the >> libnetfilter_queue distribution. >> >> Here is what I did: >> * Set up a simple python http server on port 50007. >> (http://docs.python.org/library/basehttpserver.html) >> >> * Running iptables rules to pipe outgoing tcp packets from port 50007 >> to the queue 0: >> ** The rule is " /sbin/iptables -A OUTPUT -p tcp --sport 50007 -j >> NFQUEUE --queue-num 0" >> ** The iptables output is >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> NFQUEUE tcp -- anywhere anywhere tcp >> spt:50007 NFQUEUE num 0 >> >> * Running the nfqnl_test program on the web server side. >> >> * On another machine, open a web browser, and connect to the python web server. >> >> Everything went well, the browser could browse normally, and >> nfqnl_test on the server side could print the outgoing TCP packets >> info and reinject the packet into the queue ( verdict= NF_ACCEPT). >> >> UNTIL (see below) when the browser started to try to download (or >> open) a (big) zip file on the server side. The nfqnl_test program >> always exited from the callback loop during the middle of file >> downloading. I repeated five or so times (even trying open different >> file), the behavior is quite persistent. >> >> Is it possible a bug in the system? Or did I use the nfqnl_test >> wrongly? Or something else? Any suggestion? >> Thanks a lot. >> >> --peter >> >> Here are the details of my system: >> >> * OS: Linux .. 2.6.21-2950.fc8xen #1 SMP Tue Oct 23 12:24:34 EDT 2007 >> i686 i686 i386 GNU/Linux >> * libnfnetlink-1.0.0 >> * libnetfilter_queue-1.0.0 >> * iptables v1.3.8 >> >> >> Here is the output of the nfqnl_test: >> >> [root@ar21-222 utils]# ./nfqnl_test >> opening library handle >> unbinding existing nf_queue handler for AF_INET (if any) >> binding nfnetlink_queue as nf_queue handler for AF_INET >> binding this socket to queue '0' >> setting copy_packet mode >> pkt received >> hw_protocol=0x0000 hook=3 id=1 outdev=2 payload_len=60 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=2 outdev=2 payload_len=52 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=3 outdev=2 payload_len=52 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=4 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=5 outdev=2 payload_len=69 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=6 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=7 outdev=2 payload_len=60 >> entering callback >> pkt received >> hw_protocol=0x0000 hook=3 id=8 outdev=2 payload_len=52 >> .... >> hw_protocol=0x0800 hook=3 id=366 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0800 hook=3 id=367 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0800 hook=3 id=368 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0800 hook=3 id=369 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0800 hook=3 id=370 outdev=2 payload_len=1500 >> entering callback >> pkt received >> hw_protocol=0x0800 hook=3 id=371 outdev=2 payload_len=1500 >> entering callback >> unbinding from queue 0 <---------------------------------out from the loop >> hw_protocol=0x0800 hook=3 id=372 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=373 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=374 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=375 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=376 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=377 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=378 outdev=2 payload_len=1500 >> entering callback >> ... >> hw_protocol=0x0800 hook=3 id=426 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=427 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=428 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=429 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=430 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=431 outdev=2 payload_len=1500 >> entering callback >> hw_protocol=0x0800 hook=3 id=432 outdev=2 payload_len=1500 >> entering callback >> closing library handle <---- finish close the library >> > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
