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.