From: Peteris Krumins <newsgroups@lf.lv>
To: netfilter@lists.netfilter.org
Subject: Possible huge iptables memory leakage
Date: Thu, 31 Jul 2003 22:23:06 +0300 [thread overview]
Message-ID: <62264464249.20030731222306@lf.lv> (raw)
Hello,
I suspect there is a huge memory leakage in one or more of the
iptables modules or iptables core.
The scenario is simple, i set up a test-machine and let different
traffic flow through it.
It's located near the central backbone of my company, so different
traffic flows through.
Different iptables matches/targets are used.
There are no applications running which could make memory leaks.
The Linux is custom built and takes up 12MB of disk space.
Only a single getty process is running and if i log in correctly a
shell - bash. Verifying the memory usage w/ `free' i see no userland
application is taking up that much memory alltogether, but the memory
usage is still growing.
two hours before:
used memory: 26304KB
now:
used memory: 29204KB
and the usage grows every hour around 1.5 MB.
The data flow is around 8mbit/s at a constant rate.
If i flush all the rules, the memory is not freed but it is not
growing anymore.
The Linux is - 2.4.22-pre6 patched w/ patch-o-matic-20030714
Iptables are 1.2.8 patched w/ patch-o-matic-20030714
Have some memory leaks recently been fixed?
I am tomorrow to try 2.4.22-pre9 and the latest patch-o-matic.
here's a list of used iptable modules:
(is there a way to find out how much memory each module uses?)
ipt_mark 440 2 (autoclean)
^- used to match some marked values
ipt_mport 696 4 (autoclean)
^- used to match some mports
ipt_state 568 4 (autoclean)
^- used to -j MARK only ESTABLISHED,RELATED traffic
ipt_psd 42824 2 (autoclean)
^- used to derect portscans
ipt_ttl 600 1 (autoclean)
^- used to fake outgoing ttl
ipt_limit 952 6 (autoclean)
^- used to limit some dataflow
ipt_MARK 824 316 (autoclean)
^- mark much packets for fun
iptable_nat 20728 0 (autoclean) (unused)
^- not used
ipt_REJECT 3192 1 (autoclean)
^- reject some traffic
iptable_filter 1668 1 (autoclean)
^- a must
ip_conntrack_ftp 4016 0 (unused)
ip_conntrack_irc 3184 0 (unused)
ip_conntrack 25736 4 [ipt_state iptable_nat ip_conntrack_ftp ip_conntrack_irc]
^- used to connection-track.
ip_queue 5020 1
ipt_XOR 1208 2 (autoclean)
^- used to encrypt some of the traffic.
iptable_mangle 2192 1 (autoclean)
^- used to match some packets in mangle table
ip_tables 13720 15 [ipt_mark ipt_mport ipt_state ipt_psd ipt_ttl ipt_limit ipt_MARK iptable_nat ipt_REJECT iptable_filter ipt_XOR iptable_mangle]
^- a must
next reply other threads:[~2003-07-31 19:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-31 19:23 Peteris Krumins [this message]
2003-07-31 19:42 ` Possible huge iptables memory leakage Aldo S. Lagana
2003-07-31 20:33 ` Re[2]: " Peteris Krumins
-- strict thread matches above, loose matches on Subject: below --
2003-07-31 20:14 Daniel Chemko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=62264464249.20030731222306@lf.lv \
--to=newsgroups@lf.lv \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox