Hi,
This is really a conceptual problem. A port number is to be associated
with its service. That concept break when talking about dynamic data
ports, these are negotiated 'by other means'.
Wireshark tries to pick up these negotiations, like SDP, and configure the
dissectors accordingly.
Otherwise it tries to heuristically determine the protocol. That is the
case with the DirectPlay protocol, its not related to a specific port as
you state.
These methods aren't perfect. Therefor the dissectors are outfitted with
preferences to help make Wireshark make the right choices. In this case
the UDP preference "Try heuristic sub-dissectors first" might help, if
switched off. Another may be of the RTP dissector, "Try to decode RTP
outside of conversations".
Yet another option is to select the DirectPlay protocol in the packet
details pane and select "Disable protocol..." from the righthand click
menu. That knocks out the DirectPlay dissector for this session. Or you
can disable it completely from the Analyze|Enabled Protocols... menu
option.
Bottom line is: protocol usually give poor support for solid heuristics.
With more and more protocols being dissected in Wireshark these collisions
are bound to happen more often.
Thanx,
Jaap
> Since Wireshark V1.0.0 (on Windows XP SP2) an RTP packet using UDP port
> number 26642 is being decoded as DPLAY. This port number is in the range
> used by Cisco for RTP. In V0.99.8 and before it has always been decoded as
> RTP.
>
> Obviously I can do a "Decode As" for the time being.
>
> I assume this is a bug, and if so I will raise it on there when bugzilla
> is back up again.
>
> Keith French.
