Per - Frank Singleton
> Perhaps there is another way, but what I want is
> something like..
>
> c = conversation_new( &pi.src, &pi.dst, PT_TCP,dyn_port, &anyport,
> NULL);
>
> Where I dont care where the dest port is, only if the
> if I get any packet to or from the new 1 dynamic port
> allocated on my machine.
>
> ie: any packet from port "dyn_port" on my local
> machine to "anyport" on a remote machine
> should be a conversation.
>
> I took a look at the converstaion code and it apppears
> to check both ports.
You are correct, the conversation code is setup to handle traffic
from/to a pair of hosts and ports, it doesn't do what you want.
Now you need to look at the packet-rpc.c code, it uses the heuristic
dissector scheme to determine if the sub-dissector handled the packet.
As a matter of a fact it does a conversation lookup based upon the
destination address, destination port, and source port. Check the
dissect_rpc function and the RPC_REPLY section of the case statement.
This does lead into something I have thought about, we have a HTTP
server that is configured on port 88, so the kerberos dissector not
the http dissector called. It would be nice to be able to specify
the protocol based upon an address and port, sort of a 'one sided
conversation' (monologue?). This is what Frank is looking for.
The basic idea is to create a conversation with either source or
destination values set to null. For example, set the destination to
null. During the conversation lookup routine check for a full
conversation, match both source and destination. Then check for a
'one sided conversation' by testing both source and destination
as the destination value with the source set to null. The fits into
the current conversation code and shouldn't impose to much overhead
during the conversation lookup.
Long term, users could use this feature to define the protocol for
non-standard ports on their servers and ethereal would correctly
dissect the traffic.
Jeff Foster
jfoste@xxxxxxxxxxxx