conntrack records not going away?

conntrack records not going away?

[Tobias DiPasquale]

Hi all,

We have a box running 2.4.26 (from kernel.org) over here that's
serving as a sink for test SMTP traffic. The box sits behind a Linux
box that is doing ProxyARP. The weird thing is, sometimes after
sending tons of traffic to the sink, conntrack records hang around in
the ESTABLISHED state, even though the sink process (the endpoint for
the connections in question) has been shut down. Has anyone ever seen
this before? TIA :)

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: conntrack records not going away?

[Tobias DiPasquale]

On Mon, 20 Dec 2004 14:19:24 -0500, Tobias DiPasquale
<codeslinger@gmail.com> wrote:
> Hi all,
> 
> We have a box running 2.4.26 (from kernel.org) over here that's
> serving as a sink for test SMTP traffic. The box sits behind a Linux
> box that is doing ProxyARP. The weird thing is, sometimes after
> sending tons of traffic to the sink, conntrack records hang around in
> the ESTABLISHED state, even though the sink process (the endpoint for
> the connections in question) has been shut down. Has anyone ever seen
> this before? TIA :)

More info: no NAT'ing is going on (the sink box has no firewall rules
of any kind and all policies are ACCEPT). I read on an earlier post to
some mailing list that this can happen if the application doesn't
close the connections in the proper way. I will try to capture the
packets and see what could be the issue in that respect.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: conntrack records not going away?

[Jason Opperisano]

On Mon, 2004-12-20 at 14:19, Tobias DiPasquale wrote:
> Hi all,
> 
> We have a box running 2.4.26 (from kernel.org) over here that's
> serving as a sink for test SMTP traffic. The box sits behind a Linux
> box that is doing ProxyARP. The weird thing is, sometimes after
> sending tons of traffic to the sink, conntrack records hang around in
> the ESTABLISHED state, even though the sink process (the endpoint for
> the connections in question) has been shut down. Has anyone ever seen
> this before? TIA :)

once a TCP connection gets to ESTABLISHED [ASSURED] state--it will not
be removed from conntrack until it times out (after 5 days by default
(432000 seconds)), or one side sends a FIN-ACK packet requesting that
the connection be torn down.

it sounds like you're shutting down endpoints after the connections are
setup, but before they have a chance to close them.

-j

--
"Ah, beer, my one weakness. My achilles heel, if you will."
	--The Simpsons

Re: conntrack records not going away?

[Ralf Spenneberg]

Am Di, den 21.12.2004 schrieb Jason Opperisano um 3:33:
> On Mon, 2004-12-20 at 14:19, Tobias DiPasquale wrote:
> > Hi all,
> > 
> > We have a box running 2.4.26 (from kernel.org) over here that's
> > serving as a sink for test SMTP traffic. The box sits behind a Linux
> > box that is doing ProxyARP. The weird thing is, sometimes after
> > sending tons of traffic to the sink, conntrack records hang around in
> > the ESTABLISHED state, even though the sink process (the endpoint for
> > the connections in question) has been shut down. Has anyone ever seen
> > this before? TIA :)
> 
> once a TCP connection gets to ESTABLISHED [ASSURED] state--it will not
> be removed from conntrack until it times out (after 5 days by default
> (432000 seconds)), or one side sends a FIN-ACK packet requesting that
> the connection be torn down.
> 
Or a TCP-Reset.

Cheers,

Ralf
-- 
Ralf Spenneberg <lists@spenneberg.org>

Re: conntrack records not going away?

[Tobias DiPasquale]

On Mon, 20 Dec 2004 21:33:52 -0500, Jason Opperisano <opie@817west.com> wrote:
> once a TCP connection gets to ESTABLISHED [ASSURED] state--it will not
> be removed from conntrack until it times out (after 5 days by default
> (432000 seconds)), or one side sends a FIN-ACK packet requesting that
> the connection be torn down.
> 
> it sounds like you're shutting down endpoints after the connections are
> setup, but before they have a chance to close them.

I wasn't able to get a capture that expressed this particular problem.
Every time I did a capture, the FINs were sent properly and the
conntrack records were removed. But I have another question: is what
you're telling me above that the kernel will sometimes not correctly
close a socket that a process has open when it gets killed? Where is
the code in the kernel that governs that behavior?
linux/net/ipv4/tcp_*?

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: conntrack records not going away?

[Jason Opperisano]

On Wed, 2004-12-22 at 02:41, Ralf Spenneberg wrote:
> Or a TCP-Reset.
> 
> Cheers,
> 
> Ralf

whoops--yeah, precisely.

-j

--
"My cat's breath smells like cat food."
	--The Simpsons

Re: conntrack records not going away?

[Jason Opperisano]

On Wed, 2004-12-22 at 07:37, Tobias DiPasquale wrote:
> I wasn't able to get a capture that expressed this particular problem.
> Every time I did a capture, the FINs were sent properly and the
> conntrack records were removed. But I have another question: is what
> you're telling me above that the kernel will sometimes not correctly
> close a socket that a process has open when it gets killed? Where is
> the code in the kernel that governs that behavior?
> linux/net/ipv4/tcp_*?

um--requesting the socket to be closed is the job of the application. 
when apps crash, processes die, cables get unplugged, power goes
out--connections do not get shut down gracefully and get stuck in your
firewall connection table.  i'm not telling you the kernel isn't doing
its job.  i was saying that either the application isn't doing its job
or a person between the application and the firewall isn't letting the
application do its job.

-j

--
"Getting out of jury duty is easy. The trick is to say you're
 prejudiced against all races."
	--The Simpsons