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

Wireshark-dev: Re: [Wireshark-dev] tshark --export-objects : -2 assumed or required for two-pas

From: chuck c <bubbasnmp@xxxxxxxxx>
Date: Mon, 10 Aug 2020 22:03:19 -0500
I think I muddied that waters asking about two-pass and export objects.

The tshark export (with or without -2) works in versions 2.6 and 3.0.
Something changed in 3.2 such that wireshark produces a good file and the tshark export doesn't match.

Pretty much in over my head as to whether to look in tshark.c, packet-dcm.c or somewhere else.
Was hoping to narrow things down before moving this to Bugzilla.

On Mon, Aug 10, 2020 at 9:30 PM Guy Harris <gharris@xxxxxxxxx> wrote:
On Aug 10, 2020, at 6:00 PM, John Thacker <johnthacker@xxxxxxxxx> wrote:

> On Mon, Aug 10, 2020 at 5:32 PM chuck c <bubbasnmp@xxxxxxxxx> wrote:
>> tshark --export-objects dicom is behaving differently than exporting Dicom objects in Wireshark.
>>
>> Is the "-2" option assumed to be set, observed if set or not used at all for exporting objects with tshark?
>
> Having implemented Export Objects on a different custom TFTP-like protocol, I experienced the same thing.
>
> With tshark, -2 is observed if set, and that can result in different behavior. Generally more accurate information is obtained with two passes, which is equivalent to Wireshark behavior.

Generally, at least for packet dissection, the only thing you get if you defer displaying packets until after the first pass is that you get to see not only "this frame is dissected as a response to the packet dissected for frame N" but also "this frame is dissected as a packet the response to which is in frame M".  There may be exceptions, but it's best to keep them to a minimum.

> There are certain protocols where single pass analysis just isn't sufficient to determine all the data, and dissectors where some state object is set, like packet-dcm.c, are a common case.

If M < N, most protocols do not require data from packet N (at that protocol layer) in order to process packet M; that even applies to implementations that maintain state.  The same applies to dissection; when dissecting a packet, all state established by previous packets is available.

What are some examples where you need information from *later* packets to:

        dissect a packet completely;

        start constructing a file object?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe