On 5/2/05, Mogens Valentin <monz@xxxxxxxxx> wrote: > Taylor, Grant wrote: > >> Moritz, thanks for pointing that out. > >> Your suggested 10 minutes seems a bit short, though.. > > > > > > I would not set ip_conntrack_tcp_timeout_established to any thing lower > > than tcp_fin_timeout. I would be tempted to set > > ip_conntrack_tcp_timeout_established to approximately double what > > tcp_fin_timeout is set to. I don't know of any reason that conntrack > > would need to keep things for twice tcp_fin_timeout, but I'd rather be > > safe than sorry. Besides even double of tcp_fin_timeout is CONSIDERABLY > > less than 5 days. > > Hmm, dunno if various distros set tcp_fin_timeout differently. > With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this). > Are you saying that Mouritz' 10mins will in some (distro?) cases violate > ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ? > In debian3.1 it is 5 days too !!! The question now, what troubles would happen if we kep it/changed it !?!?! > Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says > > tcp_fin_timeout > --------------- > The length of time in seconds it takes to receive a final FIN before the > socket is always closed. This is strictly a violation of the TCP > specification, but required to prevent denial-of-service attacks. > > I'm having trouble understanding the 'strictly a violation' part. > Is it a (iana) crime to define tcp_fin_timeout? > > -- > Kind regards, > Mogens Valentin > > -- Mohamed Eldesoky www.eldesoky.net RHCE
