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.
