Bug 2666 - RFT does not return all errors from gridftp server
: RFT does not return all errors from gridftp server
Status: RESOLVED FIXED
: RFT
RFT
: development
: PC Linux
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-01-31 21:20 by
Modified: 2005-03-31 13:36 (History)


Attachments
Container log (988.65 KB, text/plain)
2005-01-31 21:48, Mats Rynge
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-01-31 21:20:44
I was trying to do some RFT transfers, but got an error message from RFT:

rynge@viz-9:~$ rft -h viz-login.isi.edu -r 9000 transfer.xfr
Number of transfers in this request: 1
Subscribed for overall status
Termination time to set: 60 minutes

 Overall status of transfer:
Finished/Active/Failed/Retrying/Pending
0/0/1/0/0
Error:Error authenticating user at source/dest hostnull [Caused by:
java.io.EOFException]




Not very informative. After enabling debugging on the gridftp server, I found
the real problem:

globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: The certificate is not yet valid: Cert with subject:
/C=US/O=NPACI/OU=SDSC/CN=Mats Rynge/UID=ux454281/CN=609403960/CN=420783230 is
not yet valid- check clock skew between hosts.



The real problem is obiously my fault, but it would be nice if RFT could return
the error, instead of my changing hats from user to sysadmin and tailing logfiles.
------- Comment #1 From 2005-01-31 21:48:14 -------
Created an attachment (id=498) [details]
Container log
------- Comment #2 From 2005-02-01 10:00:21 -------
Assigning this to jarek. 
------- Comment #3 From 2005-02-01 10:10:33 -------
This is the Error I see at RFT: 
2005-01-31 19:02:35,430 ERROR service.TransferWork [Thread-9010,run:575] Terminal transfer 
errorError authenticating user at source/dest hostnull [Caused by: java.io.EOFException]Error 
authenticating user at source/dest hostnull. Caused byjava.io.EOFException    at 
org.globus.ftp.extended.GridFTPInputStream.readHandshakeToken(GridFTPInputStream.java:50)    at 
org.globus.ftp.extended.GridFTPControlChannel.authenticate(GridFTPControlChannel.java:158)    at 
org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:92)    at 
org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:77)    at 
org.globus.transfer.reliable.service.TransferClient.authenticateSource(TransferClient.java:562)
------- Comment #4 From 2005-02-07 01:05:17 -------
What gridftp server is this exactly? I believe this is a server problem not a 
client one.
------- Comment #5 From 2005-02-07 01:19:52 -------
Both RFT and GridFTP built from CVS HEAD.
------- Comment #6 From 2005-02-25 16:38:30 -------
Was the certificate on client or server expired?

With the client certificate expired I get the following error:

Caused by java.io.IOException: 530 Authentication failed.
        at org.globus.ftp.extended.GridFTPInputStream.readHandshakeToken
(GridFTPInputStream.java:60)
        at org.globus.ftp.extended.GridFTPControlChannel.authenticate
(GridFTPControlChannel.java:159)
        at org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:93)
        at org.globus.ftp.GridFTPClient.authenticate(GridFTPClient.java:78)

Older gridftp server was a little more verbose on this error.
------- Comment #7 From 2005-02-25 17:19:41 -------
I meant was the client or server ceritifcate not yet valid?
------- Comment #8 From 2005-02-25 17:29:55 -------
From what I can tell the server is closing the connection. The Java client code 
throws EOFException only if the connection is closed. Reassigning to Mike for 
now.
------- Comment #9 From 2005-03-31 13:36:56 -------
There were two problems here, the original reported problem, was where the 
server would close the connection on certain authentication errors, and was 
fixed by a merge a few days after the report (which is why Jarek's results 
didn't match Mats').  The other is reporting a useful error to the client, 
which I've just fixed.

Everything's in the trunk.