Error with ice_ping in iOS 7 & 8

in Help Center
Hi,
I have an application that running in iOS, it runs fine into iOS 8 and iOS 9, but with the same version of app, it cannot do ice_ping to proxy of endpoint with iOS 6 & 7.
In iOS 7 the one of error that I get is: "CFNetwork SSLHandshake failed (-9800)"
But this error is rare, because I can connect with the endpoint and the app use several methods in order to talk with the element remote, but when I do ice_ping in order to avoid expire the session, I get the previous error with iOS 7, by other hand, with iOS 6 & 7 the app get the following error extra:
I don't receive this error with the same version of app in iOS 8 & 9.
Thank you in advance.
Best regards,
I have an application that running in iOS, it runs fine into iOS 8 and iOS 9, but with the same version of app, it cannot do ice_ping to proxy of endpoint with iOS 6 & 7.
In iOS 7 the one of error that I get is: "CFNetwork SSLHandshake failed (-9800)"
But this error is rare, because I can connect with the endpoint and the app use several methods in order to talk with the element remote, but when I do ice_ping in order to avoid expire the session, I get the previous error with iOS 7, by other hand, with iOS 6 & 7 the app get the following error extra:
Description: Ice/OutgoingAsync.cpp:673: Ice::ObjectNotExistException: object does not exist: identity: `XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' facet: operation: ice_ping)
I don't receive this error with the same version of app in iOS 8 & 9.
Thank you in advance.
Best regards,
0
Comments
Could you provide a little more background information on your deployment? Is your client using Glacier2 to establish a session with the backend server? Or did you implement your own session mechanism? I'll assume you use Glacier2.
From what you describe, it sounds like the client successfully establishes the connection most of the time (but sometime it fails with a ssh handshake error) and for some unknown reasons the communication is broken after session establishment. This results in the Ice::ObjectNotExistException on the ice_ping. With Glacier2 sessions, this exception is expected if the Ice connection is dropped after successfully establishing the session. The session is bound to the network connection so when the connection drops the session is also destroyed by Glacier2. If the client later tries to the ping the session and automatic reties are enabled, Ice will transparently try to re-establish a new connection to Glacier2. However, since this connection isn't bound to a new session, Glacier2 rejects the call with Ice::[FONT=courier new, courier, monospace]ObjectNotExistException.[/FONT]
[FONT=arial, helvetica, sans-serif]You should be able to confirm this by enabling network/retry tracing on the client with Ice.Trace.Network=2 and Ice.Trace.Retry=1. On Glacier2, you can enable Glacier2.Trace.Session=2 and Ice.Trace.Network=2[/FONT]
You could also disable automatic retries on the client to prevent the client from transparently re-establishing the connection on ice_ping. Instead of retrying the client will raise the communication failure exception and your client can handle this exception to re-establish a new session. To disable automatic retries you should set Ice.RetryIntervals=-1 (see also https://doc.zeroc.com/display/Ice36/Getting+Started+with+Glacier2).
So I believe the main issue here is a reliability issue for the network connection between your client and server. The -9800 error indicates a SSL protocol error which doesn't really help us much. Which error do you see on the server side when the communication is dropped? Which Ice version do you use and on which operating system Glacier2 or your server is running?
Cheers,
Benoit.
Thank you for your fast response.
I have attached the result shown after enable the flags "Ice.Trace.Network=2" and "Ice.Trace.Retry=1".
I don't use a Glacier2 service, the communication is point to point in a LAN context.
Best regards,
I suppose the Ice::ObjectNotExistException exception is the result of the session expiring on the server side (the server removes the session object from its object adapter and this results in this exception being raised on the client).
As for the network connection failures, it looks like they occur with both iOS 6 and iOS 8.
Did you enable network tracing on the server side? You could also set Ice.Warn.Connections=1
Cheers,
Benoit.
Information about nodes:
* Node 1: iOS application with Ice 3.5.1.
* Node 2: PC with C++ client with Ice 3.5.0
The communication is directly between two devices, without Glacier2 session and in LAN context.
Both elements run as server and client. At same time I can have two iOS devices against the PC, one of them is running iOS >= 8 and the other one has iOS <=7. The device with iOS <=7 when tries the first ice_ping, crashes with the error reported in previous messages, whereas the other one is alive all the time.
This message is only for give you more information, I know that your response can be the same that previous messages.
Best regards,
I show you the traces after enable the flag that you tell me previously in iOS app:
And the log wrote by PC app:
I hope that this info attached, can use to know another perspective of the problem that I have.
It's truth that the error could be the problem at network, but, in the same moment, in a paralel way, other iOS app is being used and it hasn't any problem.
Do you know if there are any trouble with iOS 6 & 7 using IceSSL? TLS version? CFNetwork trouble or specific configuration?
Thank your in advance,
Best regards,
So if I understand it correctly, the SSL connection always fails when using iOS 7. It's not a sporadic failure. If that's the case, it could indeed be an SSL interoperability issue between the iOS 7 client and the server. Which operating system do you use for your server?
Can you try enabling IceSSL.Trace.Security on the server?
The easiest would be to provide a small test case. You could for example try to reproduce the problem with our iPhone hello client using your certificates.
Cheers,
Benoit.
Yes, the problem is always present when I use IOS <= 7.
I have enabled the IceSSL.Trace.Security and the difference between deal connection from iOS <= 7 and iOS >= 8 is:
* iOS 7:
* iOS 9 log:
I'm surprised because the private key was generated with 256 bit RSA algorithm, however, when I try use the iOS <= 7, the server tries to use AES 128 bits instead of the 256 bits RSA as iOS >= 8, both with TLS v1.
I will try to do asap the test case that you tell me.
Best regards,
I can also give this a try with a similar certificate. Can you indicate which operating system you are using on the server side so that I try with a similar deployment?
Cheers,
Benoit.
I have tried with another certificates and the result is the same. The PC is Linux based and the version of Ice is 3.5.0.
I think that I found where is the problem, the iOS app create a SSL proxy in order to receive some conversations from PC, when PC tries ice_ping with my iOS proxy, it has an error, then close his proxy, and the app detect that the remote proxy is off and close the connection.
Are there any problem using IceSSL proxy with iOS 6 & 7? If I create the proxy using TCP instead of SSL, the problem disappear in all iOS versions.
Best regards,
Yes, this is most likely an SSL interoperability issue between iOS 6 or 7 and the Linux system. I will try to reproduce the problem and let know what I find out.
Cheers,
Benoit.
I wasn't able to reproduce the problem with a iPhone 4 running iOS 7.1.2 and a Debian Linux machine using OpenSSL 1.0.0.
Using the iPhone/hello demo and certificates (RSA certificate with a 2048 byte key size and the SHA256 signature algorithm), the iOS device was able to establish an SSL connection using the TLSv1 protocol with the AES128-SHA cipher. Note that the key size used for the certificate is not related to the key size used by the encryption algorithm, the key from the certificate is only used for authentication and to exchange a private key for the encryption algorithm used to encrypt the communication (AES128 here).
Which OpenSSL version are you exactly using on your Linux machine? Can you check if you can reproduce the problem running the iPhone/hello demo on your iOS device and the hello server on the Linux machine? You could also try using another server machine to see if problem comes from the OpenSSL version you're using on your Linux box.
Cheers,
Benoit.
You are right, the version of Linux based PC is lower than 1.0.0, then I try to update the version of OpenSSL... when I will have done this task, I will response you in order to close this thread.
Thank you very much in advance.
Best regards.