> 1) handle payload spread over multiple frames in a number of
> places, including:
>
> payload spread over multiple IP fragments;
>
> payload spread over multiple TCP segments;
...although, as per the following mail to the tcpdump-workers list:
To: tcpdump-workers@xxxxxxxxxxxxxxxxxxxxxx
Subject: [tcpdump-workers] memory leak
Date: Sat, 18 Mar 2000 19:41:06 -0500
From: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Hugh Daniels <hugh@xxxxxxxx> reports:
-----BEGIN PGP SIGNED MESSAGE-----
I think I have seen a serious memory leek in both classic tcpdump-3.4
and the modern tcpdump-3.5/libpcap-0.5.
I found it when I was chasing a trinoo infection, I had serious
memory problems and it turn out that I had tcpdumps of well over 100
megabytes in RSS. Crazy.
In some quick tests I found that the printing of TCP packets seems
to cause tcpdump to grow in RSS until it start paging while UDP
packets did not have this affect.
I found a second (simpler) way to stroke this bug, by doing a nmap
(nmap -St -P 1-65535 -n <ipaddr>) scan on the same ether that I am
running a simple tcpdump (say tcpdump -n -i eth0) on I can get the
modern tcpdump-3.5 (candidate) to burn about 300 Kbytes more RSS each
run.
This memory leek turn out to kill high volume tcpdump work such as
anti-DDoS work on 100 mbit networks. Whee.
I am quite busy with other real work, but I consider this an
important enough bug that I have spent some time characterizing it in
hopes that someone who knows tcpdump can fix it quicker then I could
get around to it.
||ugh Daniel
hugh@xxxxxxxx
Systems Testing & Project mis-Management
The Linux FreeS/WAN Project
http://www.freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBONKYjlZpdJR7FBQRAQH3mwP/e5NIRHz7C7RMkYvTfkSRdphBVYR6MoMV
mRNX828oR9fMwpyW/o0yw8a+voGbkBOds3RQj/+XhAHhDCC4vs8Fwqclvqoz2bi9
tMLB0I6hF/eujSNvHPuP5ecxfzNrojGN8+MiE3E0PVEcc/Uw/cWbdAuSs6zPDQaO
XQtphl6EVV4=
=3kH4
-----END PGP SIGNATURE-----
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request@xxxxxxxxxxx?body=unsubscribe
the downside of maintaining per-packet or per-connection state is that
if somebody's trying to assault your machine by causing its networking
stack to, err, umm, maintain a lot of per-packet or per-connection
state, it can cause collateral damage to a program that's trying to
watch traffic on the network over which the assault is arriving
(tcpdump, when run without the "-S" flag, allocates per-connection data
structures so that it can report TCP sequence numbers relative to the
initial sequence numbers, rather than reporting absolute sequence
numbers; I suspect that's the source of the tcpdump problem being
reported, given that nmap is a port scanner, and the "-sT" flag, which
is apparently what Hugh meant by "-St", causes, well, a TCP "connect()"
scan...).