>Message: 4
>Date: Thu, 03 Apr 2014 16:14:53 -0400
>From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] overriding dissector for port 8080
>Message-ID: <533DC13D.8010808@xxxxxxxxx>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>On 04/03/14 10:26, John Dill wrote:
>>
>> I have network traffic that uses TCP port 8080 for sending non-http data
>> (on a private network with its own custom application layer on top of
>> TCP an UDP). Is there a recommendation for how to override or remove
>> this dissector? I still have port 80 for http traffic.
>>
>> I can remove port 8080 from the default http dissector TCP port options,
>> and strip 'http-alt' out of services (to be replaced with a different
>> well-known service name). Is there anything else?
>
>You don't have to change the services file unless you don't want to see
>port 8080 translated into "http-alt" in Wireshark.
Yeah, the avionics network architecture defines its own Well Known Services
for several TCP and UDP ports, so I'd have to eventually create a custom
'services' file to document all the ports.
>Removing port 8080 from the HTTP dissector's preference is probably the
>best way. If you have a custom dissector for your protocol, registering
>it for port 8080 *might* override the HTTP dissector but it's not
>guaranteed (last I checked). As Alexis mentioned Decode-As would
>override it.
Unfortunately, I do not have the TCP dissector component working yet (the
message structure has to be somewhat reverse engineered), so I'll have to
try that out when I get it working.
>> I also noticed a disabled_protos.[ch], so maybe there is a feature to
>> disable other protocols. Is there a feature that could be used to hide
>> protocols I don't need in the Filter Expression (to reduce the list to
>> simplify the interface to users)?
>
>No, I don't think there's a way to simplify what's in the Filter
>Expression dialog short of removing dissectors from Wireshark (probably
>more effort than it's worth).
The only reason would be to simplify the interface for test engineers who
like to streamline their process (it would remove the need to constantly
type the protocol abbreviation). It would happen at the end of the
development cycle if at all.
Thank you (and to Alexis) for your feedback.
John Dill
<<winmail.dat>>
