[jcifs] SamOEMChangePassword works

[Tony Thompson]

> > I feel that I may be overstaying my welcome but, it seems like every time
> > I  make progress, I run into another wall. I now have two traces that I can
> > compare and they are definately different.
> 
> You  got  it!  Is  this  SamOEMChangePassword  pcap  of Windows to Windows?
> Regardless your jCIFS RAP works. Good job. The rest is easy. I'll explain.

The pcap that I sent was a SamOemChangePassword from a Win98 client to a Wint4 server.  BTW, I don't feel like the rest is easy...

> > According  to the cifsrap2.doc file, the things that I should be writing
> > into the transaction request parameters section are: 
> > 
> > - a 16 bit function number, in this case 214
> > - the parameter descriptor string "zsT"
> > - a null terminated ASCII string that represents the name of the user
> > - a word with a value of 532 representing the size of the data buffer
> > 
> >  The  problem is I think I also have to write in a data descriptor string
> > "B516B16"  even  though it didn't say to in the document. So, I have almost
> > the  same  information  that  is in the Win98 pcap except the word with the
> > value of 532. The Win98 capture has a value of 814. 
> 
> WARNING:  Do not believe *anything* you read in the documentation, see in a
> pcap,  or  hear through the grapevine. Even the hexdumps in the low pane of
> Ethereal can be wrong.

< * snip * >

> >  There  are other things that are not the same in the traces that I don't
> > know  how to rectify. In the Win98 pcap, it has a parameter count of 20. In
> > the  jCIFS capture, it has a parameter count of 22. There are several other
> > things  but  some  of  them  may dependent on each other (i.e. if I fix one
> > thing the rest will correct themselves). 
> 
> As you probably know by now, every SMB has a 'ParameterWords' section and a
> 'Bytes'   section   (also   called   Data  section).  See  the  section  on
> 'Transactions'  in  the CIFS spec. So the ServerMessageBlock superclass has
> four abstract methods: 
> 
>     abstract int writeParameterWordsWireFormat( byte[] dst, int dstIndex );
>     abstract int writeBytesWireFormat( byte[] dst, int dstIndex );
>     abstract int readParameterWordsWireFormat( byte[] buffer, 
>                                         int bufferIndex )
>                                         throws IOException;
>     abstract int readBytesWireFormat( byte[] buffer, 
>                                         int bufferIndex )
>                                         throws IOException;
> 
> To  implement  any  SMB  message you just have to fill in these methods and
> give that object to send or sendTransaction. The top level writeWriteFormat
> method  will  call writeParameterWordsWireFormat and write the return value
> of   that   into  the  ParameterCount  field.  It  will  do  the  same  for
> writeBytesWireFormat  writing the return value from that into the DataCount
> field.     Same     principle    for    readParameterWordsWireFormat    and
> readBytesWireFormat.  In  other  words,  that  22 is being returned by your
> writeParameterWordsWireFormat implementation. Have it return 20 instead. If
> the  accounting  doesn't  add  up,  that might be a further clue as to what
> constitutes a valid message and help to reverse engineer the precise format.

The methods that I am using are writeParametersWireFormat() and writeDataWireFormat() not writeParameterWordsWireFormat() and writeBytesWireFormat().  I also can't write 20 instead of 22 and get anything in a pcap that makes sense.  I am using a NG Sniffer instead of Ethereal to look at the traces (the decodes are much better) and I am still having a hard time figuring out where my issues are coming from.

One thing that I can't easily reconcile is the fact that the parameter descriptor string that I am sending is "zsT" but the only parameters that I send are:

- a null terminated string for the user ID (this is the "z" part)
- a word with a value of 532 that represents the size of the data buffer (this is the "T" part)

Where did the "s" part go?  The pcap from the Win 98 machines doesn't have any extra bytes in there that would correspond to the "s" part either but, the word is not 532, it is 814.  The Sniffer reports that word as a 2 byte pad in the Win98 trace.

There is a "parameter words" field in the transaction header that is partially wrong in the jCIFS trace as well.  I don't have a clue where any of that information came from but, it is wrong.

Mike, would you mind having a look at the two trace that I sent and give me an idea where I can go to fix some of the differences?

Trying to control my frustration because Micro$oft'$ stand on your head and spin a plate on one toe dance is getting old,
Tony