Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Registering nonstandard protocol ports w/o rec ompi ling

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 2 Mar 2001 11:41:26 -0800 (PST)
> If the redirect ports are known, then it is not really very difficult to
> incorporate them into the port registration code by means of the proposed
> tokenizer code.  Or I have to be able to choose a dissector for a selected
> packet in ethereal...

Well, as I said in my mail, the ability to do that is in the current CVS
version of Ethereal, and will be in the next release:

> If you're going to make it something the user has to explicitly specify
> when running Ethereal, note that the current version of Ethereal in CVS
> has the ability to select a packet and pop up a dialog box allowing the
> user to specify that the
> 
> 	Ethernet protocol for that packet, if any;
> 
> 	IP protocol type for that packet, if any;
> 
> 	TCP or UDP source, destination, or both ports, if any;
> 
> should be dissected as a particular protocol.
> 
> At some point, we'll probably support controlling that from the command
> line, as well, for the benefit of Tethereal.

and, in the future, there will probably be a way to edit the list of
port registrations:

> A future possibility (requiring some more infrastructure work) could be
> to have the registration of protocols with "ports" be controlled by a
> configuration file, and to provide a UI to let the user control the
> regisration.

but, even now, you could modify the WAP dissectors to register
"preferences" with port numbers:

> Dissectors can register "preferences" that allow the user to, using the
> "Edit->Preferences" menu item (or the "-o" command-line flag), change
> various options for the dissector - including the port it's registered
> on.  Some dissectors register their ports as preferences in this
> fashion, which provides another way for a dissector to have its ports
> changed at run time.  The mechanism mentioned in the previous paragraph
> might replace that, so that dissectors wouldn't have to explicitly
> register ports as preferences (there would still be other preferences
> that some of them would register).