Hi,
I think you are referring to this one:
Send from my iPhone On 23 Sep 2025, at 21:20, Roland Knall <rkn...@gmail.com> wrote:
Hi Eugene
A very similar example for this is the way the openSAFETY dissector works. For that there are examples in the wireshark trace repository. Also, if you search through Wireshark-dev, there was a discussion ages ago between Evan Huus and myself and I also think Guy Harris, about what would be needed from a pure epan pov to achieve such a thing. (for instance, how would you handle duplicate information for the sub packages so that our other stuff like filters would still work correctly).
I am all for pursuing that idea again.
cheers 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
|
