Hmmm.
Good question.
Keep in mind though that the fragment data is only one (albeight
probably quite a large one)
user of persistent data in [t]ethereal.
Other things that will build up state continously over time are
conversation tables,
hash tables for request/response matching etc etc.
To do this properly, what might need to be done would probably rather be
a long term project to have someone use valgrind to find high memory
users, one by one,
then add code to conditionally for tethereal clean up and return these
memory chunks
from time to time.
This willb e a big and long term project, if it is started and it
wouldr eqwuire someone (not me) to use valgrind or something similar
to track these users down one by one.
It would be much easier to just do what i do :
just write a small shellscript that runs an infinite loop running
tethereal or tcpdump and capturing 1 milion packets in each run.
Generate filenames for the captures based on
the timestamp when the capture was started.
On Thu, 16 Dec 2004 08:18:22 +0100, CHARBONNIER Christophe
<christophe.charbonnier@xxxxxxxxxxxx> wrote:
>
> Hi everyone,
>
> I am using tethereal to save WAP traffic with the help of the read-filters
> to isolate a very specific traffic. My saving process is several hours long.
> I see that the memory used by the tethereal process is increasing in a
> relatively constant manner during hours of use. I had look up in the
> ethereal-library to try to understand what is going on. I understood the
> following, tell me if I am wrong:
> for reassembling (reassemble.c), every frame that is to be reassembled is
> stored in the protocol-specific fragment-table (for me, it's WTP, so
> wtp_fragment_table). When a frame is inserted in this hash-table, it NEVER
> expires and is never freed... Am I right ?
>
> I understand this behavior is normal in a "normal" use (ie GUI analysis, or
> fixed-period decoding), but is this behavior still "acceptable" when
> capturing AND saving packets, without the verbose option (-V) ?
> Could it be possible to free the fragments when we do not need them anymore,
> because we know that we will not come back on it later on this same
> "tethereal session" ?
>
> I tried myself to "fix" this: in packet-wtp.c, dissect_wtp_common function:
>
> ...
> if ( ( (pdut == SEGMENTED_INVOKE) || (pdut == SEGMENTED_RESULT)
> || ( ((pdut == INVOKE) || (pdut == RESULT)) && (!fTTR) )
> ) && tvb_bytes_exist(tvb, dataOffset, dataLen) )
> {
> /* Try reassembling fragments */
> fragment_data *fd_wtp = NULL;
> guint32 reassembled_in = 0;
> gboolean save_fragmented = pinfo->fragmented;
>
> pinfo->fragmented = TRUE;
> fd_wtp = fragment_add_seq(tvb, dataOffset, pinfo, TID,
> wtp_fragment_table, psn, dataLen, !fTTR);
> wsp_tvb = process_reassembled_data(tvb, dataOffset, pinfo,
> "Reassembled WTP", fd_wtp, &wtp_frag_items,
> NULL, wtp_tree);
> if (fd_wtp) {
> /* Reassembled */
> reassembled_in = fd_wtp->reassembled_in;
> if (pinfo->fd->num == reassembled_in) {
> /* Reassembled in this very packet:
> * We can safely hand the tvb to the WSP dissector */
> call_dissector(wsp_handle, wsp_tvb, pinfo, tree);
> } else {
> /* Not reassembled in this packet */
> if (check_col(pinfo->cinfo, COL_INFO)) {
> col_append_fstr(pinfo->cinfo, COL_INFO,
> "%s (WTP payload reassembled in packet %u)",
> szInfo->str, fd_wtp->reassembled_in);
> }
> if (tree) {
> proto_tree_add_text(wtp_tree, tvb, dataOffset, -1,
> "Payload");
> }
> }
>
> /* We have a reassembled packet, we handed this to upper-dissector,
> * we now decide we do not need this reassembled fragment anymore...
> */
> char *del = fragment_delete(pinfo, TID, wtp_fragment_table);
> if (del)
> {
> g_free(del);
> }
>
>
> } else {
> /* Not reassembled yet, or not reassembled at all */
> ...
>
> Is this enough to free a reassembled-element ? Am I not missing some other
> stuff to free (such as memory-chunks) ? Am I not missing some issues ?
>
> Well, have anyone had to face the same problem I am facing ?
>
> Thank you very much for your attention
> Christophe
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
>
