> -----Original Message-----
> From: Richard Sharpe [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, August 26, 2002 8:25 PM
> To: Allen, Michael B (RSCH)
> Cc: Luke Kenneth Casson Leighton; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
> Subject: RE: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly
>Zero Term'd
>
> On Mon, 26 Aug 2002, Allen, Michael B (RSCH) wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Richard Sharpe [SMTP:[EMAIL PROTECTED]]
> > > Sent: Monday, August 26, 2002 4:28 PM
> > > To: Michael B. Allen
> > > Cc: Luke Kenneth Casson Leighton; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > Subject: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Properly Zero
>Term'd
> > >
> > > On Mon, 26 Aug 2002, Michael B. Allen wrote:
> > >
> > > > On Mon, 26 Aug 2002 10:24:09 +0000
> > > > Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > On Sun, Aug 25, 2002 at 10:02:49PM -0400, Allen, Michael B (RSCH) wrote:
> > > > >
> > > > > > Clients should not check for *two* zero bytes after the Primary Domain
>field Unicode string
> > > > > > in SMB_COM_SESSION_SETUP_ANDX. You may only get *one* 0x00 byte. I'm almost
> > > > > > glad this is a bug in Win2K, I thought this was a bug in jCIFS. At least I
>have two articles of
> > > > > > evidence suggesting the bug is with Win2K. One is inlined here and the
>other is a PNG of a
> > > > > > pcap.
> > > > > >
> > > > > > Aug 21 06:58:52.472 - bad string
> > > > > > 00000: FF 53 4D 42 73 00 00 00 00 98 01 80 00 00 00 00 |?SMBs...........|
> > > > > > 00010: 00 00 00 00 00 00 00 00 05 88 56 34 01 F8 04 00 |..........V4.?..|
> > > > > > 00020: 03 75 00 81 00 00 00 58 00 7C |.u.....X.|
> > > > > len1 = 0x58; len2=0x7c ^^^^^ ^^^^^
> > > > > > 57 00 69 00 6E 00 W.i.n.|
> > > > > > 00030: 64 00 6F 00 77 00 73 00 20 00 35 00 2E 00 30 00 |d.o.w.s. .5...0.|
> > > > > > 00040: 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00 |..W.i.n.d.o.w.s.|
> > > > > > 00050: 20 00 32 00 30 00 30 00 30 00 20 00 4C 00 41 00 | .2.0.0.0. .L.A.|
> > > > > > 00060: 4E 00 20 00 4D 00 61 00 6E 00 61 00 67 00 65 00 |N. .M.a.n.a.g.e.|
> > > > > > 00070: 72 00 00 00 44 00 49 00 56 00 49 00 4E 00 45 00 |r...D.I.V.I.N.E.|
> > > > > > 00080: 00 30 |.0
> > > > >
> > > > > 0x58 length ends here.
> > > > >
> > > > > well, whoopidedoo, that happens to be absolutely spot-on.
> > >
> > > Ummm, since SMBs are little endian, 00 58 is a large BCC. Much larger that
> > > 0x58.
> > >
> > > As well, ISTM, 00 7C is the first part of the Native OS: It looks like |.
> > >
> > His little pointers were just wrong. It's really 58 00 and 7C although I'm not
>sure
> > what len2 means. He's right in that the byte count cuts off the pd field.
>Still a
> > stepchild of a packet if I ever saw one.
>
> At the risk of getting into a pissing contest, the SMB shown looks like a
> session setup and X response with a chained command.
>
Yes, read the note below the hexdump in my original message.
> The 00 57 are in the correct place for the BCC, they just look like they
> are in big endian format.
>
Nope. Look at the PNG of Ethereal in my OP. The packet may be messed up
but it's definately not suffering from endian-inversion.
> The next two bytes actually look like padding.
>
> At least that is what it looks like when comparing it to NT4 and W2K
> traces I have.
>
> Of course, I could be wrong. Where did the packet come from?
>
I captured jCIFS doing a NetServerEnum. I'll send you the pcap. Please don't
crack my password :~)
> Regards
> -----
> Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>
