Le jeudi 18 février 2010 à 16:53 -0800, Afi Gjermund a écrit : > I have found the issue that was causing this problem. A userspace > application that was using the NFQueue mechanism to queue data to > userspace was returning a verdict of STOLEN on the first UDP packet > seen. This appears to have been leaving entries in the connection > table that could not be flushed via nf_conntrack_flush(). When > changing the verdict to DROP, the problem no longer existed. > > This was found as I noticed the Timer value of the connections within > the table remained at 3000 (30 in nf_conntrack_udp_timeout x 100). > > Feb 18 22:56:31 titan user.info kernel: =========================== > Table Dump ========================= > Feb 18 22:56:31 titan user.info kernel: ---- Set ---- > Feb 18 22:56:31 titan user.info kernel: Timer is : 3000 > Feb 18 22:56:31 titan user.info kernel: tuple dump: IP_CT_DIR_ORIGINAL > Feb 18 22:56:31 titan user.info kernel: > Feb 18 22:56:31 titan user.warn kernel: tuple c321cc70: l3num 2 > protonum 17 srcIP 172.16.8.45 srcPort 4858 -> dstIP 172.16.8.7 > dstPort 45001 > Feb 18 22:56:31 titan user.info kernel: tuple dump: IP_CT_DIR_REPLY > Feb 18 22:56:31 titan user.info kernel: > Feb 18 22:56:31 titan user.warn kernel: tuple c321cca8: l3num 2 > protonum 17 srcIP 172.16.8.7 srcPort 45001 -> dstIP 172.16.8.45 > dstPort 4858 > Feb 18 22:56:31 titan user.info kernel: ---- End Set ---- > Feb 18 22:56:31 titan user.info kernel: =========================== > End Table Dump ========================= > Feb 18 22:57:03 titan user.info kernel: =========================== > Table Dump ========================= > Feb 18 22:57:03 titan user.info kernel: ---- Set ---- > Feb 18 22:57:03 titan user.info kernel: Timer is : 3000 > Feb 18 22:57:03 titan user.info kernel: tuple dump: IP_CT_DIR_ORIGINAL > Feb 18 22:57:03 titan user.info kernel: > Feb 18 22:57:03 titan user.warn kernel: tuple c321cc70: l3num 2 > protonum 17 srcIP 172.16.8.45 srcPort 4858 -> dstIP 172.16.8.7 > dstPort 45001 > Feb 18 22:57:03 titan user.info kernel: tuple dump: IP_CT_DIR_REPLY > Feb 18 22:57:03 titan user.info kernel: > Feb 18 22:57:03 titan user.warn kernel: tuple c321cca8: l3num 2 > protonum 17 srcIP 172.16.8.7 srcPort 45001 -> dstIP 172.16.8.45 > dstPort 4858 > Feb 18 22:57:03 titan user.info kernel: ---- End Set ---- > Feb 18 22:57:03 titan user.info kernel: =========================== > End Table Dump ========================= > > Thank you all for your help! Hopefully this may help other people as well. > > Afi Thanks Afi for providing us more info :) Patrick, If a user application asks NF_STOLEN, we leak the skb. As the entry is freed, there is no way this skb can be found again. What do you think of following patch ? Or should we ignore NF_STOLEN status from user, to let packet still queued ? Thanks [PATCH] nf_queue: fix NF_STOLEN skb leak commit 3bc38712e3a6e059 (handle NF_STOP and unknown verdicts in nf_reinject) was a partial fix to packet leaks. If user asks NF_STOLEN status, we must free the skb as well. Reported-by: Afi Gjermund <afigjermund@xxxxxxxxx> Signed-off-by: Eric DUmazet <eric.dumazet@xxxxxxxxx> --- diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c index 3a6fd77..ba095fd 100644 --- a/net/netfilter/nf_queue.c +++ b/net/netfilter/nf_queue.c @@ -265,7 +265,6 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict) local_bh_disable(); entry->okfn(skb); local_bh_enable(); - case NF_STOLEN: break; case NF_QUEUE: if (!__nf_queue(skb, elem, entry->pf, entry->hook, @@ -273,6 +272,7 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict) verdict >> NF_VERDICT_BITS)) goto next_hook; break; + case NF_STOLEN: default: kfree_skb(skb); } -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
