[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 10:15 PM
> To:	Allen, Michael B (RSCH)
> Cc:	jcifs at samba.org
> Subject:	Re: [jcifs] Very minor oddity testing SmbComTreeConnectAndX.java
> 
> It could be a terminology thing.  When I use the word "value" or write
> 0x0001 I mean an short integer with a value of 1.  In SMB, a value of
> 0x0001 would be written on the wire as two bytes, like so: { 0x01, 0x00 }.
> I use the bracket notation to suggest an array of bytes rather than a 
> short int value.  Hope that clears things up.
> 
> > 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.
> 
> Yes, that's what they're about.
> 
> > > 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.
> 
> Understood.  Reading the raw hexdump, however, I also see { 0x00, 0x01 }.
> Just a bit more evidence.
> 
	The "raw" hexdump from where? If you're looking at Ethereal it's not raw. It's
	peiced together from the decoded members and I've found on one very frustrating
	occation it was wrong. If you're looking at the jCIFS -Dlog=ALL output that's "raw".