IP Conntrack

IP Conntrack

[faton kurteshi]

HI
 Does anybody know, why I'm getting this warning error or whatever
ip_conntrack_rtsp.c: help_out: ip_conntrack_expect_related failed (-17)
 and what can be the consequences, should I use any patch or something else
I'm using gentoo with kernel version 2.4.26-gentoo-r13.

Tkanks.

Faton

ip_conntrack

[Warren P]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

hi

does anyone know how to clear/flush the ip_conntrack table. Every 4 to 6 months i need to reboot my server because it drops packets and complains that the table is full ...

Regards,
Warren P

[-- Attachment #2: Type: text/html, Size: 677 bytes --]

Re: ip_conntrack

[Arnt Karlsen]

On Thu, 11 Sep 2003 22:19:04 +0200, 
"Warren P" <weatherman@webmail.co.za> wrote in message 
<000801c378a1$f6c24360$243902c4@weatherman>:

> hi
> 
> does anyone know how to clear/flush the ip_conntrack table. Every 4 to
> 6 months i need to reboot my server because it drops packets and
> complains that the table is full ...

..dive into /proc/sys/net/ipv4/ and check your timeouts.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: ip_conntrack

[NightHawk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just simply remove the mod ip_conntrac and any dependices and re-apply it.

**Warning** this will require you to drop iptables while you do it...which may 
not be a good option depening on your network configuration. **/Warning**

NH

On Thursday 11 September 2003 4:19 pm, Warren P wrote:
> hi
>
> does anyone know how to clear/flush the ip_conntrack table. Every 4 to 6
> months i need to reboot my server because it drops packets and complains
> that the table is full ...
>
> Regards,
> Warren P
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/ZiRdb58ZIoF+byQRAnS1AKCNFSkbxzO1C6HwHA6TdnOnzVfuYQCfZeDw
WdVpLPTGBcmroVejcs4QJYs=
=2odx
-----END PGP SIGNATURE-----

Re: ip_conntrack

[Security]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just simply remove the mod ip_conntrac and any dependices and re-apply it.

**Warning** this will require you to drop iptables while you do it...which may
not be a good option depening on your network configuration. **/Warning**

NH

On Thursday 11 September 2003 4:19 pm, Warren P wrote:
> hi
>
> does anyone know how to clear/flush the ip_conntrack table. Every 4 to 6
> months i need to reboot my server because it drops packets and complains
> that the table is full ...
>
> Regards,
> Warren P
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Zk3jPEfiOMhBaIMRAqjlAJ4wemLaeC1n/MjvJnANCT4jDJUHgwCfdldB
Dvk62MF2dxCx2uNilvCp13Y=
=vmrB
-----END PGP SIGNATURE-----

Re: ip_conntrack

[pengjie]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

try the 2.4.21.
  ----- Original Message ----- 
  From: Warren P 
  To: netfilter@lists.netfilter.org 
  Sent: Friday, September 12, 2003 4:19 AM
  Subject: ip_conntrack


  hi

  does anyone know how to clear/flush the ip_conntrack table. Every 4 to 6 months i need to reboot my server because it drops packets and complains that the table is full ...

  Regards,
  Warren P

[-- Attachment #2: Type: text/html, Size: 1565 bytes --]

Re: ip_conntrack

[Warren P]

hi

I've upgraded the server to Redhat 8 ... I seem to be worst
off now ... I'm getting the error "kernel: ip_conntrack:
table full, dropping packet." every few days now instead of
every few months as with Rehar 7.3

Question1: What are the dangers of increasing
/proc/sys/net/ipv4/ip_conntrack_max (I've currently got
1gig of RAM in my server and the current value of
ip_conntrack_max is 65528).

Question2: Do i really need ip_conntrack? Since I'm only
using it for my transparent proxy.

Question3: If i don't need it in order to user IP Tables,
how do i get rid of it safely? Will rmmod ip_conntrack.o be
sufficient and save?

Regards,
Warren P

------------------------------------------------------------


On Tue, 16 Sep 2003 09:27:44 +0800
 "pengjie" <bill.peng@ocamar.com> wrote:
> try the 2.4.21.
>   ----- Original Message ----- 
>   From: Warren P 
>   To: netfilter@lists.netfilter.org 
>   Sent: Friday, September 12, 2003 4:19 AM
>   Subject: ip_conntrack
> 
> 
>   hi
> 
>   does anyone know how to clear/flush the ip_conntrack
> table. Every 4 to 6 months i need to reboot my server
> because it drops packets and complains that the table is
> full ...
> 
>   Regards,
>   Warren P

Regards,
Warren P
___________________________________________
 Look Good, Feel Good www.healthiest.co.za

RE: ip_conntrack

[George Vieira]

ip connection tracking is what it says and using rules like

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

makes the existing connections automatically excepted, like an SSH connection will continue to work after the first SYN is accepted as the connection would be established and ip_conntrack will keep a record of the connection while it's still up.

Without ip_conntrack, the --state module would not work... correct me if I'm wrong guys.. ;)

Thanks,
____________________________________________
George Vieira
Systems Manager
georgev@citadelcomputer.com.au

Citadel Computer Systems Pty Ltd
http://www.citadelcomputer.com.au

-----Original Message-----
From: netfilter_user [mailto:netfilter_user@o2.pl]
Sent: Thursday, May 22, 2003 6:18 AM
To: netfilter@lists.netfilter.org
Subject: ip_conntrack


Hello everyone,

I have got very simply and basic quastion.
What ip_cpnntrack and ip_cpnntrack_ftp realy do? Tracking connection
or something more?

  

-- 
Best regards,
 mailto:netfilter_user@o2.pl

ip_conntrack

[netfilter_user]

Hello everyone,

I have got very simply and basic quastion.
What ip_cpnntrack and ip_cpnntrack_ftp realy do? Tracking connection
or something more?

  

-- 
Best regards,
 mailto:netfilter_user@o2.pl

ip_conntrack

[Warren P]

Hi

I'm receiving the following messages in /var/log/messages
kernel: ip_conntrack: table full, dropping packet.
My ip_conntrack_max = 65528.
I'm running a squid proxy and the messages did not bother me, until
last few days, when the proxy's responses deteriated heavily.
If ip_conntrack is the causing the problem, please indicate as to how
I determine what the prefered size of ip_conntrack_max should be
considering that I have 1gig of RAM in the machine.

_______________________________________________________________
 http://www.webmail.co.za the South-African free email service

  NetWiseGurus.Com Portal - Your Own Internet Business Today!

Re: ip_conntrack

[Ard van Breemen]

On Mon, Nov 25, 2002 at 02:00:41PM +0200, Warren P wrote:
> I'm receiving the following messages in /var/log/messages
> kernel: ip_conntrack: table full, dropping packet.
> My ip_conntrack_max = 65528.
> I'm running a squid proxy and the messages did not bother me, until
> last few days, when the proxy's responses deteriated heavily.
> If ip_conntrack is the causing the problem, please indicate as to how
> I determine what the prefered size of ip_conntrack_max should be
> considering that I have 1gig of RAM in the machine.
insmod ip_conntrack hashsize=4194304

If you have a lot of different connections, you do not want to be
stuck with 8192 buckets. It will get your system cpu up to
100%...
This way, you free your CPU, and it will allow you to have
9gigabyte worth of connections ... :-)
Anyway, adjust the hashsize to something that fits the use. The
hashsize I use above is for a core firewall only. But it does a
lot of connection tracking...
-- 
procedure signature;
begin  { telegraaf.com
} writeln('<ard@telegraafnet.nl> SMA-IS | Geeks don't get viruses');
end

ip_conntrack

[jrw]

Hi,
How could I remove a connection listed in the ip_conntrack file?
Because, now, I must wait until the timeout...
And if it's not possible, is there a way to change the timeout?

In my rules, I have the following line :
${IPTABLES} -A FORWARD -o eth1 -m state --state ESTABLISHED,RELATED      -j
ACCEPT 
and thus, old connection are accepted even if I restart iptables. I must
reboot the server to clean the connections listing.

Thansk for any help

-- 
  .''`. | Jean-Robert WIAME 
 : :' : | jrw AT ngi.be
 `. `'  | BELGIUM 
   `-   |  
--

Re: ip_conntrack

[Antony Stone]

On Thursday 17 October 2002 10:37 am, jrw@ngi.be wrote:

> Hi,
> How could I remove a connection listed in the ip_conntrack file?
> Because, now, I must wait until the timeout...
> And if it's not possible, is there a way to change the timeout?
>
> In my rules, I have the following line :
> ${IPTABLES} -A FORWARD -o eth1 -m state --state ESTABLISHED,RELATED      -j
> ACCEPT
> and thus, old connection are accepted even if I restart iptables. I must
> reboot the server to clean the connections listing.

You cannot remove entries from the connection tracking table.

If you know the IP address/es of the connection/s you wish to remove, you 
could insert some DROP or REJECT rules before the ESTABLISHED,RELATED match 
so that the connections get taken down.

eg iptables -I FORWARD -s a.b.c.d -j REJECT

will block packet from address a.b.c.d before they get recognised as part of 
a previously established connection.

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

Re: ip_conntrack

[Cedric Blancher]

Le jeu 17/10/2002 à 11:37, jrw@ngi.be a écrit :
> How could I remove a connection listed in the ip_conntrack file?
> Because, now, I must wait until the timeout...

See ipconntrack thread : you can't.

> And if it's not possible, is there a way to change the timeout?

Apply patch-o-matic tcp-window-tracking patch which provide a set of
sysctl (/proc/sys/net/ipv4/netfilter/) to tweak conntrack behaviours,
such as timeout. As far as I can remember, this feature has been
released separatly from TCP windows tracking and posted to devel mailing
list, but I can't find related post :/

Another way is to directly hack kernel sources to modify thoses timeouts
into header files.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: ip_conntrack

[Andrew Smith]

> Le jeu 17/10/2002 à 11:37, jrw@ngi.be a écrit :
>> How could I remove a connection listed in the ip_conntrack file?
>> Because, now, I must wait until the timeout...
> 
> See ipconntrack thread : you can't.
> 
>> And if it's not possible, is there a way to change the timeout?
> 
> Apply patch-o-matic tcp-window-tracking patch which provide a set of
> sysctl (/proc/sys/net/ipv4/netfilter/) to tweak conntrack behaviours,
> such as timeout. As far as I can remember, this feature has been
> released separatly from TCP windows tracking and posted to devel
> mailing list, but I can't find related post :/
> 
> Another way is to directly hack kernel sources to modify thoses
> timeouts into header files.
> 
> -- 
> Cédric Blancher  <blancher@cartel-securite.fr>

Actually, the real problem is that according to the dev team,
noone needs to change the timeout so they will not code to allow
that
I'm interested to see if there really was a patch-o-matic patch
to do this - but maybe it got removed by the dev team?

Below is my 'argument' with Harald regarding this earlier in the year
where he effectively said that the current value handles all cases
and should not be tuneable:

> On Thu, Jun 27, 2002 at 12:21:45PM +1000, Andrew Smith wrote:
>> This gives a good example when being able to set the timeout dependant
>> upon specific factors (e.g. port/protocol) would be good rather than a
>> global timeout that suits specific cases and does not match many cases
>> - and causes a severe problem for a limited set of cases
> 
> Sorry, but we've had this discussion over and over again. Go to the
> list archives and look for tuneable timeouts.
> 
> The conclusion of this discussion was, that we need to cope with all
> cases without any tuning being necessarry. 

Well either there is a language mistake or that statement is rubbish.
It does NOT cope with all cases.
If fails dismally with the case I've given.
It is not POSSIBLE to cope with all cases without any tuning being
necessary unless the code tuned itself.

Pity that the conclusion is flawed.

> btw: For the 'ping' case, the icmp echo reply is closing the connection
> anyway.

So I guess I need to look in detail what is happening in my case
- but at a guess the problem might be that a large number of the
connections fail to get a fast enough response and thus do not get
closed for a 'long' time.

> conntrack is mostly about tracking layer 3+4 protocol state.  And this
> should happen as transparent as possible, so assumptions about the
> application are made.  [conntrack helpers are an exemption, and be sure
> I would be much happier if we didn't need to have them].
> - Harald Welte / laforge@gnumonks.org              

Yes but the problem is that it causes problems at a higher protocol
level and though it works for most cases - it fails on at least a
few specific cases.

Anyway - this argument will not get anywhere.
I guess some time (in the far distant future :-) when I have the
time and inclination I'll fix it myself and then just have to keep
patching it every time it's updated - coz the comments certainly
suggest that a patch would not be accepted here.

-- 
-Cheers
-Andrew

MS ... if only he hadn't been hang gliding!