["Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>]

OK.

I will update the patch and repost it.

----- Original Message -----
From: "Guy Harris"
Sent: Monday, January 21, 2002 1:19 PM
Subject: Re: [Ethereal-dev] dcerpc patch, request-response matching update
and persistent data pointer


> 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.
>
> (The same, BTW, applies to ONC RPC XIDs, but Sun's ONC RPC client -
> which is, I suspect, the source of most of the ONC RPC sessions in
> captures I've seen, either directly or as the result of other OSes
> basing their client code on code from Sun - tends not to reuse XIDs
> quickly.)
>
> We may have to do with DCE RPC calls and responses something similar to
> what we do with SMB requests and responses, with matched and unmatched
> hash tables, to handle this.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev