RE: Forwarding GnomeMeeting to internal network

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If you are using a newish version of Netfilter, you can execute
something like the following:

echo "1000" >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait

This would set TCP CLOSE_WAIT timeouts to 1000 seconds. The default
number is 3 days, so within that time, any traffic that does not close
the connection properly will linger inside the conntrack systems.

I don't have the option to fix the bad system. I do Nagios probes for
Windows 2000 RDP uptimes using tcp socket probing (I know I could use
RPC, blah blah), but the RDP connections are never fully closed by the
windows machine, so within a couple days of probing various servers, I
have quite a large conntrack table. 


-----Original Message-----
From: Julien Didron [mailto:admin@xxxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, November 12, 2003 5:11 AM
To: Netfilter Mailing List
Subject: Re: Forwarding GnomeMeeting to internal network

Hi again,


Thanks for the answer Antony.
I'll then grant this box a fixed IP using DHCP declaration with the MAC 
adress.

Concerning the ip_conntrack table, I indeed have a sort of worm on my
network 
called "MLdonkey" ;o) (it's on some other box on the network), process
that I 
kill everytime the problem occurs, but with no success : i still get the
very 
same error line in syslog.
after increasing the value of ip_conntrack_max, I monitored the traffic
on 
the outgoing interface, that was very little : say from 150B/s to 500B/s
up 
and down.
For information my local network (this is home) is composed of 4
machines 
ranging from mail server (smtp and pop) to DDNS, DHCP and web server ...
But 
I really don't think it to be a "large" network :o)




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux