setsockopt failed: EINVAL - does ARC support https/SSL?

Question

just tried ARC with our APK for the first time. It starts fine but fails to connect to our backend server:

SocketException: setsockopt failed: EINVAL (Invalid argument)

Current Chrome and ARC as downloaded 2015-04-07.

Stack Trace shows it fails trying to set the KeepAlive socket option which is not supported (thans for that pointer).

Adding SocketConfig socket = SocketConfig.custom().setSoKeepAlive(false).build(); to the HttpClient does not help, as HttpClientConnectionOperator does always call sock.setKeepAlive(socketConfig.isSoKeepAlive()); and it looks to me, the call crashes even when called with false ...

Thanks, Cheers, Tom.

I/HttpClient(  204): I/O exception (java.net.SocketException) caught when processing request to HttpRoute[{s}->https://xxx.xxx.xxx:443]: setsockopt failed: EINVAL (Invalid argument)
I/HttpClient(  204): Retrying request to HttpRoute[{s}->https://xxx.xxx.xxx:443]

shell.js:141 I/libposix_translation_static(  204): TCPSocket::Bind: [::0.0.0.0]:0

shell.js:141 I/libposix_translation_static(  204): TCPSocket::connect: [xxx]:443

shell.js:141 E/PortalHttpClient(  204): Failed http request: POST https://xxx.xxx.xxx:443/if/xxx HTTP/1.1
E/PortalHttpClient(  204): java.net.SocketException: setsockopt failed: EINVAL (Invalid argument)
E/PortalHttpClient(  204):  at libcore.io.IoBridge.setSocketOption(IoBridge.java:306)
E/PortalHttpClient(  204):  at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:289)
E/PortalHttpClient(  204):  at java.net.Socket.setKeepAlive(Socket.java:453)
E/PortalHttpClient(  204):  at com.android.org.conscrypt.OpenSSLSocketImplWrapper.setKeepAlive(OpenSSLSocketImplWrapper.java:100)
E/PortalHttpClient(  204):  at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:134)
E/PortalHttpClient(  204):  at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
E/PortalHttpClient(  204):  at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:373)
E/PortalHttpClient(  204):  at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:225)
E/PortalHttpClient(  204):  at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
E/PortalHttpClient(  204):  at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
E/PortalHttpClient(  204):  at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
E/PortalHttpClient(  204):  at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
E/PortalHttpClient(  204):  at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
E/PortalHttpClient(  204):  at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
E/PortalHttpClient(  204):  at xxx.xxx.PortalHttpClient.execute(PortalHttpClient.java:134)
E/PortalHttpClient(  204):  at xxx.xxx.PortalHttpClient.executeWithRetry(PortalHttpClient.java:107)
E/PortalHttpClient(  204):  at xxx.xxx.PortalHttpClient.post(PortalHttpClient.java:78)
E/PortalHttpClient(  204):  at xxx.xxx.HttpServerCommunication.pairDevice(HttpServerCommunication.java:100)
E/PortalHttpClient(  204):  at xxx.xxx.ServerCommunicationSwitch.pairDevice(ServerCommunicationSwitch.java:51)
E/PortalHttpClient(  204):  at xxx.xxx.xxx.app.base.XxxAsyncTask.doInBackground(XxxAsyncTask.java:53)
E/PortalHttpClient(  204):  at android.os.AsyncTask$4.call(AsyncTask.java:372)
E/PortalHttpClient(  204):  at java.util.concurrent.FutureTask.run(FutureTask.java:237)
E/PortalHttpClient(  204):  at android.os.AsyncTask$SerialExecutor$2.run(AsyncTask.java:280)
E/PortalHttpClient(  204):  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
E/PortalHttpClient(  204):  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
E/PortalHttpClient(  204):  at java.lang.Thread.run(Thread.java:841)
E/PortalHttpClient(  204): Caused by: libcore.io.ErrnoException: setsockopt failed: EINVAL (Invalid argument)
E/PortalHttpClient(  204):  at libcore.io.Posix.setsockoptInt(Native Method)
E/PortalHttpClient(  204):  at libcore.io.ForwardingOs.setsockoptInt(ForwardingOs.java:122)
E/PortalHttpClient(  204):  at libcore.io.IoBridge.setSocketOptionErrno(IoBridge.java:338)
E/PortalHttpClient(  204):  at libcore.io.IoBridge.setSocketOption(IoBridge.java:304)
E/PortalHttpClient(  204):  ... 28 more
W/PortalHttpClient(  204): xxx.xxx.comm.common.CommunicationException: HOST_NOT_AVAILABLE[recoverable]: java.net.SocketException: setsockopt failed: EINVAL (Invalid argument) - will retry in 10s

Is this Android's HttpClient or the separate Apache HttpClient-for-Android library? — CommonsWare, Apr 07 '15 at 16:16
Hmm yeah it looks like ARC sets einval no matter what the value is if there is an unsupported option. Is there any way you can modify the external httpclient to not set this option, or did I misunderstand and this is coming from ARC code? — Elijah Taylor, Apr 08 '15 at 14:47
FYI: filed crbug.com/475036 to see if we can ignore SO_KEEPALIVE false and other default values — Elijah Taylor, Apr 08 '15 at 14:57
This is from commons HttpClient not ARC. Many thanks for opening 475036. — cheesus, Apr 08 '15 at 15:55

score 0 · Answer 1 · answered Apr 07 '15 at 16:55

There are two questions here:

Implicitly, you're asking about about setsockopt support based on the error. Yes, ARC supports a subset of setsockopt calls. You can see our posix translation layer, and what flags are supported, in our open source repo: https://chromium.googlesource.com/arc/arc/+/release-41.4410.244.0/src/posix_translation/socket_stream.cc#98 (this is for the current ARC 41 release). Unfortunately, based on your callstack, you are trying to set SO_KEEPALIVE, which is not currently supported. Here is a tracking issue for it if you want to star it, but it is unlikely to be implemented very soon: https://code.google.com/p/chromium/issues/detail?id=384940

Regarding HTTPS/SSL, we've gotten some reports about this externally, but mostly these reports have been vague. Some SSL does work so it is unclear why some people are having issues. If you can create a small reproducing APK with source that highlights a problem with HTTPS/SSL, you can file a bug to help isolate this.

Thanks for the insight! - actually I wanted to provide some info but I cannot press enter in the comment field. So I will edit the original question. — cheesus, Apr 08 '15 at 12:31

setsockopt failed: EINVAL - does ARC support https/SSL?

1 Answers1