[jcifs] Even-byte-alignment padding in Write AndX Request

[Michael B Allen]

On Thu, 15 Jul 2004 19:48:22 -0500
ddkilzer at kilzer.net (David D. Kilzer) wrote:

> 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.

It could be working. At least as far as jCIFS is concerned this might be
normal behavior for SQLEM if your "login message" isn't quite right. The
fact that you elicited a different behavior is noteworthy.

> 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 don't think this will work too hot but try setting sessionSetup =
true in the jcifs/smb/SmbSession.java constructor.

>     (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

Mmm, that's a strange bit. I'm only aware of bit 0 which if on means to
"diconnect tid".

> 
>   - The NT Create AndX Request have more differing fields:
> 
>     Fields        SQLEM      JCIFS
>     ------------- ---------- ----------
>     AndXOffset:   57054      0

Meaningless value even if there was an AndX message that followed. Should be
0. Obviously ignored.

>     Create Flags: 0x00000016 0x00000000
>     Access Mask:  0x0002019f 0x0000008b

0x2019f is:

FILE_READ_DATA 
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
READ_CONTROL

which is a pretty wacky access mask for a database pipe. Try overrideing
desiredAccess = 0x0002019f in src/jcifs/SmbComNTCreateAndX.java
constructor.

>     Share Access: 0x00000001 0x00000007
>     Disposition:  3          1

These mean:

  1 - Open the file or fail if it does not exist
  3 - Open the file or create it if it does not exist

I think you could definately make this work. At least I'm confident
you can make the pipe communication work. If we need to make
some adjustments at our end we'll do that. Just keep doing what
you're doing and try hacking hardcoded values as necessary (e.g. in
jcifs/src/SmbComNTCreateAndX.java constructor) to see if you can get it
to work. Obviously if all of the flags and such are the same it WILL work.

If you send me a capture [1] of the desired behavior and a capture of
jCIFS failing I might have some better input.

Mike

[1] http://jcifs.samba.org/capture.html

-- 
Greedo shoots first? Not in my Star Wars.