[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unknown system state during get request
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
-----------------------------------------------------------------------