[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