On Mon, Sep 25, 2000 at 01:19:13PM -0500, Jeff Foster wrote:
>
> I think that we should allow filtering on these proxied port to be
> consistent. The question is - how to add the tcp.port item to the
> protocol tree for the proxied ports. Because the hf_* values are
> static we must do it in the packet-tcp.c file. I am suggesting that
> we add and export a routine set_tcp_hidden_port in the packet-tcp.c
> file. Then the proxy protocols can call this routine to create the
> hidden protocol tree for tcp.port.
>
> As I think about this more, this argument can be extended to the
> tcp.srcport, tcp.dstport, ip.addr, ip.srcaddr, and ip.dstaddr.
>
> Lookout, the can is open, the worms are loose!!
This echoes back to Uwe's problem of being able to put nfs.filehandle (or
whatever the particular field was) in a non-nfs protocol branch. Remember,
the display filter routines look for fields only in their protocol
branches, so there needs to be an "nfs" branch in order for "nfs.xxx"
to be searched for.
I believe the best way to do this would to make proto_tree have a hidden
branch that acted as an "always search here" branch. That is, provide
a "protocol" that would serve as a universal parent for any field.
Then "tcp.port" and "nfs.filehandle" could be put there.
What worries me though is the extra copying. For example, in the NFS example,
Uwe would use proto_tree_add_item() calls to add the data to the visible
portion of the tree, and then again for the inivisible, always-searched portion
of the tree. That's not goo.
Hmmm, I guess another way would be to mark certain protocols, like "rpc"
(was it RPC that had the nfs.xxx field?) and "socks" as able to contain fields
that aren't registered to them. Then the display filter code would always search
the "socks" branch for *any* field. But it would find a "tcp.port" embedded
in the socks branch.
--gilbert