The problem with WAP is that with these redirects the only thing you know
will remain the same is the destination socket (not necessarily the source
!). But with this conversation trick, you will never be able to parse
packets if you start to capture *after* the redirect occurred. With WAP
this redirect might only happen once a month or once a year or even worse...
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...
Any other solutions are welcome!
Regards,
Olivier
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Monday, February 26, 2001 9:17 PM
To: Biot Olivier
Cc: 'ethereal-dev@xxxxxxxxxxxx'
Subject: Re: [Ethereal-dev] Registering nonstandard protocol ports w/o
recompi ling
> Some UDP-based protocols like WAP 1.x have a "session redirect" option
> resulting in this session using another socket, resulting in the loss of
> decoding (unregistered port). Today the only way of achieving this, is by
> modifying the code and hard-coding the possible redirect ports into the
> source code.
Umm, if I understand correctly your description of the way the
redirection happens, that's *not* the only way to do that - you can,
instead, create a new conversation for the network addresses and port in
question, as, for example, the RTSP dissector does - see, for example,
"rtsp_create_coversation()", in "packer-rtsp.c".
> I would like to introduce a simple but effective method to
> achieve the goal above:
> Use environment variables named 'Ethereal_PROTO_port_SUBPROTO' like
> 'Ethereal_udp_port_wtls_wsp' for this purpose.
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.
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.
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).