netfilter buglog - Feb 2006 - [Bug 404] Packets stuck in netfilter_queue after heavy loading

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=404





------- Additional Comments From dave@rem.homeip.net  2006-02-03 20:29 MET
-------
Created an attachment (id=205)
 -->
(https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=205&action=view)
Description of "stuck packets", observations

Still don't know WHY packets get stuck...

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=404





------- Additional Comments From dave@rem.homeip.net  2006-02-03 20:29 MET
-------
Created an attachment (id=205)
 -->
(https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=205&action=view)
Description of "stuck packets", observations

Still don't know WHY packets get stuck...

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=404





------- Additional Comments From laforge@netfilter.org  2006-02-10 14:10 MET
-------
Just one minor comment, unrelated to the bug:
> 4. Queue drop rate (7th  field incrementing,
"queue_user_dropped",  except we
didn't) of 200-500/sec

'queue_user_dropped' doesn't mean the number of packets that were
reinjected
with verdict NF_DOP.  Rather, this value indicates how many packets had to be
dropped because the socket receive buffer of the userspace socket was full. 
Combined with a value of '0' for queue_dropped, this basically means
that your
socket buffer always fills up before we reach the maximum queue length.



-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=404





------- Additional Comments From laforge@netfilter.org  2006-02-10 14:48 MET
-------
Ok, now I have some news:

I can reproduce it when running iperf over the loopback interface and
doing -j QUEUE in INPUT.

With my debug patches, I get one line

len(4096) < nlh->nlmsg_len(16480)

for every 'stuck' packet. This clearly indicates that the kernel sends
messages that are larger than the 4096byte static buffer that
nfqnl_test.c uses.  I've increased this to 65535 and no longer get those
problems.

Hoewver, the buffer actually needs to be even larger, since the maximum
native packet size is 64k, plus the overhead of nfnetlink attributes,
etc.

What buffer size do you use in your app?


-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

On Fri, 10 Feb 2006, bugzilla-daemon@bugzilla.netfilter.org wrote:

+https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=404
+
+Hoewver, the buffer actually needs to be even larger, since the maximum
+native packet size is 64k, plus the overhead of nfnetlink attributes,
+etc.
+
+What buffer size do you use in your app?

#define PKT_BUFSIZE 65536

And it sounds as though I need to increase the recv buffer on the socket, 
from your last email?

Thanks!

Dave

+
+
+-- 
+Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
+------- You are receiving this mail because: -------
+You reported the bug, or are watching the reporter.
+