ERROR: "XCOMU0298E Txpi 701" & invalid EyeCatcher (XCOMU0469E)
search cancel

ERROR: "XCOMU0298E Txpi 701" & invalid EyeCatcher (XCOMU0469E)

book

Article ID: 196418

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC

Issue/Introduction

Currently using XCOM to transfer files successfully to a remote system over the non-secure interface on port 8044. However, now have a requirement to send these files over the secure interface on port 8045. Both local and remote systems are running XCOM for Linux.
Have imported the ssl certificates and mapped in the config files on both servers. However, when run this command to the remote server it fails per errors below:

/opt/CA/XCOM/bin/xcomtcp -t -c1 -f LOCAL_FILE=/share/gs/dir1/dir2/dummy.txt REMOTE_FILE=/tmp/xcom/dummy.txt FILE_OPTION=REPLACE PASSWORD.ENCRYPTED="..." PORT=8045 PROTOCOL=TCPIP REMOTE_SYSTEM=hostname USERID=xxxx QUEUE=NOSECURE_SOCKET=YES

===
2020/07/20 16:40:57 TID=002000 [/share/gs/dir1/dir2/dummy.txt --> /tmp/xcom/dummy.txt at hostname]
    XCOMU0029I Locally initiated transfer started.

2020/07/20 16:40:57 TID=002000
    #XCOMU0298E Unable to allocate remote transaction program: Txpi  701: Received remote data block at 0X7FFC81FE1E90 starting with invalid EyeCatcher 0X2358434F (#XCOMU0469E xcom)
===

Environment

XCOM™ Data Transport® for Linux PC

Resolution

  1. For the initial reported problem, the xcom.log showed "Missing or invalid '/usr/spool/xcom/config/configssl.cnf'" where "/usr/spool/xcom/config/" is a symbolic link to "/opt/CA/xcom/config"
    ===
    2020/07/20 22:03:50 TID=002004 PRG=xcomtp PID=28983 IP=remote_host_name PORT=8045
        XCOMU0780E Txpi  307: TxpiSSLConfig Failed msg = <ConfigSSL: Missing or invalid </usr/spool/xcom/config/configssl.cnf> file.> value = 0: 
    2020/07/20 22:03:50 TID=002004
        #XCOMU0298E Unable to allocate remote transaction program: Txpi  701: Received remote data block at 0X7FFC579D7D50 starting with invalid EyeCatcher 0X2358434F (#XCOMU0469E xcom); 
    ===
    After checking required XCOM symbolic links, the configssl.cnf file location and its content, that problem went away.
  2. New error now seen in the local xcom log file after new transfer attempt to the remote server:
    "XCOMU0780E Txpi  308: TxpiInitSSL Failed msg = 'error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt' value = 0:"
    From openssl s_client tests done by support to local server using the provided ssl files, it appeared the certificate was pass phrase protected.
    Add the pass phrase to the [PASSWORD] section of the local configssl.cnf file for both INITIATE_SIDE & RECEIVE_SIDE and test a loopback transfer on the local server i.e.
    ===
    [PASSWORD]
    INITIATE_SIDE = password
    RECEIVE_SIDE  = password
    ===
    The loopback test was successful.
  3. Using #2, a transfer test to the remote server shows a new error:
    "XCOMU0780E Txpi  308: TxpiInitSSL Failed msg = <error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number> value = 4294967295:"
    Support requested this openssl test be executed to the remote server :
    "openssl s_client -connect remote_hostname:8045 -ssl3 -cert /opt/CA/XCOM/ssl/certs/clientcert.pem -key /opt/CA/XCOM/ssl/private/clientkey.pem -showcerts -status -msg < /dev/null > openssl_ssl3.out 2>&1"
    It was successful but returned "Cipher is (NONE)" amd " Cipher    : 0000"
    There was also an error: "140443818207120:error:1408D177:SSL routines:ssl3_get_key_exchange:bad dh g value:s3_clnt.c:1786:"
    Per this KB article: XCOM SSL handshake fails with XCOMU0298E and XCOMU0780E
    Change remote configssl.cnf to have the [RSAKEY] value "RECEIVE_SIDE" set to YES instead of the default NO, so that RSA is used instead of Diffie Hellman (RSA is more secure) i.e.
    ===
    # Mandatory, YES/NO (if NO, DH will be used)
    [RSAKEY]
    RECEIVE_SIDE = NO
    ===
    The ssl handshake was then successful.