Wireshark mailing list archives

Re: Dissecting UDP conversations that encapsulate UDPdata


From: Tobias Witek <witek () ftw at>
Date: Wed, 11 Nov 2009 13:23:03 +0100

The code filling the fp_info structure does not know the UDP Port / IP
Address pairs, no. I realize that this would make things easier.

In the case of FP being sent via Ethernet, the FP frames are carried
within UDP. Port assignment is arbitrary, that is, the first UDP layer
encountered always contains FP, the 'upper' UDP layer contains the
payload. At least this is my understanding how things work.

Concerning the attached trace: The problem is that for correctly
dissecting the FP frames, additional information not necessarily
available from the packets contained in the trace are required (e.g.
detecting which type of FP channel is contained within a certain
connection).

Thanks!

Tobias

Anders Broman wrote:
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

___________________________________________________________________________
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: