Wireshark mailing list archives
Re: Dissecting UDP conversations that encapsulate UDPdata
From: "Anders Broman" <anders.broman () ericsson com>
Date: Wed, 11 Nov 2009 12:54:34 +0100
Hi, I'm not intierly sure how this is supposed to work but my understanding is that one of the heuristic Conditions is that the "fp structure" is filled in/attatched to the packet. Does the code filling in this structure know the IP address and port pair going to be used for the UDP transport? If so that code could set up a conversation and set the UDP conversation dissector. That means that for that UDP IP and port par "dissect_fp..() would be called directly not the heuristic. I asume that any IP payload traffic carried inside of this UDP reaffic would have other IP address port combinations? With this setup there is no need for a FP heuristic dissector at all. As for thye other question regarding the trace attached to the bug is there enough iformation in the (NBAP?) Message(s) to fill in the fp struct if so code to do that could be added to the NBAP dissector + setting up of a conversation. Regards Anders -----Original Message----- From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Tobias Witek Sent: den 11 november 2009 11:33 To: wireshark-dev () wireshark org Subject: [Wireshark-dev] Dissecting UDP conversations that encapsulate UDPdata Hello, I am currently trying to extend the UMTS FP protocol to also handle FP frames sent via UDP. To avoid modifications in the UDP dissector, my plan was to use a heuristic to detect the first UDP packet of each stream that contains FP and assign a conversation dissector to the whole conversation. The problem is that these frames can in turn contain UDP (e.g. DNS queries). The solution outlined above would dissect these as FP again, if I understand correctly (as a separate conversation). As far as I see, I would need a way to let the heuristic determine that the current frame was already parsed as FP (respectively, is already part of a different UDP conversation) and should not be treated as FP. Currently, I see no way to do this and would be very happy about any suggestions! Regards, Tobias ________________________________________________________________________ ___ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Dissecting UDP conversations that encapsulate UDP data Tobias Witek (Nov 11)
- Re: Dissecting UDP conversations that encapsulate UDPdata Anders Broman (Nov 11)
- Re: Dissecting UDP conversations that encapsulate UDPdata Tobias Witek (Nov 11)
- Re: Dissecting UDP conversations that encapsulate UDPdata Anders Broman (Nov 11)