[jcifs] Even-byte-alignment padding in Write AndX Request
Eric Glass
eric.glass at gmail.com
Fri Jul 16 01:38:39 GMT 2004
If you can send a packet trace (directly to Mike and/or myself) we can
analyze it a bit and see if anything pops out.
Eric
On Thu, 15 Jul 2004 19:48:22 -0500, David D. Kilzer <ddkilzer at kilzer.net> wrote:
> On Thu, Jul 15, 2004 at 03:55:01PM -0400, Michael B Allen wrote:
>
> > On Thu, 15 Jul 2004 11:57:00 -0500, David D. Kilzer wrote:
> >
> > > [...]
> > > I have hacked up jTDS so that it emits a TDS 4.2 logon packet (which is
> > > the data after the Write AndX Request) that is identical to what the SQL
> > > Enterprise Manager tool sends. Unfortunately, there are still a few
> > > minor differences between the two packets:
> > >
> > > - The SQL Enterprise Manager packet has the TDS 4.2 logon packet
> > > even-byte-aligned by including a padding byte of 0xEE between the
> > > Write AndX Request and the data (TDS 4.2 logon packet).
> > >
> > > [...]
> > >
> > > - Fields that differ in the Write AndX Request:
> > >
> > > Fields SQL-E-M JCIFS
> > > ------------- -------- --------
> > > Reserved: FFFFFFFF 00000000
> > > Write Mode: 0x0008 0x0000
> >
> > Mmm, Ethereal claims 0x0008 is "write start". We don't do anything with
> > that flag. Try setting writeMode = 0x0008 in the SmbComWriteAndX.java
> > constructor (temporarily just to see if it works).
>
> I set writeMode to 0x0008, but it made no effect on the behavior of SQL
> Server 6.5.
>
> > > Remaining: 512 0
> >
> > Probably doesn't matter.
> >
> > > Data Offset: 64 63
> > > Byte Count: 513 512
> > > Padding: EE (n/a)
> >
> > Alignment could be an issue. Try uncommenting
> > jcifs/smb/SmbComWriteAndX.java:110 where the comment reads "Netware
> > doesn't like this". Make it 0xEE if you like. I don't think it should
> > make any difference.
>
> I added a 1-byte alignment byte of 0xEE. This caused JCIFS to throw a
> different exception:
>
> jcifs.smb.SmbException: The pipe is being closed.
>
> At this point, I took a look at previous SMB packets, and noted the
> following:
>
> - The Tree Connect AndX Request/Response occur with NO session using
> SQL Enterprise Manager (SQLEM), but within a session using JCIFS.
> (I'm using an "anonymous" NtlmPasswordAuthentication with domain,
> user and pass set to empty strings.) The only difference in the
> Tree Connect AndX Request is:
>
> Fields SQLEM JCIFS
> ------------- -------- --------
> Flags: 0x0008 0x0000
>
> - The NT Create AndX Request have more differing fields:
>
> Fields SQLEM JCIFS
> ------------- ---------- ----------
> AndXOffset: 57054 0
> Create Flags: 0x00000016 0x00000000
> Access Mask: 0x0002019f 0x0000008b
> Share Access: 0x00000001 0x00000007
> Disposition: 3 1
>
> Thanks for any more insight you have, or suggestions of what to try.
>
> I'm going to sniffing a working driver next (running the same test code)
> to see what it does differently. Comparing the SQLEM output to the
> output running the AsTest.java class from jTDS is a bit like comparing
> apples to oranges.
>
> Dave
>
More information about the jcifs
mailing list