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

[Eric Glass]

The attached appears to work as a rudimentary named pipes transport
for SQL Server 2000 (based on the ncacn_np transport for Jarapac);
usage would be:

    SqlTransport transport = new SqlTransport("mysqlserver");
    byte[] sendBuffer = <data you want to send>
    transport.write(sendBuffer, 0, sendBuffer.length);
    byte[] receiveBuffer = new byte[0xffff]; // buffer for receiving data
    transport.read(receiveBuffer, 0, receiveBuffer.length);

I just replayed a couple of connection setup packets I sniffed from an
ODBC connection establishment to test it; the first packet looks to be
some sort of "hello", with some handshaking reply from the server. 
The second packet appears to be the SQL Server authentication, which
got me back a message with a bunch of database info ("Changed database
context to MYDB", some other stuff).


Eric


On Thu, 15 Jul 2004 23:50:08 -0400, Michael B Allen <mba2000 at ioplex.com> wrote:
> On Thu, 15 Jul 2004 22:12:21 -0500
> ddkilzer at kilzer.net (David D. Kilzer) wrote:
> 
> > I've now got a full packet returning via Read AndX Response!!  But I'm
> > getting an IndexOutOfBoundsException now (such is progress):
> >
> > java.lang.IndexOutOfBoundsException
> >       at java.io.PushbackInputStream.read(PushbackInputStream.java:143)
> >       at
> >       jcifs.smb.SmbComReadAndXResponse.readBytesDirectWireFormat(SmbComRe
> >       adAndXResponse.java:68) at
> >       jcifs.smb.AndXServerMessageBlock.readAndXWireFormat(AndXServerMessa
> >       geBlock.java:266) at
> >       jcifs.smb.AndXServerMessageBlock.readWireFormat(AndXServerMessageBl
> >       ock.java:103) at jcifs.smb.SmbTransport.run(SmbTransport.java:444)
> >       at java.lang.Thread.run(Thread.java:536)
> >
> > A quick debugging session showed that the code is dying in line 3 of
> > SmbComReadAndXResponse.readBytesDirectWireFormat() because 'b' is
> > declared as byte[8] when 175 bytes of data are available to be read.
> > Oops!  I don't have time to track that down just now, but I'm hoping
> > that one of the developers can provide a patch fairly easily (or else
> > I'll go play with JCIFS some more tomorrow).
> 
> That's kinda strange because b is SmbTransport.rcv_buf which is *hard
> coded* with a size of 0xFFFF:
> 
>    private static byte[] rcv_buf = new byte[0xFFFF];
> 
> > BTW, the last change I made (which triggered the above exception) was to
> > hard-code maxCount and minCount to 512 in the constructor and setParam()
> > methods of SmbComReadAndX:
> >
> >   this.maxCount = minCount = 512;
> >
> > Turns out that SQL Server 6.5 will only send back the number of bytes
> > requested by one (or both) of those fields, so when I was getting the
> > other error message earlier, I was only getting 1 byte back instead of
> > the whole TDS packet!
> 
> I don't follow.
> 
>  1) What does your jCIFS code look like to access the IPC resource?
>  2) Send captures.
> 
> It sounds like the pipe needs to be in a certain message mode that isn't
> quite set right. There are many options for pipes. If they're not right it
> might half work like you're seeing. I assume you have seen our named pipe
> docs?
> 
>  http://jcifs.samba.org/src/docs/pipes.html
> 
> Mike
> 
> 
> 
> --
> Greedo shoots first? Not in my Star Wars.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SqlTransport.java
Type: text/java
Size: 3063 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040716/ed6518c5/SqlTransport.bin