>> I checked the conversation.c code because it sounded like something I
>> could use in a socks dissector. Just one problem; how does this
>> function on a trace that does a router hop ? For example:
>>
>> router ----------> hub -----------> server (10.2.1.2)
>> (10.1.1.1) \
>> (10.2.1.1) \--------> client (10.1.1.2)
>> \
>> \------> ethereal computer
>>
>> When I looked at adding "conversations" I realized that this would be a
>> problem unless I had both the DLC and IP addresses in the key.
>
>Eh?
>
>The conversation is between host 10.1.1.2, port XXX, and host 10.2.1.2,
>port YYY. It's irrelevant whether the packets travel through host
>10.1.1.1/10.2.1.1, or host 66.66.66.66, or host 137.1.1.1, or... in the
>process of getting between 10.1.1.2 and 10.2.1.2 - different packets in
>the same conversation could well travel through *different* routers.
I know this is an unusual setup... so let me iterate
1) The network is subnetted into class 'B networks. So the traffic
from 10.2.1.2 to/from 10.1.1.2 has to hit the router to hop acrossed
the subnets.
2) You have a "conversation" between 10.2.1.2 and 10.1.1.2.
Consider a packet traveling from 10.2.1.2 to 10.1.1.2:
As it leaves 10.2.1.2 for the router, the ethereal sniffer will see it.
The router performs the subnet-subnet hop.
As it travels from the router to 10.1.1.2 the sniffer will see it again.
So you are trying to dissect a conversation and it's echo (so to speak).
To eliminate this situation and make the sniffer see two copies of the
same conversation, not one conversation with two copies of every packet,
you would have to consider both DLC (layer 2) and IP (layer 3) addresses
in the conversation hash.
Jeff Foster
jfoste@xxxxxxxxxxxx