Re: Exporting FTP objects

[John Thacker <johnthacker () gmail com>]

On Tue, Dec 14, 2021 at 1:36 PM Richard Sharpe <realrichardsharpe () gmail com>
wrote:

> On Tue, Dec 14, 2021 at 10:18 AM Moshe Kaplan <mosheekaplan () gmail com>
> wrote:
> > I considered using such a data structure, but the challenge there is
> that there's no guarantee of a 'file transfer complete' that could be used
> to trigger reassembly and adding to the export objects list. AFAIK, it's
> also not possible to have a function to run after all packets were
> dissected to generate the export object list entries then.
>
> I am very unfamiliar with the tap infrastructure but perhaps you could
> introduce an EOM event through the tap so you could detect the data
> connection going down and do reassembly there.

The SMB export objects functionality, if I read it correctly, just does its
own reassembly inside its export objects tap, and every time it gets a new
chunk it updates the existing table entry (including showing what
percentage of the entire file has been gathered):

https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-smb.c#L973-1571

That's probably slower because of some extra copying and work, but you
don't have to worry about doing something special at the end, I suppose.

the TFTP export objects functionality was rewritten to be less that way a
while back:
https://gitlab.com/wireshark/wireshark/-/commit/25800536388aa2b567a18874dd0312a2bb29464d

though that's probably because the TFTP export objects only works on
complete files so the extra copies were just a performance waste.

For the data structure option, I recall doing something like that once
temporarily with I believe the TFTP dissector. You can store such a data
structure in conversation_data, and then on a second pass (checking if it's
visited) export if it's the last block seen. That doesn't work for tshark
except in two pass mode.

As far as the usefulness, for text files I found it quite useful to have
even partial sparse files, which is why I did the above, though I didn't
really consider it good enough quality to submit.

John Thacker

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe