On Thu, May 22, 2025 at 6:53 PM John Thacker <johnthac...@gmail.com> wrote:
> On Thu, May 22, 2025 at 11:22 AM Yaniv Kaul via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> I have some issue with the dissector going over my packets more than once. >> There's a legitimate reason to go over *some* packets more than once - if >> I have more than a single PDU in a packet (or a reassembled one), that's >> fine. But it just seems that it goes over all packets. I'm trying to fight >> it off with !pinfo->fd->visited, but I'm quite sure I'm doing >> something wrong. >> > > I believe you have a common misconception about how Wireshark works. It is > *not* the case that frames are dissected exactly once and that the entire > dissection tree (including all strings shown in the protocol tree pane) is > stored for each packet in memory. The dissection tree (and packet_info > Packets can and are dissected more than once. They can be dissected > sequentially a second time, such as when applying a new filter or opening a > tap, but they can also be dissected in an arbitrary order, such as when > clicking on a packet in the packet list in the Wireshark GUI and showing a > dissection tree. > > 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. > > 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. > > John > _______________________________________________ > Wireshark-dev mailing list -- wireshark-dev@wireshark.org > To unsubscribe send an email to wireshark-dev-le...@wireshark.org >
_______________________________________________ Wireshark-dev mailing list -- wireshark-dev@wireshark.org To unsubscribe send an email to wireshark-dev-le...@wireshark.org
