RAK2287 with open source stack on localhost

Hi team,

Is anyone using RAK2287 with things stack running on raspberry pi (localhost)?
Kindly share how you configured your certificates using cfssl? I’m trying to follow the steps as documented here Custom Certificate Authority but I get this error.

openssl verify -CAfile ca.pem cert.pem
C = US, ST = CA, L = SJ, O = Tech
error 18 at 0 depth lookup: self signed certificate
error cert.pem: verification failed


Basicstation works but UI doesn’t

If my cert.json file is like this, I am able to connect RAK2287 using docker to Things Stack but unable to login to UI.

{
  "cn": "192.168.0.47",
  "names": [
    {"C": "US", "ST": "CA", "L": "SJ", "O": "Tech"}
  ]
}

This is the error message:

{
  "code": 7,
  "message": "error:pkg/web/oauthclient:exchange (token exchange refused)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/web/oauthclient",
      "name": "exchange",
      "message_format": "token exchange refused",
      "correlation_id": "dd14286f1ed8407fb540dc41f3d80b2e",
      "cause": {
        "namespace": "pkg/errors",
        "name": "request",
        "message_format": "request to `{url}` failed",
        "attributes": {
          "op": "Post",
          "url": "https://192.168.0.47/oauth/token"
        },
        "correlation_id": "389c4f533aca481e8a96b6ba07a839e8",
        "cause": {
          "namespace": "pkg/errors",
          "name": "x509_hostname",
          "message_format": "certificate authorized names do not match the requested name",
          "attributes": {
            "host": "192.168.0.47"
          },
          "correlation_id": "b2f0fe3c1b664ec599ad8abea247e2ec",
          "code": 14
        },
        "code": 14
      },
      "code": 7
    }
  ]
}

basicstation doesn’t work but UI works

If my cert.json file is like this then basicstation doesn’t start.

{
  "hosts": ["192.168.0.47"],
  "names": [
    {"C": "US", "ST": "CA", "L": "SJ", "O": "Tech"}
  ]
}

This is the error message:

basicstation    | cert. version     : 3
basicstation    | serial number     : 7C:7E:73:41:86:5A:FB:55:FE:F7:80:C9:49:FA:88:EF:94:39:A8:4B
basicstation    | issuer name       : C=US, ST=CA, L=SJ, O=Tech
basicstation    | subject name      : C=US, ST=CA, L=SJ, O=Tech
basicstation    | issued  on        : 2022-08-22 02:26:00
basicstation    | expires on        : 2027-08-21 02:26:00
basicstation    | signed using      : ECDSA with SHA256
basicstation    | EC key size       : 256 bits
basicstation    | basic constraints : CA=true
basicstation    | key usage         : Key Cert Sign, CRL Sign
basicstation    | 2022-08-22 02:32:15.236 [TCE:INFO] Connecting to INFOS: wss://192.168.0.47:8887
basicstation    | 2022-08-22 02:32:15.270 [AIO:INFO] TLS server certificate verification failed: The certificate Common Name (CN) does not match with the expected CN
basicstation    | 2022-08-22 02:32:15.270 [AIO:DEBU] [4] WS connection shutdown...
basicstation    | 2022-08-22 02:32:15.270 [TCE:INFO] INFOS reconnect backoff 0s (retry 0)
basicstation    | 2022-08-22 02:32:15.271 [AIO:INFO] ./tc.trust:

I don’t think that it’s particularly related to the RAK2287 or a Pi.

I have recently tried to put a reverse proxy in front of an install so that a site with a single IP address that already has a web server mapped to it can also run a local instance of TTS for testing but provide remote config & gateways on mobile backhaul.

But the session token request fails in a similar fashion like yours - it returns the html for the login page rather than the expected response, which makes me suspect I’m not mapping over the right headers and/or where the TLS should happen. Now I know it’s “not just me”, I can spin up that machine again later this week and look at it again with fresh eyes!

If you only want to run an instance on the internal network, then using an IP address without TLS works fine - any security issues that arise should be minimal if it’s inside your network. To make it look prettier, I put an A entry in to my infrastructure domain that points to the internal IP address on the network, but the quad dot works equally well. However I’m not sure if BasicStation mandates TLS. You may find it easier to get another Pi (yes I know there are availability issues) so you can work on the stack and the gateway elements separately.

1 Like

:slight_smile: I feel hopeful

Much appreciated!

I’m running entire setup at home with no DNS server. Both the Things Stack and the Basic-station are installed on the same Pi. I tried accessing the stack with http://192.168.0.47 but after login it still fails with same error message on the browser.

Would you suggest to run these on separate Pi’s?

Yes, if only to try & keep things sane or at least for the purposes of debugging. And if you aren’t fussed, you could use an older packet forwarder rather than BasicStation which has the main advantage of remote management which you don’t need for this setup.

The DNS is entirely optional and mostly cosmetic, but for me with many devices on the home-office network, I can use names rather than try to remember numbers.

Which packet forwarder is recommended?

If not using BasicStation I would suggest/recommend Jac @kersing 's MP PF :wink: Runs fine on older/lower end Pi’s as well. Works fine on dozens of mine…

1 Like

I tried with 2 hosts and no luck.

Do you mean you setup a host name in a DNS and tried using that URL?

Can you expand on “no luck” - hard to suggest anything at that level of detail!

Apologies for short message.

I tried running Thing stack on a separate host than the one where basicstation was running. @xoseperez latest update helped resolve the issue.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.