There's currently no built-in ways to detect this.

You can do a dial WithBlock with FailOnNonTempDialError as mentioned in 
this issue: 
https://github.com/grpc/grpc-go/issues/2863#issuecomment-500852442
You will need wrap TLS to make the specific TLS errors non-temporary, and 
the dial will fail when those errors happen.

On Wednesday, June 19, 2019 at 10:13:29 AM UTC-7, Dave Quigley wrote:
>
>
> The issue is that I don't want to defer until an RPC is sent to tell the 
> user something is wrong. This is part of an administration tool that has an 
> explicit connect command and it would be good to fail then. Is there any 
> sort of built in NULL rpc that can be used to test the connectivity or 
> would I need to build that into my grpc definitions?
>
> On Tuesday, June 18, 2019 at 2:04:33 PM UTC-6, Menghan Li wrote:
>>
>> If the connections fail because of TLS issues, the RPCs will also fail, 
>> and the RPC errors will have the TLS error message.
>>
>> The PR https://github.com/grpc/grpc-go/pull/2055/ 
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgrpc%2Fgrpc-go%2Fpull%2F2055%2F&sa=D&sntz=1&usg=AFQjCNElfr4RLPulZ9BrEx2qcqDf_9Id2A>
>>  was 
>> to get the underlying connection error after dialing, without making an 
>> RPC. But we didn't get to finish the API design.
>>
>> On Monday, June 17, 2019 at 1:28:30 PM UTC-7, Dave Quigley wrote:
>>>
>>> The problem though is that is a configuration error. That is something 
>>> that a user of the software would need to have an idea of what is going on 
>>> to fix it and asking them to set the two environment variable and crawl 
>>> through internal grpc debug messages. Also that won't catch if your 
>>> certificates were not generated properly either. For example if you don't 
>>> have the caRoot cert installed on your machine but your saying the 
>>> certificates have to be verified. There was a pull request 
>>> https://github.com/grpc/grpc-go/pull/2055/ that would introduce the 
>>> ability to obtain the underlying network failure during a transient failure 
>>> but it seems to be closed and has gone nowhere. It would really be useful 
>>> for a person using grpc to develop a program to obtain this information so 
>>> it can let the user know that they have a configuration issue.
>>>
>>> On Monday, June 17, 2019 at 1:04:06 PM UTC-6, Eric Anderson wrote:
>>>>
>>>> Correct. If the client expects TLS you will get an error if connecting 
>>>> to a plaintext server. Some languages may provide more error information 
>>>> than others, but in all language that information is intended for 
>>>> developers, not programs to inspect.
>>>>
>>>> On Thu, Jun 13, 2019 at 12:00 PM Dave Quigley <[email protected]> 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have enabled TLS between a gRPC client and server and require client 
>>>>> auth to be done as part of the exchange. I also have a flag to say that 
>>>>> the 
>>>>> server should be started without TLS securing the channel. However there 
>>>>> does not seem to be a good way to figure out when connecting from a 
>>>>> client 
>>>>> that expects a TLS handshake that the reason it was unable to connect is 
>>>>> that there is a mismatch of expectations. Am I missing something here? It 
>>>>> seems that TLS handshake failures are just treated as transient failures 
>>>>> and there is no way to get more details.
>>>>>
>>>>> Dave
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "grpc.io" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/50a5b52b-b5f9-42db-bb23-3c96bb2c1c01%40googlegroups.com.

Reply via email to