Error connect over TOR

[mandelmonkey]

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.16.1

What did you expect to see?

Connecting successful over TOR

am trying to connect via GRPC to a server over TOR

Currently I used the following code to connect to the clear text version or the server but now I would like to do the same over TOR in JAVA

 OkHttpChannelBuilder builder = OkHttpChannelBuilder.forAddress(host, port)
        .connectionSpec(new ConnectionSpec.Builder(OkHttpChannelBuilder.DEFAULT_CONNECTION_SPEC)
        .tlsVersions(ConnectionSpec.MODERN_TLS.tlsVersions().toArray(new TlsVersion[0]))
        .build());
 
      ManagedChannel channel = builder.build();
 
      stub = LightningGrpc
       .newStub(channel)
       .withCallCredentials(new MacaroonCallCredential(macaroon));

Is it just a matter of using the onion address and port? I tried removing TLS but no luck I get an "UNAVAILABLE" error

any ideas? I am using ORBOT SOCKS Proxy running on the android device

[ejona86]

In general, you need to provide the full error for us to help.

However, since you mentioned SOCKS, that is the clear problem. grpc-java does not support SOCKS. We only support HTTP CONNECT-based client-side proxies.

[mandelmonkey]

Thanks for the reply, I couldn't get any more error logs other than a grpc runtime exception with error message unavailable, anyway thanks for clarifying that GRPC does not support socks

…

On Wed, Jul 24, 2019, 2:51 AM Eric Anderson ***@***.***> wrote: In general, you need to provide the full error for us to help. However, since you mentioned SOCKS, that is the clear problem. grpc-java does not support SOCKS. We only support HTTP CONNECT-based client-side proxies. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5998?email_source=notifications&email_token=ABSECNZKS77QUHJ5EKEZXDDQA5AKDA5CNFSM4IFY77EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2T5HRA#issuecomment-514315204>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABSECN3OSX3WA2XU7CHRA23QA5AKDANCNFSM4IFY77EA> .

[ejona86]

grpc runtime exception with error message unavailable

That's exactly what I was hoping to see. You are also free to remove any of your own classes from the backtrace (although saying "snip" or "removed" where you removed a section is useful just to make it obvious where things were removed).

If the only information was StatusRuntimeException: UNAVAILABLE, then that is below our normal standards for error messages and would deserve being fixed. I will note, at times there will be a Throwable cause within the Status/Throwable which has more information and we'd generally hope to see that exception provided to us as well.

[mandelmonkey]

I created a gist with the stack trace based on a few different variations of OkHttpChannelBuilder builder config

https://gist.github.com/

[ejona86]

@mandelmonkey, looks like you were meaning https://gist.github.com/mandelmonkey/2ce8a97a73cfda2651f2074f8fc4eb60

It looks like TLS handshaking failed. Either the remote server isn't speaking TLS or it doesn't support TLS v1.2 (see the WRONG_VERSION_NUMBER in the error).

[mandelmonkey]

thanks for the reply, indeed the Tor onion address is using http not https, I was unsure how to disable TLS when connecting but tried the following

 OkHttpChannelBuilder builder = OkHttpChannelBuilder.forAddress(host, port);

//and

 OkHttpChannelBuilder builder = OkHttpChannelBuilder.forAddress(host, port).usePlaintext()

and got the errors starting here
https://gist.github.com/mandelmonkey/2ce8a97a73cfda2651f2074f8fc4eb60#file-gistfile1-txt-L76

is this not the correct way to connect to a non ssl uri?

[ejona86]

Channels by default use TLS. But usePlaintext() should disable TLS. That error message looks like TLS is still being used. Could you try again with usePlaintext()? (And I assume you aren't calling useTransportSecurity())

[mandelmonkey]

I confirmed using usePlaintext() and the error is error in frame handler

 at io.grpc.Status.asRuntimeException(Status.java:526)
2019-07-31 18:15:43.948 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:434)
2019-07-31 18:15:43.948 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
2019-07-31 18:15:43.948 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
2019-07-31 18:15:43.949 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
2019-07-31 18:15:43.949 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:678)
2019-07-31 18:15:43.949 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
2019-07-31 18:15:43.949 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
2019-07-31 18:15:43.949 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
2019-07-31 18:15:43.950 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:397)
2019-07-31 18:15:43.950 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:459)
2019-07-31 18:15:43.950 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:63)
2019-07-31 18:15:43.950 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:546)
2019-07-31 18:15:43.950 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:467)
2019-07-31 18:15:43.951 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:584)
2019-07-31 18:15:43.951 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
2019-07-31 18:15:43.951 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
2019-07-31 18:15:43.951 31445-31808/co.nayuta.wallet W/System.err:     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
2019-07-31 18:15:43.951 31445-31808/co.nayuta.wallet W/System.err:     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
2019-07-31 18:15:43.952 31445-31808/co.nayuta.wallet W/System.err:     at java.lang.Thread.run(Thread.java:764)
2019-07-31 18:15:43.952 31445-31808/co.nayuta.wallet W/System.err: Caused by: java.io.IOException: FRAME_SIZE_ERROR: 4740180
2019-07-31 18:15:43.952 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.okhttp.internal.framed.Http2.ioException(Http2.java:590)
2019-07-31 18:15:43.952 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.okhttp.internal.framed.Http2.access$200(Http2.java:47)
2019-07-31 18:15:43.953 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.okhttp.internal.framed.Http2$Reader.nextFrame(Http2.java:137)
2019-07-31 18:15:43.953 31445-31808/co.nayuta.wallet W/System.err:     at io.grpc.okhttp.OkHttpClientTransport$ClientFrameHandler.run(OkHttpClientTransport.java:968)
2019-07-31 18:15:43.953 31445-31808/co.nayuta.wallet W/System.err: 	... 3 more

[ejona86]

@mandelmonkey, that's a more appropriate error. 4740180 is 0x485454 which is "HTT" in ASCII. It seems you are hitting an HTTP/1 server, not HTTP/2. I am sorry it is cryptic, but plaintext isn't as commonly used with OkHttp so this failure hasn't happened as much and so we've not gone out of our way to add more debug information to make it more clear to users.

What server is being used? Is there a reverse (server-side) proxy involved?

[mandelmonkey]

Let me check with the developers of the server, I believe there is a reverse proxy being used, will get the details

…

On Aug 1, 2019, at 0:11, Eric Anderson ***@***.***> wrote: @mandelmonkey, that's a more appropriate error. 4740180 is 0x485454 which is "HTT" in ASCII. It seems you are hitting an HTTP/1 server, not HTTP/2. I am sorry it is a cryptic, but plaintext isn't as commonly used with OkHttp so this failure hasn't happened as much and so we've not gone out of our way to add more debug information to make it more clear to users. What server is being used? Is there a reverse (server-side) proxy involved?

[mandelmonkey]

seems to be using a reverse proxy yes
https://github.com/btcpayserver/btcpayserver-docker/blob/master/Production/nginx.tmpl#L229
anything you need me to find out?

[mandelmonkey]

I spoke to the dev he said he may need to add http2 to this line
https://github.com/btcpayserver/btcpayserver-docker/blob/master/Production/nginx.tmpl#L292

[ejona86]

Seems like the problem has been tracked down. @mandelmonkey, you can comment and we can reopen the issue if things don't work out.

[michaelWuensch]

Hi, I am trying to do exactly the same.
I was not able to get it working with Orbot in normal mode.
But with Orbot's VPN-Mode I was able to connect to a Tor Node with .onion address out of the box.
Is this in any way less secure? And was anyone able to get it working without the VPN-Mode yet?