> From: owner-openssl-us...@openssl.org On Behalf Of manoj dhyani
> Sent: Saturday, 04 February, 2012 23:59
> both soapUI and client application built using axis 2c are running
> on the same machine, I have axis2java based client running on the
> same machine and works fine
> the request is hot very big, the webserver requires WS-Security
> username and password, but if you don't pass that it returns a soap fault
> in case of SopUI and axis2java but fails with the same error for axis2c
> the buffer in axis2c is null, I do see encrypted alter and connection
reset
> after FIN
> I am attaching the wireashark capture both when the call is done
from
> SoapUI and Axis2c client
Okay, in the good case (SoapUI) after handshake
(resulting in TLS1.0 RSA-RC4-128-SHA) we have:
#17 send enc-data 559-20=539
#18,19 recv enc-data 1471-20=1451
#21 recv enc-data 69-20=49
#22 send enc-data 762-20=742
about .4sec delay to #23 ACK and another .4sec to
#24,25,27,28,30,31,33,34,36 recv enc-data 12218-20=12198
539 is about right to be HTTPhdr plus a smallish request;
1451 + 49 could be a segmented response (but see next)
or a response with some HTTP control like chunked encoding.
742 could be a slightly larger request and 12198 a big response
(not segmented, but maybe from a different part of server).
In the bad case (app+axis2) there's 4.5sec delay starting handshake
which I'll hope was just debugging, then after handshake we have:
#15 send enc-data 204-20=184
#16 send enc-data 22-20=2
#17 send enc-data 944-20=924
about .2sec delay maybe Nagle then recv ACK(#16) and ACK(#17) then
#20 recv enc-alert with piggyback FIN (with PSH ACK)
#21 send ACK(#20+FIN) not FIN (probably in stack)
#22 recv RST (with ACK and good ack/seq)
The server apparently dislikes your request and closes
aggressively: it RSTs to your machine's ACK(FIN) even
though it may still have seqctrs and (thus) endpoint block,
and even though you haven't begun to FIN. This is not ideal
TCP behavior, though it can be acceptable in an error case.
It looks very odd that your request is sent as 184,2,924.
184 is enough for HTTPhdr but little or no request data.
2 is a very odd size to do in the middle. Total 1110 is
noticeably more than 539 for first request in good case.
Since you can debug, I would look at the calls to SSL_write,
and verify that when concatenated they form a valid request
(HTTPhdr then SOAP request body), and try to look at the calling
(axis2c) code to see why it's sending in pieces like this.
Though in itself legal that behavior is somewhat unusual, and
might be triggering a server limitation the other case doesn't.
Hope this helps.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
