"ip_conntrack_core: Frag of proto 17." error and memory leak?

"ip_conntrack_core: Frag of proto 17." error and memory leak?

[c0g]

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

Hi,
I'm getting this error, my kern.log is flooded, it is logged many
hundred of thousands times. I read in ip_conntrack_core.c it should
"never happen" (so it's kind of assertion). Why does this assertion fail?

I'm using 2.4.22 kernel with CVS p-o-m 20030907. I'm using only
following major netfilter patches:

TCPLAG.patch
ipt_REJECT-fake-source.patch
raw.patch

and some minor:

39_ip_conntrack-proc.patch
40_nf-log.patch
54_ip_nat-macro-args.patch
58-ip_conntrack-macro-args.patch
59_ip_nat_h-unused-var.patch
60_nat_tftp-remove-warning.patch
61-remove-memsets.patch
63_getorigdst-tuple-zero.patch
74_nat-range-fix.patch
ip_ct_refresh_optimization.patch

I made rule that blocks fragments, but it doesn't stop messages (perhaps
because the check is performed before rules are evaluated).

Also, I suppose there is big kernel memory leak that happen about 12-24
hours after boot. It eats up to 40 MB of RAM memory in few seconds. If
someone is interested I made some graphs of vmstat (excel) at
http://ng.pl/~jp/vmstat-n5/
Could it be caused by failed "Frag of proto" assertion?

Is there someone who had this problem? And solved it?
Please give me some pointers what should I do.

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/ZewzPqmVt5WhbA8RAq3HAJ9Ahvz19BQNE4MXhLxzCyIuE4fqCwCfUwaw
eEhLSl0iX7j9KZr8kfsPIZ8=
=AiO4
-----END PGP SIGNATURE-----

Re: "ip_conntrack_core: Frag of proto 17." error and memory leak?

[Maciej Soltysiak]

Hello,

On Mon, 15 Sep 2003, c0g wrote:
> I made rule that blocks fragments, but it doesn't stop messages (perhaps
> because the check is performed before rules are evaluated).
How about investigating why are you getting fragments ? Maybe you can
eliminate the problem by avoiding fragmentation.

Anyway, as I remember the conntrack mechanism assembles fragments for
connection tracking purposes, thus it's denoted as /* Never happen */
Maybe you are being flooded, and the conntrack mechanism sees, something
like new fragmented UDP packets that cannot be assembled. Run iptraf,
tcpdump, snort or whatever you wish.

This could explain the memleak: conntrack reserves memory for each udp
fragment and hopes to assemble it, which never happens. I guess that
this should be free'd at some point, after failing to assemble the data,
but I am not sure.

If I am correct, we have a problem in the conntrack mechanism.
And a Netfilter DoS.

> Could it be caused by failed "Frag of proto" assertion?
If I am correct, or at least close, it might.

> Is there someone who had this problem? And solved it?
I never heard of such problems.

Regards,
Maciej

Re: "ip_conntrack_core: Frag of proto 17." error and memory leak?

[c0g]

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

| How about investigating why are you getting fragments ? Maybe you can
| eliminate the problem by avoiding fragmentation.

I tcpdumped it. It seems it is big syslog messages generated by one of
my hosts which don't fit in one packet. Syslog uses udp, so it fragment
these packets. And there are some minor fragmented udp packets from
users (perhaps some p2p program generates them).

| Anyway, as I remember the conntrack mechanism assembles fragments for
| connection tracking purposes, thus it's denoted as /* Never happen */
| Maybe you are being flooded, and the conntrack mechanism sees, something
| like new fragmented UDP packets that cannot be assembled. Run iptraf,
| tcpdump, snort or whatever you wish.

It is strange. These messages are logged even if fragments rate (sniffed
with tcpdump) is very low. It doesn't look like messages are indicating
fragments flood.

| This could explain the memleak: conntrack reserves memory for each udp
| fragment and hopes to assemble it, which never happens. I guess that
| this should be free'd at some point, after failing to assemble the data,
| but I am not sure.

I investigated it more deeply - log messages and memory leaks don't
correlate. The first happens in other time than second. Sorry for bad hint.
I was supposing these "leaks", because my box was hanging every day. I
replaced hardware and it stopped.
RAM "jumps" still happen. But now, when box uptime is > 1day I see RAM
returns to norm, some time after "leak". I spend long time tracking it,
and I know only one: RAM is not eaten by processes for sure. But
increased process activity triggers RAM leak (and I know - increased
process activity triggers cache and buffers grow, but I substracted
these in my tests). After processes end, there is fewer RAM than before.

But this problem appears now to be a little offtopic.
And now, when my box isn't hanging such frequently it isn't so important ;-)

Greets!

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/aG4tPqmVt5WhbA8RAkJnAJ9snfyKYWJeyXnv9i7WJqFvBacUSQCeNpZt
s9XiHzavRoLQK7AEiSk6lA8=
=cz2P
-----END PGP SIGNATURE-----

Re: "ip_conntrack_core: Frag of proto 17." error and memory leak?

[Maciej Soltysiak]

On Wed, 17 Sep 2003, c0g wrote:
> I tcpdumped it. It seems it is big syslog messages generated by one of
> my hosts which don't fit in one packet. Syslog uses udp, so it fragment
> these packets. And there are some minor fragmented udp packets from
> users (perhaps some p2p program generates them).
So I'm puzzled. You can try sending a brief note about it to
netfilter-devel@lists.netfilter.org

> But this problem appears now to be a little offtopic.
> And now, when my box isn't hanging such frequently it isn't so important ;-)
Good for you.

Regards,
Maciej