Does this have to do with the packet forwarder protocol for UDP as described here? basicstation/examples/station2pkfwd at master · lorabasics/basicstation · GitHub
Can this be used to connect to TTN?
Yes, that is the ‘legacy’ protocol when adding a gateway to TTN.
Is there still no option to connect a (non TTIG) basic station gateway to TTN?
Because the RAK7258 has a basic station option.
1 Like
If there is an option I’m not aware of it.
@Johan any changes now gateways are largely connected to V3 instanced?
Indeed, we have community network support for Basic Station.
@KrishnaIyerEaswaran2 can shed some light on the endpoints.
4 Likes
Hey yes you can connect non TTIGs to the PCN Basic Station instances. Please use the following parameters;
- tc.uri:
wss://lns.{eu|us|in|au}.thethings.network:443 - tc.trust: Lets Encrypt DST X3 Root CA
Make sure to use the DER format for the trust.
On the gateway console, register your gateway using the “I’m using the legacy packet forwarder” option and enter your EUI.
PS: Yes this is not legacy but we are not going to update the v2 console for this change.
3 Likes
Make sure to use the DER format for the trust.
Actually, PEM should work just fine with Basic Station:
curl https://letsencrypt.org/certs/trustid-x3-root.pem.txt -o tc.trust
But, DER works equally well:
curl -s https://letsencrypt.org/certs/trustid-x3-root.pem.txt | openssl x509 -outform der > tc.trust
1 Like
Hello, are these facts still up to date? A week ago all was working with station like a charm. Now I’m not getting further then this:
# ../../bin/station 2020-04-07 07:28:04.522 [SYS:INFO] Logging : stderr (maxsize=10000000, rotate=3) 2020-04-07 07:28:04.522 [SYS:INFO] Station Ver : 2.0.3(phy/debug) 2020-04-07 07:19:02 2020-04-07 07:28:04.522 [SYS:INFO] Package Ver : 1.0.0 2020-04-07 07:28:04.522 [SYS:INFO] proto EUI : 0:502d:f41a:1134 (/sys/class/net/eth0/address) 2020-04-07 07:28:04.522 [SYS:INFO] prefix EUI : ::1 (builtin) 2020-04-07 07:28:04.523 [SYS:INFO] Station EUI : 502d:f4ff:fe1a:1134 2020-04-07 07:28:04.523 [SYS:INFO] Station home: ./ (builtin) 2020-04-07 07:28:04.523 [SYS:INFO] Station temp: /var/tmp/ (builtin) 2020-04-07 07:28:04.523 [SYS:WARN] Station in NO-CUPS mode 2020-04-07 07:28:04.724 [TCE:INFO] Starting TC engine 2020-04-07 07:28:04.726 [any:INFO] cert. version : 3 serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 issued on : 2000-09-30 21:12:19
expires on : 2021-09-30 14:01:15
signed using : RSA with SHA1
RSA key size : 2048 bits
basic constraints : CA=true
key usage : Key Cert Sign, CRL Sign
2020-04-07 07:28:04.726 [AIO:INFO] tc has no key+cert configured - running server auth only
2020-04-07 07:28:04.778 [TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443
2020-04-07 07:28:04.835 [AIO:DEBU] [3] WS connection shutdown…
2020-04-07 07:28:04.836 [TCE:INFO] INFOS reconnect backoff 0s (retry 0)
2020-04-07 07:28:04.837 [any:INFO] cert. version : 3
serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B
issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3
subject name : O=Digital Signature Trust Co., CN=DST Root CA X3
issued on : 2000-09-30 21:12:19
expires on : 2021-09-30 14:01:15
signed using : RSA with SHA1
RSA key size : 2048 bits
basic constraints : CA=true
key usage : Key Cert Sign, CRL Sign
2020-04-07 07:28:04.837 [AIO:INFO] tc has no key+cert configured - running server auth only
2020-04-07 07:28:04.879 [TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443
2020-04-07 07:28:04.932 [AIO:DEBU] [3] WS connection shutdown…
2020-04-07 07:28:04.932 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
In case it’s related, in Slack’s #ops channel the following was posted, emphasis mine:
On April 5, I could not connect to TTN LNS:
wss://lns.eu.thethings.network:443
Note: Before April 5, I had no problems using the basic station packed forwarder.The problem does NOT occur when using:
wss://lns.us.thethings.network:443After some debugging I have pin pointed the problem:
basicstation/src/net.c at v2.0.3 · lorabasics/basicstation · GitHubWhen using:
wss://lns.eu.thethings.network:443
the function mbedtls_ssl_handshake keeps returning the decimal values: -26880 and -9984When using:
wss://lns.us.thethings.network:443
the function mbedtls_ssl_handshake returns the decimal values: -26880 and 0
0 = GOOD, it means ready to run websocket protocol.if( conn->tlsctx ) { err = mbedtls_ssl_handshake(conn->tlsctx); LOG(DEBUG, "XXXXXXXXXXXXXXX mbedtls_ssl_handshake %d",err); }In both cases I use the same tc.trust file.
anton 2020-04-07 9:45 AM
For looking into the TLS setup in more detail you can set the environment variable
STATION_TLSDBG=4when executing LBSreturn code -0x2700 means:
$ grep -rin 0x2700 include/mbedtls/x509.h:73:#define MBEDTLS_ERR_X509_CERT_VERIFY_FAILED -0x2700 /**< Certificate verification failed, e.g. CRL, CA or signature check failed. */The reason it does not verify the certificate is because the subject name does not match the hostname (
lns.in.thethings.network!=lns.eu.thethings.network):ssl_tls.c:3754 MBEDTLS[2]: <= read record ssl_tls.c:4524 MBEDTLS[3]: peer certificate #1: ssl_tls.c:4524 MBEDTLS[3]: cert. version : 3 ssl_tls.c:4524 MBEDTLS[3]: serial number : 03:C0:15:AE:30:BD:E0:20:C1:4D:38:86:90:1D:89:A6:A4:00 ssl_tls.c:4524 MBEDTLS[3]: issuer name : C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 ssl_tls.c:4524 MBEDTLS[3]: subject name : CN=lns.in.thethings.network 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:23 ssl_tls.c:4524 MBEDTLS[3]: signed using : RSA with SHA-256 ssl_tls.c:4524 MBEDTLS[3]: RSA key size : 2048 bits ssl_tls.c:4524 MBEDTLS[3]: basic constraints : CA=false ssl_tls.c:4524 MBEDTLS[3]: subject alt name : lns.in.thethings.network ssl_tls.c:4524 MBEDTLS[3]: key usage : Digital Signature, Key Encipherment ssl_tls.c:4524 MBEDTLS[3]: ext key usage : TLS Web Server Authentication, TLS Web Client AuthenticationWhen I connect to
lns.eu.thethings.networkI’m getting the correct cert.Could it be possible that LBS isn’t setting TLS SNI correctly?
anton 2020-04-07 10:03 AM
Ok, so you are serving multiple certificates on the same connection
@KrishnaIyerEaswaran2 2020-04-07 10:04 AM
Yes indeed.
1 Like
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.
1 Like
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