[Todd Sabin <tas@xxxxxxxxxxx>]

Guy Harris <gharris@xxxxxxxxx> writes:

> On Sun, Jan 20, 2002 at 03:14:58PM -0800, Guy Harris wrote:
> > Perhaps there's some state your new code is maintaining that's being
> > maintained on a per-connection basis rather than on a
> > per-connection-and-FID basis?
> 
> Actually, it's the old code - call keys were hashing on the conversation
> and call ID, which wasn't sufficient.
> 
> Unfortunately, the conversation, call ID, and SMB FID (if any) isn't
> sufficient, either.  The section on the call_id field in a
> connection-oriented message says
> 
> 	The caller must guarantee that at any time, all call_ids for all
> 	outstanding messages for the same association group are
> 	distinct.
> 
> which is not the same as "the caller must guarantee that call_ids are
> never reused in a session" - and, in fact, another capture I've seen has
> a DCE RPC-over-named-pipe call and response using a given call ID and
> has the next call and response on that same named pipe use the *SAME*
> call ID.

Maybe they were on different association groups?  Were there binds or
alter contexts in between?  Not that it would make the problem go away
either way, it just seems odd that someone would implement a client
like that.  It's easier to just increment by one every call.  Could I
see that capture?


Todd