Guy Harris <guy@xxxxxxxxxx> writes:
> > I have a protocol that allows a single machine to host multiple
> > virtual endpoints. Each of these virtual endpoints has a unique name
> > associated with it. The unique name is always the same between runs.
> > The port number that is used to demux the flows is not. The user
> > would like to see the logical name rather than the port number since
> > it makes it easier to identify the virtual host in question.
> >
> > Otherwise the user first needs to find the message where the logical
> > name was exchanged and then associated that port number to a
> > particular host. This process has to be repeated everytime a new
> > capture is made.
>
> Then perhaps what *really* needs to be done is to
>
> add a new PT_ value for your protocol's port type;
>
> add a mechanism your dissector can use in order to, when it sees
> the message to which your second paragraph refers, add to an
> internal database that associates names with ports;
>
> add to "col_set_port()" a case for your port type that, if
> "is_res" is set, tries to resolve the port number using said
> database (and presumably falls back on the port number if
> there's no entry in the database);
>
> have your dissector set "pinfo->ptype" to your new PT_ value,
> and sets "pinfo->srcport" and "pinfo->destport" appropriately;
>
> have your dissector register an init routine that, when called,
> clears out the database if it exists (as it's called when a new
> capture file is opened, or when a re-dissection takes place).
>
> Unfortunately, this currently requires that you change the core Ethereal
> code; we really should have a mechanism by which protocols can register
> new address and port types.
This sounds like a better solution.
Perhaps I can implement a generic mechanism. I'll need to look at the
source tomorrow and see what would be required. If anyone has given
this any thought I would be interested in comments and/or suggestions.
--
-Andrew Feren
Cetacean Networks, Inc.
Portsmouth, NH
