[jcifs] Very minor oddity testing SmbComTreeConnectAndX.java

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> Sent:	Thursday, July 25, 2002 9:33 PM
> To:	Allen, Michael B (RSCH)
> Cc:	jcifs at samba.org
> Subject:	Re: [jcifs] Very minor oddity testing SmbComTreeConnectAndX.java
> 
> On Thu, Jul 25, 2002 at 06:21:07PM -0400, Allen, Michael B (RSCH) wrote:
> :
> > > Later in the code there's this:
> > > 
> > >                 dst[dstIndex++] = (byte)0x00;
> > >                 dst[dstIndex++] = disconnectTid ? (byte)0x01 : (byte)0x00;
> > > 
> > > I think the order of those two lines needs to be reversed.  The result is 
> > > showing up on the wire as 0x0001.
> > > 
> > 	Then that looks right. Bit zero would be 0x0001.
> 
> SMB is little-endian, so 0x0001 on the wire translates to a host value of
> 0x0100.
> 
	Well, 0x0001 on the wire will translate to 0x0001 on the host regardles of
	what endianess is used. 0x0001 suggests a 16bit value in which the lowest
	bit is on and equates to 1 decimal. 0x0100 suggests the 16th bit is on and
	equates to 256 decimal. Perhaps you meant to write 0x01 followed by 0x00?
	The code snipplet you provide doesn't provide enough context but if the two
	bytes represented by it refer to the two bytes in the flags short value then
	you are correct and the two lines should indeed be reversed.

> When I turned on disconnectTid (by setting it to True and recompiling)
> Ethereal would show a numeric value of 0x0100 (seen on the wire as {0x00,
> 0x01}) and tell me that the disconnect bit was zero (false).  When I
> swapped the order of those two lines I got {0x01, 0x00} on the wire, which
> Ethereal read as 0x0001 and told me that the disconnectTid bit was true.
> 
	Yes. then the two lines probably need to be reversed but you would have to
	check some windows traces to rule out the possibilty of a bug in Ethereal
	or consider more code surrounding the two lines in question.

> It's an endian thing.  Ick.
> 
> > > PS.  As far as I can tell W/95 ignores that bit in a TreeConnect... which 
> > >      makes sense.  Why would there be a disconnect bit in a tree connect 
> > >      request?  Am I missing something or is this just silliness in the
> > >      SMB?
> > > 
> > 	It means after servicing the AndX message to disconnect. It's an
> >       optimisation; in one operation you can tree connect, perform some
> >	command (e.g. delete), and then disconnect.
> 
> So, if I understand correctly, the disconnect is delayed until the end of
> the AndX chain.
> 
> In an AndX block like this:
> 
>   {
>   SessionSetupAndX
>   TreeConnectAndX (disconnect == true)
>   CreateAndX
>   }
> 
> the disconnect would actually follow the CreateAndX block.  If that's the 
> way it works, that makes sense.  I suppose it is also useful to have a 
> block like:
> 
>   {
>   SessionSetupAndX
>   TreeConnectAndX (disconnect == true)
>   }
> 
> Which would verify that you had permission to connect, but not return an 
> open TID.
> 
> Am I close here?
> 
> Chris -)-----
> 
> -- 
> Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
> jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
> ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
> OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org