[John Thacker <johnthacker@xxxxxxxxx>]

On Thu, May 22, 2025 at 12:49 PM Yaniv Kaul via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

On Thu, May 22, 2025 at 6:53 PM John Thacker <johnthacker@xxxxxxxxx> wrote:

This is done for several reasons. It is done to consume less memory, not having to store all the strings and other information. It is done for performance - when not displaying certain strings, they don't have to be calculated, which saves on expensive string operations. When filtering on only certain fields, fields that don't matter (and their parents, etc.) don't have to be computed. This is tremendously faster. Then too, it is frequently useful to display information about future packets if available (e.g., linking to and/or showing information from a response packet). This is accomplished in the GUI by initially doing 2-passes (and can be done in tshark with an option, though not in a live capture) so that packets have information about their responses. Attempting to add the information into the protocol tree from another packet would be difficult to impossible.

Thanks for your response. I find it also somewhat inefficient to re-parse packets when I do not need to. I understand (now) better the reasons why it's done, but both my (now) spaghetti code and the efficiency (and perhaps bugs) could be somehow avoided, I reckon, if I know better if it's the first or nTh pass.

Why do you think you don't need to?

Currently, you are guaranteed that the initial dissection through the packets is sequential. (It might be nice not to guarantee that, because it makes trying to implement threading difficult, but with various dependencies of packets on each other that's hard to change.) Many dissectors do indeed check !PINFO_FD_VISITED(pinfo) and do certain things differently on the initial pass, and that might be needed for your dissector.

I'm not sure that works so well for me when I have multiple PDUs in a single packet though?

Ideally, I'd somehow skip already dissected PDUs.

Y.

I don't understand what you mean. How would you do that? If you mean something like on the same pass through all the frames, then the TCP dissector will call your dissector with a tvbuff starting at the next offset to dissect, after all the PDUs you have dissected. If you mean on an entirely different pass through the frames (or after clicking on a different frame in the GUI), I don't understand what you mean.

John