Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Tim Potter <tpot@xxxxxxxxx>
Date: Mon, 19 Nov 2001 09:57:04 +1100
On Sun, Nov 18, 2001 at 12:14:34PM -0500, Todd Sabin wrote:

> > I've added an extra entry to the conversation hash key which should
> > be zero for non-MSRPC DCERPC calls but set to the fid for MSRPC.
> > Hopefully I've done this in a nice transport independent way (I
> > alluded to this in my last message to the list) without making
> > the dcerpc dissector too ugly.
> 
> I'm glad to see someone getting this working, but wouldn't it be
> cleaner to have the SMB layer add this to the conversation info for
> the packet?  I.e., add a port_type PT_SMB, and have the FID be either
> src or dest port (both?), or something along those lines.  Then the
> dcerpc layer shouldn't need to be modified at all because of its use
> of find_conversation, and it would be available to other dissectors,
> should they ever need it.  This is what was suggested to me when I
> first mentioned this problem, but I never found the time to do it.

Hi Todd.  Thanks for the feedback.  I did cringe a bit when changing the
dcerpc layer stuff as it didn't seem the right thing to do.  )-:

I think the problem is that there needs to be an additional field in the 
conversation_key structure.  If we override the destination port that 
might lead to identical keys?  NT seems to start issuing fid numbers
starting at 0x4000 (or is it 0x8000 - maybe that's Samba) for each
TCP connection.

Maybe the conversation_key needs to have a per-port type union that can
hold the fid in the case of PT_SMB?  How do other protocols solve this
problem?


Tim.