Home page logo

wireshark logo Wireshark mailing list archives

Re: Memory consumption in tshark
From: Anders Broman <a.broman () bredband net>
Date: Wed, 28 Aug 2013 00:02:44 +0200

Joerg Mayer skrev 2013-08-27 23:24:
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass allows for most/all of the reassembly/request-response
which we want to do sometimes. Any ideas why we have to keep some

Two-pass requires us to keep *all* the state around through the first pass
so that it is available during the second pass (at which point it can be
discarded).  Even in single-pass mode, there is some state that we can't
always immediately discard. If I see a fragment of a TCP message then it
doesn't make sense to discard that until the other fragments have arrived
and been reassembled. If I see a request, I probably need to keep state
from that request until the response (which may never show up).

We already do reassembly and a lot of other stateful work in single-pass
mode. The only thing two-pass mode provides is the ability to "see the
future" (for example, saying: this request has a response 5 packets later).
So (assuming we really free everything we could already) could add a
possibly configurable foresight horizon of 10000 packets. If a packet
number is older than 10000 packets, forget it?

I haven't really looked but we do keep the reassembled fragments around even in tshark as there is no mechanism to discard them selectively if run by tshark as opposed to wireshark and that's the really big memory eater I would think.
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]