Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Conntrack\s+leak\s+\(2\.6\.2rc2\)\s*$/: 34 ]

Total 34 documents matching your query.

1. Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 08:56:45 +0000 (GMT)
I've already posted this to the netfilter-devel list and had no response so I'm hoping that some of you might have some insight into the problem: I'm using the 2.6.2rc2 kernel and have a strange conn
/archives/netdev/2004-02/msg00010.html (8,605 bytes)

2. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 09:46:19 +0000 (GMT)
From my observations, init_conntrack() is being called for each packet (not fragment, packet), which seems right. destroy_conntrack() is, however, _not_ being called for any packets that are fragment
/archives/netdev/2004-02/msg00011.html (9,679 bytes)

3. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 10:22:17 +0100 (CET)
Hi Steve, init_conntrack is called only when we have full, non-fragmented packets: ip_conntrack_in explicitly calls the proper function to gather the fragments before calling init_conntrack. There is
/archives/netdev/2004-02/msg00012.html (9,190 bytes)

4. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 10:48:08 +0000 (GMT)
I have added to the top of init_conntrack(): printk("Init conntrack\n"); Doing: ping -n 172.16.0.1 -c 1 -s 2500 through the machine now causes the kernel to output "Init conntrack", proving the funct
/archives/netdev/2004-02/msg00013.html (10,636 bytes)

5. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 11:34:22 +0100 (CET)
No, that's not true (and would be bad). Please check the code. Yes, because fragmented packets does not lead to conntrack entries - there is nothing to be freed. I could not reproduce it: test machin
/archives/netdev/2004-02/msg00014.html (10,107 bytes)

6. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 12:45:04 +0100 (CET)
Yes, once, on the whole packet. Or do you see the message two times, when issuing the ping command above once? You described exactly what happens: fragmented packets received, defragged by the stack,
/archives/netdev/2004-02/msg00015.html (11,598 bytes)

7. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 11:58:13 +0000 (GMT)
No, only once for the whole packet (sorry, I think I didn't do a good job of describing the problem). init_conntrack() always gets called once for the whole packet (this seems right to me). However,
/archives/netdev/2004-02/msg00016.html (11,172 bytes)

8. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 13:47:56 +0100 (CET)
To be precise, the destroy function is not called whenever a packet leaves the system: it gets called, when conntrack thinks the connection is completed. It can happen when whe explicitly know from t
/archives/netdev/2004-02/msg00017.html (10,528 bytes)

9. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 13:36:07 +0000 (GMT)
Yes, this makes sense. The fact that the connection is removed from the hash table indicates that conntrack thinks the connection has gone, but the destroy function was never called. (The connection
/archives/netdev/2004-02/msg00018.html (12,416 bytes)

10. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 14:03:40 +0000 (GMT)
I'm just investigating the usage count ATM to see if I can work out what is (claiming to be) using the data. - Steve Hill Senior Software Developer Email: steve@xxxxxxxxxxxx Navaho Technologies Ltd.
/archives/netdev/2004-02/msg00019.html (9,786 bytes)

11. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 14:46:24 +0100 (CET)
You convinced me: something is really fishy. I fire up debugging and checking. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pg
/archives/netdev/2004-02/msg00020.html (11,123 bytes)

12. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Tue, 3 Feb 2004 09:14:11 +0100
I also have some problems with conntrack since updating to 2.6.2rc3 from 2.6.1 on x86-64. Some TCP connections for the masqueraded machines seem to go extremly slow. I haven't investigated more close
/archives/netdev/2004-02/msg00038.html (10,057 bytes)

13. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: 明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 3 Feb 2004 09:48:55 +0100 (CET)
I created exactly the same setup (machine 1 and 3 are UMLs) and could not reproduce the problem. tcpdump shows that machine 1 sends fragmented ICMP echo requests and machine 3 sends ICMP echo reply b
/archives/netdev/2004-02/msg00041.html (10,079 bytes)

14. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: csik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Tue, 3 Feb 2004 14:35:45 +0000 (GMT)
No extra patches, it's the vanilla 2.6.2rc2 kernel. I'm running a nonmodular kernel and have spent this morning recompiling it with different options - the problem is only showing up when CONFIG_IP_N
/archives/netdev/2004-02/msg00042.html (10,192 bytes)

15. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Tue, 3 Feb 2004 16:32:42 +0100 (CET)
I can confirm that with the NAT module loaded in, the leak you described appears. As if the reference counts created as refragging the packet would not be cleaned up properly... Best regards, Jozsef
/archives/netdev/2004-02/msg00043.html (9,875 bytes)

16. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Wed, 4 Feb 2004 10:20:37 +0100
Yes, this is indeed the case. Whihc is not a contradiction to what Jozsef said. They are defragmented before getting passed to conntrack, and thus look exactly the same like unfragmented packets thro
/archives/netdev/2004-02/msg00057.html (10,541 bytes)

17. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: xx>
Date: Wed, 4 Feb 2004 10:22:50 +0100
To be more precise: It is called for every NEW packet, after defragmentation happens (i.e. if ip_conntrack_find_get() returns NULL, meaning there is no entry in the hash table.). -- - Harald Welte <l
/archives/netdev/2004-02/msg00058.html (10,194 bytes)

18. Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 08:56:45 +0000 (GMT)
I've already posted this to the netfilter-devel list and had no response so I'm hoping that some of you might have some insight into the problem: I'm using the 2.6.2rc2 kernel and have a strange conn
/archives/netdev/2004-02/msg00751.html (8,605 bytes)

19. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 09:46:19 +0000 (GMT)
From my observations, init_conntrack() is being called for each packet (not fragment, packet), which seems right. destroy_conntrack() is, however, _not_ being called for any packets that are fragment
/archives/netdev/2004-02/msg00752.html (9,773 bytes)

20. Re: Conntrack leak (2.6.2rc2) (score: 1)
Author: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 10:22:17 +0100 (CET)
Hi Steve, init_conntrack is called only when we have full, non-fragmented packets: ip_conntrack_in explicitly calls the proper function to gather the fragments before calling init_conntrack. There is
/archives/netdev/2004-02/msg00753.html (9,245 bytes)


This search system is powered by Namazu