Hi Wesley, thanks for talking about this very particular use case. I understand you cannot share any PCAP, even anonymized, which makes things difficult to solve. Do you think that would be possible to share a screenshot of the GUI, particularly of the Packet Details panel where we can see how things are interpreted and rendered ? Even if some parts are blurred or masked intentionally , that would help a lot.
best regards E.A. Le lun. 22 sept. 2025 à 14:13, wireshark via Wireshark-dev <wireshark-dev@wireshark.org> a écrit : > > Hi All, > > I work for the Netherlands Forensic Institute (NFI, https://nfi.nl/ ) where i > maintain a wireshark fork for internal use with a custom dissector and file > handler. Unfortunately i'm not allowed to share this code or a capture. > > We have a (special?) use case where each frame can contain a high number of > IP packets, i've even seen up to 100's in one frame. Those packets may be > related (same sender/receiver or reverse, same service), but don't need to > be. For most things dissection works as expected. Especially in cases where > analysis spans multiple packets this breaks, sometimes in minor ways, > sometimes with an unusable result. The cause of this seems to be that on > quite some places there is the assumption that 1 frame == 1 IP packet. So far > I found two places where this is visible: > 1) The packet_info struct is used per frame and can only hold one set of > source/destination addresses and ports. In cases where more IP headers are > available, the values of the last header that is analyzed will be the one > that remain, the others are lost (at least in packet_info, not in the > dissection tree of course). > 2) When referring to other packets (like pairing a request and response or > stream analysis) this is done by frame number only. Of course this is > ambiguous when a frame holds 10's or 100's of packets. > Because of this we run into multiple problems. TCP, QUIC and RTP are the > first ones that come to mind. For some a workaround is a possible (like > disabling TCP sequence number analysis), but others run into so much problems > there is not much i can do to improve it. > > As far as i can see similar issues can also arise with dissectors available > in public code. For example 802.11n and G.hn allow frame aggregation, > although a bit more constrained than my case. For example 802.11n only allows > aggregation of frames for the same destination MAC address. This might make > it less visible, but it seems to be there none the less. > > I'd like to know if there is any interest to structurally solve these issues > by removing this 1 frame == 1 IP packet assumption. As far as i can see that > has quite some impact on wireshark, so that's probably something i'll need > help with. But most important: Is there any interest to merge such changes? > > Best regards, > Wesley > ________________________________ > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt > u verzocht dat aan de afzender te melden en het bericht te verwijderen. De > Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die > verband houdt met risico's verbonden aan het elektronisch verzenden van > berichten. > > Ministerie van Justitie en Veiligheid > > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. The State accepts no > liability for damage of any kind resulting from the risks inherent in the > electronic transmission of messages. > > Ministry of Justice and Security > > _______________________________________________ > 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
