Ethereal-dev: Re: [Ethereal-dev] packet-smb-pipe

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sat, 4 Aug 2001 18:24:14 -0700
On Sun, Jul 29, 2001 at 01:37:29PM +0000, Pia Sahlberg (well, actually,
    presumably Ronnie Sahlberg, using Pia's account while traveling)
    wrote:
> The patch now correctly matches a response to the Correct request and doesnt 
> just assume every response matches the last read request.

Actually, it didn't bother checking the conversation, so it didn't
necessarily match things; the old code *did* include the conversation,
and wasn't assuming every response matches the last read request (it was
matching based on the MID and the conversation; the CIFS spec on the
SNIA site seems to indicate that the MID plus the PID must be used, so I
changed the transaction request/response matching code to check both MID
and PID).

> The patch correctly handles when lanman inserts an extra pad byte between 
> the parameters and the list of servers/shares in netshareenum-response and 
> netserverenum2-response.

Nope - neither the old nor the new code correctly handled all the
captures I have.  The correct way to do it is to use the parameter and
data offsets to point to the parameters and the data, not to check the
offset after the last parameter to see if it's odd or not.

> The only calls implemented are netshareenum,netserverenum2.
> The other calls in the original implementation could not be converted to 
> tvbuff and were removed. As soon as I, or anyone else, gets capture files 
> with any other calls, the remaining calls can be implemented.

I have captures with almost all of them, and implemented them, along
with one that I don't have but that's documented in one of the "draft of
an Internet-Draft" documents from the old CIFS mailing list.

> Lots of functionality was removed (all calls except netshareenum 
> netserverenum2) but I think it was nessesary, the other calls could not be 
> converted in their current implementation.

I will look at re-implementing the ability to handle calls for which we
don't have explicit dissectors.

I've checked in code based on the patch that

	uses the core SMB dissector's transaction request/response
	matching code rather than adding its own (if the core
	dissector's code isn't matching correctly, it should be fixed,
	not worked around, given that stuff in the core dissector uses
	it);

	includes dissectors for all the remote API calls in the captures
	I have, plus the one in the spec for which I didn't have a
	capture;

	uses the data offset to find the beginning of the data, rather
	than inserting padding based on the offset at the end of the
	parameters;

	fixes various other problems.