Re: Unknown system state during get request

["Eric Wasek" <ericw@xxxxxxxxxxxxx>]

Hello again,
After a one week delay I am back on this situation again.  As you may 
recall, we were going to load LIBHTTP and test programs on a second remote 
system and see what the resulting messages revealed.  This has been 
accomplished and the results are inconsistent with the results on the first 
remote system.  The debug information follows, along with some of the code 
from the test program.

HTTPAPI Ver 1.16 released 2006-05-07



New iconv() objects set, ASCII=819. EBCDIC=0

https_init(): entered

(GSKit) Identifier value is not valid.

ssl_error(701): (GSKit) Identifier value is not valid.

SetError() #24: Setting auth type: (GSKit) Identifier value is not valid.



D UrlText2        C                   'https://www.klements.com'

C                   CALLP     HTTP_DEBUG(*ON: DBGFILE)



c                   eval      rc = https_init(*BLANKS)



c                   if        rc < 0

c                   eval      msg = http_error(rc)

c                   if        rc = HTTP_NOTREG

c                   exsr      RegisterMe

c                   return

c                   else

c                   dsply                   msg

c                   return

c                   endif

c                   endif

c                   eval      rc = http_url_get(

c                                  UrlText2 :

c                                  '/tmp/httptest.html')


As is shown in the program, it is supposed to connect to the klements site. 
So for this (second) remote system we were not able to connect to the 
klements site, while the first remote site is able to connect to the 
klements site.

This is a new error to me.  Does anyone have any ideas?

Eric

----- Original Message ----- 
From: "Eric Wasek" <ericw@xxxxxxxxxxxxx>
To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, November 30, 2010 4:41 PM
Subject: Re: Unknown system state during get request


> Hello Scott,
>
> First an update of events from earlier today.  We ran two comm traces on 
> the
> remote system, one with the get request that we use in production and one
> with the get request to the Klements site.  The comparison of the two was
> not a good comparison since the first one did not work and the second one
> did and they were connecting to 2 very different sites.  So we also ran a
> comm trace on our local system using the get request from production.  It
> did work, as it always has, so we compared it to the remote trace for
> production.  The comparison of the 2 was quite similar.  Up to a point, 
> they
> both showed sends and receives in the same sequence and also with similar
> data.  It was at the point that we think the handshake was to be completed
> that the similarities ended and the connection was closed on the one that
> did not work.  The one that did work went on to send encrypted data before
> closing the connection.  So we could see what was happening in 
> communication
> and data but not in programs and files.  The results are therefore
> inconclusive.
>
> We will be installing the IBM encryption software on another remote 5.1
> system later this week.  We hope to gain knowledge of the PTF level that 
> is
> needed to make this work correctly.  Our local system is at a higher level
> of PTFs than the remote system with the problem.  The remote system with 
> the
> problem had its encryption software installed recently, so it has no PTFs 
> or
> CUMs installed for the encryption software.  The other remote system that
> will be installed later this week will also not have PTFs or CUMs 
> installed
> for the encryption software.  So if the second remote location fails the
> test using the get request from production, then we can suspect that a CUM
> or PTF is needed.  If it succeeds, we can suspect the base encryption
> software.  So we will either be searching for PTFs and CUMs or reloading 
> the
> base encryption software.  We should know more later this week.
>
> RCLSTG does sound like a shot in the dark.  I have noted that as something
> to try in the future.
>
> Regarding your text that contains "the problem is with the code that 
> handles
> different types of certificates".  We also think this is the problem (or 
> at
> least something that needs verifying).  Our test program uses the same url
> for the get request locally and remotely so we are concentrating on the 
> old
> version of the OS and encryption.  We should learn more later this week.
>
> Regarding openssl - After reading your post and searching the 
> SystemiNetwork
> archives for openssl, I read an article that hinted that 5.3 is needed to
> install openssl and other related software.  Is this true or can it be
> installed on our 5.1 system?
>
> Eric
>



-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------