Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Running (T)Ethereal forever

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, 02 Sep 2004 12:46:49 -0700
Pierre JUHEN wrote:

I would like to run tethereal on a PC "forever".

I use it to capture on an ethereal interface, filter some packets, and them
on the network through another interface.

So what exactly are you making Tethereal do?

I assume something's missing from "and them on the network through another interface" - do you mean "and send them on the network through another interface"? If so, that's not something Tethereal can do.

Presumably this means you're doing a capture to a binary file, rather than writing out the packet dissection as text.

If so, then:

However, tethereal consumes memory for each packet,

...Tethereal only consumes memory if it has to maintain state when dissecting packets (if there's no state, it shouldn't be consuming memory for each packet - if it does, that's a bug).

If you're saving to a binary capture file, and you're not using a read filter or any taps, Tethereal shouldn't be dissecting packets (if it is, that's a bug).

Would it be possible to have an option where tethereal releases the memory used by the capture,
after either a  number of packets, or a certain amount of time.

It might be possible, at the risk of causing some packets not to be dissected correctly (as the state needed to dissect them would no longer be available). It wouldn't necessarily be easy to implement - it's not as if there's a centralized piece of code that's responsible for all the state information (only a dissector knows what state it'll need).

This would be also useful for ethereal in graphical mode, but I guess it's more difficult.

What exactly would it *mean* in Ethereal? It *needs* to keep at least *some* information in memory for every packet in the packet list, and, as the state information is used to dissect packets, and as you can click on packets in any order you want, and go back to a packet multiple times, it needs to keep enough state to allow a packet to be dissected after the first time it's seen.