[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

----- Original Message ----- 
From: "Scott Klement" <sk@xxxxxxxxxxxxxxxx>
To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, November 30, 2010 12:29 PM
Subject: Re: Unknown system state during get request


> Hi Eric,
>
> If you suspect a corrupt disk file, I would use RCLSTG (requires your
> system to be in a restricted state).
>
> However, that seems like a shot in the dark!
>
> EUNKNOWN can be reported on sockets, stream files, or pipes.  It's a
> very generic error code used for a large variety of different
> situations.  It's used by both the Unix-type APIs and the ILE C
> runtime...  both of these are core pieces of the OS (they're not
> separate licpgms you can uninstall and reinstall.)
>
> The fact that your SSL works to some sites and not to others makes me
> think that the problem is with the code that handles different types of
> certificates (part of the OS.)   either the site you're connecting to
> isn't using SSL at all (as I suggested before) or the certificate is in
> a format that your crypto routines don't understand.  (Which might be
> caused by running a very old version of the OS or Crypto Access Provider)
>
> It couldn't hurt to run a RCLSTG.  You should do it periodically,
> anyway.  But if it's painful to take the system down, I wouldn't jump on
> that idea until you've exhausted other possibilities.
>
> Some real information about the situation would help a lot.  Can you
> analyze the certificates with openssl?
>
>
> On 11/30/2010 10:39 AM, Eric Wasek wrote:
>> Thomas,
>>
>> OK.  So how do we check for a damaged IFS file in the C++ Run-Time 
>> Library?
>> Or do we just reload the whole library?
>>
>> We did not set up any special certificates on the remote system.  It uses
>> the same certificate method for our production software get request as it
>> does to perform the get request to the Klements site - and the get 
>> request
>> works to the Klements site.  If I am missing or overlooking something 
>> please
>> let me know.
>>
>> Eric
>>
>> ----- Original Message -----
>> From:<thomas.raddatz@xxxxxx>
>> To:<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>> Sent: Tuesday, November 30, 2010 2:40 AM
>> Subject: Re: Unknown system state during get request
>>
>>
>>>
>>> Eric,
>>>
>>> I am just guessing but since the EUNKNOWN error code is returned by
>>> several C stream file functions the problem might be a damged IFS file
>>> ("ILE C/C++ Run-Time Library Functions"). I do not know anything about 
>>> the
>>> DCM but in case it stores the certificates in the IFS it may be worth a
>>> try to check the certificate files.
>>>
>>> Thomas.
>>>
>>> ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 30.11.2010 01:01:25:
>>>
>>>> Von: ericw@xxxxxxxxxxxxx
>>>> An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>>>> Datum: 30.11.2010 01:02
>>>> Betreff: Re: Unknown system state during get request
>>>> Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> Hello Scott,
>>>>
>>>> You are very welcome (concerning the feedback).
>>>>
>>>> We have performed some tests that cast some light on the EUNKNOWN 
>>>> error.
>>> We
>>>> have used our test program (modeled after your example 3) from the
>>> remote
>>>> system to perform a get request to your Klements site.  Your site is an
>>> ssl
>>>> site and that get request does work.  We have also changed the url in
>>> that
>>>> test program to perform the get request to the production PC server
>>> site.
>>>> The url looks like this.
>>>> https://www.xxx.net/XXX99/security_export.php?pass=xxxx
>>>>
>>>> As you can see, it does use https.  This url does not work from the
>>> remote
>>>> system.  This same url in the exact same test program does work from 
>>>> our
>>>
>>>> local system.
>>>>
>>>> We checked the license programs on the remote system and noticed the
>>>> following.
>>>> 5722CE3   V5R1M0      Client Encryption 128-bit
>>>>
>>>> While the local system shows:
>>>> 5769CE3   V4R4M0      Client Encryption 128-bit
>>>>
>>>> We think this is because our local system was upgraded from V4.4 to 5.1
>>>> while the remote system was always a 5.1 system.  This seems strange
>>> given
>>>> the fact that the local system is the one that is working.  This may be
>>>> telling us that there is a problem with base 5.1 encryption while the
>>>> upgraded 5.1 encryption is working properly.
>>>>
>>>> Today we created another test program, so now we have 2 of them - one
>>> that
>>>> performs a get request to the url that we use in production and the
>>> other
>>>> that performs a get request to the Klements site.  We will be running
>>> comm
>>>> traces with both of these tomorrow to find out how they are different.
>>>> Obviously, the production url will not work while the Klements site url
>>> will
>>>> work.  We are hoping this will give us a clue to the problem.  We will
>>>> surely also run the comm trace for the local system using the 
>>>> production
>>>
>>>> url, since it does work.  Maybe a comparison of the 3 will help to
>>> figure
>>>> this thing out.
>>>>
>>>> The EUNKNOWN error that you wrote about is probably one of many
>>> situations
>>>> that throw the EUNKNOWN error.  We will find out more tomorrow.
>>>>
>>>> ----- Original Message -----
>>>> From: "Scott Klement"<sk@xxxxxxxxxxxxxxxx>
>>>> To: "HTTPAPI and FTPAPI Projects"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>>>> Sent: Monday, November 29, 2010 4:29 PM
>>>> Subject: Re: Unknown system state during get request
>>>>
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> I see...  so the upgrade issue isn't about HTTPAPI's update process.
>>>>> It's simply that it takes a lot of effort to update your systems
>>> because
>>>>> there are so many of them.  Thanks for the feedback.
>>>>>
>>>>> I don't know what the problem is -- and that makes it very hard to
>>> help.
>>>>>
>>>>> I do remember another place I saw the EUNKNOWN error you're receiving.
>>>>> If you connect to a non-SSL page, but use HTTPAPI in SSL mode, it'll
>>>>> cause that error.  That's because the OS is trying to negotiate SSL
>>> with
>>>>> the remote server, but the data it's getting back is unencrypted,
>>>>> non-SSL data... and it gets very confused.
>>>>>
>>>>> Might be worth looking into.
>>>>>
>>>>>
>>>>>
>>>>> On 11/29/2010 3:51 PM, Eric Wasek wrote:
>>>>>> Hello Scott,
>>>>>>
>>>>>> I did not want to burden this mailing list with the details of the
>>>>>> "several
>>>>>> hours" it would take to upgrade to the latest HTTPAPI on my original
>>>>>> post.
>>>>>> But now that you asked .... We are using your HTTPAPI software on
>>> MANY
>>>>>> systems, not just a few.  For it to work on those systems we have to
>>>>>> download it to our 5.1 system and compile it (fast and easy so far)
>>> and
>>>>>> send
>>>>>> the compiled software to all those systems and install it on each of
>>>>>> them.
>>>>>> The sending and installing is what takes several hours of time.  This
>>> is
>>>>>> all
>>>>>> in an effort to keep all the systems we support on the same release
>>> of
>>>>>> software.  We try to do this to avoid total confusion even though the
>>>
>>>>>> many
>>>>>> systems are running a wide variety of OS versions.  I am very
>>> thankful
>>>>>> that
>>>>>> we have been able to run one (old) version of HTTPAPI for so many
>>> years
>>>>>> without any problems.
>>>>>>
>>>>>> If we do need to upgrade to the latest version of HTTPAPI to figure
>>> out
>>>>>> (or
>>>>>> help figure out) what the problem is, then that is what we will do. I
>>>
>>>>>> was
>>>>>> hoping someone else encountered this situation on their system and
>>> would
>>>>>> be
>>>>>> able to say "change this little setting on that command page" and all
>>>
>>>>>> would
>>>>>> be fixed.  So if we can't make a simple change and get it to work,
>>> then
>>>>>> we
>>>>>> will have to upgrade and run our quick tests to see if it will work.
>>>>>>
>>>>>> I do not think the problem is within HTTPAPI.  Your version 1.16 has
>>> been
>>>>>> working on so many systems (for 4 years or more!) that I do not see
>>> how
>>>>>> it
>>>>>> could have a problem.
>>>>>>
>>>>>> As you stated there are 2 possibilities:  (1) HTTPAPI is providing
>>> bad
>>>>>> information to the API. Or (2) The API has a bug.  How do we figure
>>> out
>>>>>> which situation is the culprit?  About 10 days ago I did use STRDBG
>>> to
>>>>>> walk
>>>>>> thru some of the HTTPAPI subprocedures.  My notes from then say that
>>> it
>>>>>> returned *Off from comm_connect.  I think I checked some pointers at
>>> that
>>>>>> time and the parms did contain pointers, but I had no way of  knowing
>>> if
>>>>>> the
>>>>>> pointers were correct or not.  I probably missed what I really needed
>>> to
>>>>>> be
>>>>>> looking for.  The subprocedures seemed to work correctly up to that
>>>>>> point.
>>>>>>
>>>>>> What can I do to help figure out the cause of this situation?  I am
>>> open
>>>>>> to
>>>>>> all options.
>>>>>> Eric
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Scott Klement"<sk@xxxxxxxxxxxxxxxx>
>>>>>> To: "HTTPAPI and FTPAPI Projects"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>>>>>> Sent: Monday, November 29, 2010 1:53 PM
>>>>>> Subject: Re: Unknown system state during get request
>>>>>>
>>>>>>
>>>>>>> hi Eric,
>>>>>>>
>>>>>>> What I can tell you is that HTTPAPI is calling the
>>> gsk_secure_soc_init()
>>>>>>> API provided by OS/400.  The API is failing with error code
>>>>>>> GSK_ERROR_IO, and errno is set to EUNKNOWN. That's all the
>>> information I
>>>>>>> have about the error at this point.
>>>>>>>
>>>>>>> As the error is occurring during a call to an IBM API, we're left
>>> with
>>>>>>> two possibilities:  (1) HTTPAPI is providing bad information to the
>>> API.
>>>>>>>    Or (2) The API has a bug.
>>>>>>>
>>>>>>> Unfortunately, "Unknown System State" isn't a lot of information!
>>>>>>>
>>>>>>> I'm curious about your inability to upgrade to the latest HTTPAPI.
>>> You
>>>>>>> say it'll take you several hours -- but I don't understand why.  I
>>> would
>>>>>>> like to understand it better so I know how to improve HTTPAPI in the
>>>>>>> future.  What difficulty do you have updating HTTPAPI?
>>>>>>>
>>>>>>> Even if I had a fix for HTTPAPI that solved the problem you
>>> encountered,
>>>>>>> I don't see how I could get it to you?  If I issue a new copy of
>>> HTTPAPI
>>>>>>> with the fix, you'd be unwilling to install it because of the time
>>> it
>>>>>>> takes to update?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/29/2010 12:58 PM, Eric Wasek wrote:
>>>>>>>>
>>>>>>>>       We use a simple program to send a get request to a server and
>>>>>>>> receive
>>>>>>>>       back information in an IFS file.  But instead of information
>>> in a
>>>>>>>>       file, it is getting an error.  Following is the debug
>>> information.
>>>>>>>>
>>>>>>>>
>>>>>>>>       HTTPAPI Ver 1.16 released 2006-05-07
>>>>>>>>
>>>>>>>>       New iconv() objects set, ASCII=819. EBCDIC=0
>>>>>>>>
>>>>>>>>       https_init(): entered
>>>>>>>>
>>>>>>>> -----------------------------------------------------------------
>>>>>>>>
>>>>>>>>       Dump of local-side certificate information:
>>>>>>>>
>>>>>>>> -----------------------------------------------------------------
>>>>>>>>
>>>>>>>>       http_url_get(): entered
>>>>>>>>
>>>>>>>>       http_persist_open(): entered
>>>>>>>>
>>>>>>>>       http_long_ParseURL(): entered
>>>>>>>>
>>>>>>>>       (GSKit) I/O: Unknown system state.
>>>>>>>>
>>>>>>>>       ssl_error(406): (GSKit) I/O: Unknown system state.
>>>>>>>>
>>>>>>>>       SetError() #30: SSL Handshake: (GSKit) I/O: Unknown system
>>> state.
>>>>>>>>
>>>>>>>>
>>>>>>>>       Some of the code from the program is as follows.
>>>>>>>>
>>>>>>>>
>>>>>>>>       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                                  UrlText :
>>>>>>>>
>>>>>>>>       c                                  '/tmp/httptest.html')
>>>>>>>>
>>>>>>>>
>>>>>>>>       This code is a modified version of example 3 from Scotts
>>> examples.
>>>>>>>> We
>>>>>>>>       change the UrlText constant to what we use during production
>>> and
>>>>>>>>       compile this code on our version 5.1 system and send it to
>>> another
>>>>>>>>       remote 5.1 system to test.  It runs correctly on our 5.1
>>> system,
>>>>>>>> but
>>>>>>>>       not on the remote system.  We have been running this get
>>> request
>>>>>>>> on
>>>>>>>>       the local system for many years, but it has yet to work on
>>> this
>>>>>>>> remote
>>>>>>>>       system.
>>>>>>>>
>>>>>>>>
>>>>>>>>       We have changed the UrlText constant to perform the get
>>> request to
>>>>>>>> the
>>>>>>>>       Klements site (like in example 3) and it works correctly from
>>> both
>>>>>>>> the
>>>>>>>>       local and remote systems.  So we know that it can work from
>>> both
>>>>>>>> the
>>>>>>>>       local and remote systems.  It just does not work from the
>>> remote
>>>>>>>>       system with the url needed for the live, production software.
>>>>>>>>
>>>>>>>>
>>>>>>>>       We know that this is a very old version of the programs
>>> (1.16).
>>>>>>>> But
>>>>>>>>       this wonderful old version is working great at several
>>> locations.
>>>>>>>> To
>>>>>>>>       upgrade all of them would require several hours that I do not
>>> wish
>>>>>>>> to
>>>>>>>>       use as part of this project unless necessary.  We are only
>>>>>>>> currently
>>>>>>>>       using the basic functions of version 1.16 and do not want to
>>>>>>>> upgrade
>>>>>>>>       until we need to use some more advanced functions.
>>>>>>>>
>>>>>>>>
>>>>>>>>       A search of the archives found some PTFs for 5.4 (while the
>>>>>>>> problem
>>>>>>>>       system is on 5.1) and some Digital Certificate Manager
>>> information
>>>>>>>>       that should not affect what we are trying to do.
>>>>>>>>
>>>>>>>>
>>>>>>>>       Any ideas or assistance is appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>>       Eric Wasek
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> -----------------------------------------------------------------------
>>>>>>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>>>>>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>>>>>>>
>>> -----------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>> -----------------------------------------------------------------------
>>>>>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>>>>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>>>>>>
>>> -----------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> -----------------------------------------------------------------------
>>>>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>>>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>>>>>
>>> -----------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>> -----------------------------------------------------------------------
>>>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>>>>
>>> -----------------------------------------------------------------------
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------------------------
>>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>>> -----------------------------------------------------------------------
>>>>
>>>
>>>
>>> --
>>> IMPORTANT NOTICE:
>>> This email is confidential, may be legally privileged, and is for the
>>> intended recipient only. Access, disclosure, copying, distribution, or
>>> reliance on any of it by anyone else is prohibited and may be a criminal
>>> offence. Please delete if obtained in error and email confirmation to 
>>> the
>>> sender.
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>> -----------------------------------------------------------------------
>>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>>> http://www.scottklement.com/mailman/listinfo/ftpapi
>>> -----------------------------------------------------------------------
>>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
>>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
> 



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