[jcifs] RE: That SMB_COM_CLOSE thing...

[Christopher R. Hertel]

On Mon, Aug 19, 2002 at 10:56:50PM -0400, Allen, Michael B (RSCH) wrote:
:
> But here's something else that looks like it might be broken. You're
> supposed to be able to specify a UTIME in SMB_COM_CLOSE of the "Time
> of last write". I just tried it with NT4 and it didn't work. It
> uses the current time regardless.

I did some digging on this to understand it better before I fiddle with 
it.  Conrad was there and helped a lot.  He had a copy of the X/Open doc 
which was quite useful.

The Leach/Naik drafts and the SNIA doc all say that a value of '0' allows 
the server OS to set the file timestamps.  They do not clarify whether the 
time of last write or the close time should be used.  Server-side file 
caching confuses the issue.

The older X/Open doc says that both '0' and '-1' tell the server to use
its default values.  I note that jCIFS uses -1 and I'm told that this is
what Windows does too (no matter what the newer docs say).

Any other value should be interpreted as a time value to be used instead 
of server time.  I'll have to run your tests to see what happens, but I'll 
probably need to do that when I get home because all of the test boxes 
here are W2K or W/XP.



I'm having some difficulty testing with FileOps.java, and a little trouble
with some of the other example code.  Given how distracted I've been it's
likely to be my own problem.  Guidance would be helpful.  I'd like to get
a few people to test these things out so that we can verify them and so
Mike can get some additional sources for feedback if I flake out.  I'm
here at the CIFS conference and that means that I'm more distracted than
ever.

Things I've noticed:

examples/SmbShell.java:
Looks as though it's still written to the older AuthHandler and AuthInfo
classes, which have been replaced.  Appears to need an update.

Testing with FileOps.java:

First, I noticed that a URL that includes the username and password
doesn't seem to work:

$ java -Djcifs.properties=cifsconf.prp FileOps smb://crh:secret@favog/tmp
Exception in thread "main" java.lang.NullPointerException
        at jcifs.smb.SmbFile.getCanonicalPath(SmbFile.java:647)
        at jcifs.smb.SmbFile.<init>(SmbFile.java:371)
        at FileOps.main(FileOps.java:66)

I have the username/password in the properties file, and if I leave them
out of the URL string things seem to work fine, for the initial connection
at least.

I do, however, seem to have trouble with a re-connect.  Using FileOps
running against Samba (2.2.3a) I get a working initial connection:

$ java -Djcifs.properties=cifsconf.prp FileOps smb://favog/tmp
okay - delete smb://favog/tmp/JcifsTestOpsDir failed: File not found
okay - delete smb://favog/tmp/JcifsTestOpsDir successfull
okay - smb://favog/tmp/JcifsTestOpsDir does not exist
okay - mkdir smb://favog/tmp/JcifsTestOpsDir successfull
okay - smb://favog/tmp/JcifsTestOpsDir exists
okay - mkdir smb://favog/tmp/JcifsTestOpsDir failed: Cannot create a file
when that file alread exists
okay - created file smb://favog/tmp/JcifsTestOpsDir/foo.txt   
okay - canRead smb://favog/tmp/JcifsTestOpsDir/foo.txt successfull
okay - canWrite smb://favog/tmp/JcifsTestOpsDir/foo.txt successfull
Please change the file smb://favog/tmp/JcifsTestOpsDir/foo.txt to
read-only (hit return to continue)


...all of that as expected.  If I make the change to foo.txt quickly then
the next set of tests works as well, but if it takes me more than 15
seconds (roughly) then I get this:

Exception in thread "main" jcifs.smb.SmbAuthException: Bad password
        at jcifs.smb.SmbTransport.send(SmbTransport.java:496)
        at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:120)
        at jcifs.smb.SmbSession.send(SmbSession.java:96)
        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:122)
        at jcifs.smb.SmbTree.sendTransaction(SmbTree.java:50)
        at jcifs.smb.SmbFile.sendTransaction(SmbFile.java:490)
        at jcifs.smb.SmbFile.queryPath(SmbFile.java:792)
        at jcifs.smb.SmbFile.exists(SmbFile.java:847)
        at jcifs.smb.SmbFile.canWrite(SmbFile.java:902)
        at FileOps.main(FileOps.java:148)

Why would it get a Bad Password?

After 15 seconds it appears that jCIFS closes the connection (reasonable,
since there are no open files or pending transactions).  As a result, the
test program must re-connect after I press enter, which it seems to be
doing.

Upon reconnect, however, it is doing something wrong in the
challenge-response authentication.  One suggestion is that jCIFS is not
calculating a new response to the new challenge, but is using the previous
response hash. I can grab captures and see, but it's currently 1:55am and
I want to get some sleep.  This should be easy enough to reproduce if 
anyone wants to give it a try.
        
More when I have it.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org