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
digital-signature.txt
Description: PGP signature
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
