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?
