I can confirm, that the us servers work properly for me also. You saved me a lot of debugging time, beside the time already eaten away. 
Thanks a lot.
A little bit annoying is that the channel plan i get is also the us one. Of course that is not the plan i selected in ttn’s console.
No, you should not use the US servers, as any time in the future the issue might be reversed. Key is:
So, you need to ensure SNI is working.
Of course I don’t want to be connected with the us server!
So, you need to ensure SNI is working.
Digging a little bit into that, so its basically a problem with basic stations authentication pattern? And it must be patched to work properly?
Not really.
Your Basic Station’s TLS network client software first resolves the server’s IP address, and then connects to that IP address. If it then does not properly send the name lns.eu.thethings.network when it connects to that name’s IP address, then TTN might just return the wrong certificate to identify itself. I don’t know which certificate will be selected then; maybe the oldest or newest, maybe the one that was last used in a proper SNI-connection by some other gateway, maybe a random one, who knows. So, what (accidentally) works now, might (will) not work at some later time.
So, point is that the TTN server (or load balancer) is handling requests for multiple (sub-)domain names, and the TLS client needs to provide the exact name during the TLS handshake with the server. That’s what SNI does.
Okay, i think i got what SNI actually does. But i thought, that this is done in the statically linked mbedTLS library. mbedTLS(SNI use) But you say now, that it’s a problem with the underlying system?
So, I think you notice that I’m not a network expert. I try to get that stuff running on our embedded machines. I would appreciate it when you could point me in a direction to fix it?
I’ve no idea. And I just saw the discussion in Slack continues:
anton 2020-04-07 11:10 AM
Actually, the underlying problem is that the certificate for
lns.in.thethings.networkhas expired.ssl_tls.c:4524 MBEDTLS[3]: issued on : 2020-01-06 13:02:23
ssl_tls.c:4524 MBEDTLS[3]: expires on : 2020-04-05 13:02:23SNI is not the issue here, because LBS does not assume the host name to be known a priori
@htdvisser 2020-04-07 11:22 AM
Ok, let me take a look
@KrishnaIyerEaswaran2 2020-04-07 11:35 AM
Ok but the certificate received has a different SN. Shouldn’t the client skip this certificate in this case?
(I might clean up here at some later time. I’m not going to duplicate the complete Slack content here, even though it expires fast on Slack. Success!)
Magic it works 
So, what did you change?
If you didn’t change anything, and (right now) lacking new insights in Slack, then you might want to validate that the following does not apply:
Make sure to keep an eye on Slack.
Didn’t change anything at all… but I also don’t know where to start troubleshooting. So it seems for me, to be a bug not on our system side.
Make sure to keep an eye on Slack.
How could I accomplish that, never heard bevore a public Slack Channel.
I linked to the Slack instructions twice above.
Just some clarification on the configuration of Basics Station.
I have no problem with your previous information.
Do I need a similar parameter in cups.trust or is this downloaded via the LNS protocol?
Similarly, how do I determine cups.uri?
Thanks
TTN (v2) does not support CUPS. You can use The Things Stack for that.
Hi @KrishnaIyerEaswaran2, Understand about V2 not supporting Basics Station and therefore no CUPS server. I am testing using a Things Stack (V3) instance for testing and can’t find any instructions on how to set the cups.trust and cups.uri files
Fantastic, thanks so much
Does anybody know that ttn LNS support China region? is there a LNS wss://lns.cn.thethings.network:443? Is it possible that i use basic station and ttn in China？
Unfortunately not, we don’t support that at the moment.
feel free to try the balena based TTN Basics Station gateway following these instructions https://www.balena.io/blog/deploy-a-basics-station-lora-gateway-with-ttn-and-balena/
hope this can simplify installation of the newest gateways.
After TTC presentation of @jmarcelino I got inspired and setup basics station with Balena on my RAK 831 gateway. Connection to V2 went flawless and the gateway runs fine. However, it fails to connect to V3.
I am informed that:
2021-01-26 20:24:13.108 [TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887
2021-01-26 20:24:13.152 [AIO:INFO] TLS server certificate verification failed: The certificate is not correctly signed by the trusted CA
At Deploy a Basics Station The Things Network LoRa gateway with balena I find: In some cases the certificate may change from the one used at the TTN gateway. In that case, set up the variable TC_CERT with the certificate.
Unsure where to get the certificate I cannot make it work with V3.
Can anyone help me out? Thanks in advance.
These instructions should be similar enough.
http://www.multitech.net/developer/software/lora/running-basic-station-on-conduit/