On Tue, Dec 14, 2021 at 10:18 AM Moshe Kaplan <mosheekaplan@xxxxxxxxx> 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):
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:
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