[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> [1]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:
> >>>> [2]http://www.scottklement.com/mailman/listinfo/ftpapi
> >>>>
----------------------------------------------------------------------
-
> >>>
> >>>
----------------------------------------------------------------------
-
> >>> This is the FTPAPI mailing list. To unsubscribe, please go to:
> >>> [3]http://www.scottklement.com/mailman/listinfo/ftpapi
> >>>
----------------------------------------------------------------------
-
> >>>
> >>>
> >>
> >>
> >>
> >>
----------------------------------------------------------------------
-
> >> This is the FTPAPI mailing list. To unsubscribe, please go to:
> >> [4]http://www.scottklement.com/mailman/listinfo/ftpapi
> >>
----------------------------------------------------------------------
-
> >>
> >
> >
----------------------------------------------------------------------
-
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > [5]http://www.scottklement.com/mailman/listinfo/ftpapi
> >
----------------------------------------------------------------------
-
> >
> >
>
>
>
>
----------------------------------------------------------------------
-
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [6]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.
References
1. https://www.xxx.net/XXX99/security_export.php?pass=xxxx
2. http://www.scottklement.com/mailman/listinfo/ftpapi
3. http://www.scottklement.com/mailman/listinfo/ftpapi
4. http://www.scottklement.com/mailman/listinfo/ftpapi
5. http://www.scottklement.com/mailman/listinfo/ftpapi
6. 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
-----------------------------------------------------------------------