Oh,
I just noticed that. :-(
My original patch were supposed to clean up packet-smb.c and smb.h quite a
bit.
Getting rid of all the conversation thingys and also removing request_val
completely
(replacing it with a much smaller and simplified struct)
Then using dissect_transaction_[request|response] for both transaction and
transaction2 calls.
I have never seen a packet exchange as you describe. MS clients usually
(as far as I have seen) monotonically increment MID with 1-0x7f between each
call
and does not reuse MID values until MID has wrapped.
May I ask what client implementation you have seen this behaviour on?
The only times myself has seen MID reused has been in
1, broadcast requests which requires no response (as in browse host
announcement). Always ==0
2, retransmissions
3, cancel requests
Also I have only seen "weird" PID values for when command are exchanged
before a user
is authenticated (session_setup{_andx}), broadcasts or for system services
as
PID==0xCAFE as in NT Transaction/Notify calls.
:-(
Well, well,
looks like the last transaction call to be converted needs a fair bit of
work.
eta for patch not possible to estimate at current time.
----- Original Message -----
From: "Guy Harris" Subject:
Re: [Ethereal-dev] packet-smb big patch
> On Mon, Nov 12, 2001 at 08:10:32PM +1100, Ronnie Sahlberg wrote:
> > I will generate the last part of my smb patches to fix the transaction
call
> > based on current cvs.
>
> BTW, note that the stuff done by "do_transaction_hashing()", where it
> includes frame numbers as part of the hash key, really *is* necessary -
> and should probably be done for all SMB requests and replies; I have at
> least one capture with multiple Transaction2 SMB exchanges in a row, all
> with the *same* MID, PID, UID, adn TID, and all between the same
> machines on the same connection....
>
> (There should perhaps be a hash table matching requests and replies,
> using the same hashing that "do_transaction_hashing()" does now, with
> the structure associated with each hash table entry not being a
> full-blown "smb_info" structure, but something with just enough to
> supply the information that can't be extracted from the SMB itself, as
> well as a "void *" that can be used to point to other data, e.g. the
> transaction stuff.
>
> That'd mean you'd only have the transaction stuff in the hash table
> entries for transactions.)
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
