Thanks for the quick response, comments below. On Thu, May 22, 2025 at 6:45 PM Roland Knall <rkn...@gmail.com> wrote:
> This is done by design. Wireshark uses a 2-stage dissection to be able to > stuff like the cross-reference of request/response relationships or > reassembly. As you cannot do this without starting the dissection we need > to go over every packet. > > There is no way to avoid that, your dissector should not be build in a way > that it may lead to issues. And normally it also should not run into any > issues. > Yes, I believe you are right. I'm trying to improve an existing dissector ( https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-scylla.c?ref_type=heads ) Probably needs some more work. > > Also, just as a headsup, there is a difference between reported length and > remaining length. Reported does not necessarily give you the complete > packet but may be larger as the actual bytes. Remaining counts the bytes > remaining inside the frame. > It's interesting, non scientific stats show that half of the dissectors calling tcp_dissect_pdus() end up with return tvb_captured_length(tvb); and the other half with return tvb_reported_length(tvb); Specifically, so does the example in README.dissector I do agree remaining make more sense - but actually a lot more sense would be to use the output from my xxx_get_len() function, no? > I am also not sure if directly dissecting the pdus is such a good idea > here. You should not need it to get the length back. Rather the dissecting > method should return the remaining bytes and you can remove that from the > length reported. > It's indeed a horrible idea. In the past ( https://lists.wireshark.org/archives/wireshark-dev/202412/msg00002.html ) I did ask what else I could do. The challenge is that mid-stream, I don't know if the stream is compressed or not streamed or otherwise - all of which is data I *could* keep in a conversation. Perhaps there's a better way? One of my main challenges is that sometimes I get a packet dump without the initial negotiation, and I would still like to make an honest effort (read: heuristically) dissect some of the data. > It might be a good idea to read through our documentation about the > various lengths and the repercussions again. > Certainly. I must add that my method works. But I feel it's the wrong way to achieve this. Thanks again for your reply. Y. > cheers > Roland > > Am Do., 22. Mai 2025 um 17:22 Uhr schrieb Yaniv Kaul via Wireshark-dev < > wireshark-dev@wireshark.org>: > >> 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. My code is quite standard: >> static int >> dissect_scylla(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void* >> data) >> { >> tcp_dissect_pdus(tvb, pinfo, tree, scylla_desegment, >> SCYLLA_NEGOTIATION_SIZE, >> get_scylla_pdu_len, dissect_scylla_pdu, data); >> return tvb_reported_length(tvb); >> } >> >> The get_scylla_pdu_len isn't, regretfully - it does find_conversation() >> and if it exists uses it (to get the state of protocol features, such as >> streaming, compression, etc.) >> >> TIA, >> Y. >> _______________________________________________ >> 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
