[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-----------------------------------------------------------------------