Lorawan-stack: Unterstützung für die Installation von Servern an verschiedenen Standorten

Danke für den Vorschlag @zamashal

Tatsächlich ist das Getting Started derzeit für den Single-Process-Ansatz gedacht, aber wie Sie vielleicht gesehen haben, können Sie die Komponenten einzeln starten. Sehen;

$ ttn-lw-stack start --help
Start The Things Stack

Usage:
  ttn-lw-stack start [is|gs|ns|as|js|console|gcs|dtc|qrg|all]... [flags]

Es ist nicht sehr schwierig, Dienste pro Komponente zu erzeugen, wenn diese Dienste Teil desselben Clusters und Subnetzes sind.

Ich beschränke dieses Problem vorerst auf Anweisungen, wie es geht;

• Installieren Sie einen eigenständigen Identitätsserver
• Installieren Sie einen eigenständigen Join-Server
• Installieren Sie einen Routing-Cluster mit Gateway-Server, Netzwerkserver und Anwendungsserver, der die eigenständigen Dienste verwendet

@johanstokking Vielen Dank für Ihre Antwort und das Hinzufügen des Problems zum Backlog. In der Zwischenzeit frage ich mich, ob Sie mir dabei helfen können. Ich habe den Join-Server alleine mit folgendem Befehl gestartet:
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

Was ich nicht herausfinden kann, ist, an welchem ​​Port der Join-Server die Join_Req empfängt und die Join_Ans automatisch an den angegebenen Netzwerkserver sendet?

Danke noch einmal!

@zamashal ist tatsächlich JS der Server und NS und AS sind Clients. Konfigurieren Sie also die JS-Clusteradresse in NS und AS. Dadurch arbeiten sie im selben Cluster, obwohl sie einzelne Komponenten sind. Beachten Sie, dass dies die Clusterauthentifizierung verwendet, die für Komponenten entwickelt wurde, die sich im selben Cluster vertrauen. Wenn Sie GS, NS und AS am Edge und JS in der Cloud bereitstellen, ist dies wahrscheinlich nicht der Fall.

In diesem Fall müssen Sie Interop über LoRaWAN-Backend-Schnittstellen verwenden, die ebenfalls unterstützt werden. Dadurch kann NS Ihren JS über die TLS-Client-Authentifizierung kontaktieren.

Dies erfolgt in zwei Teilen: Konfigurieren des NS für die Verwendung Ihres JS und Konfigurieren Ihres JS mit der interop Konfiguration (siehe --help ). Dies ist leider auch noch nicht vollständig dokumentiert.

Nochmals vielen Dank Interoperabilität mit Semtech Join Server . Ich versuche jedoch, den Join-Server von TTN Stack selbst zu verwenden und nicht etwas Externes wie das von Semtech oder anderen. Muss ich noch die Konfiguration für configure.yml und example/js.yml eingeben? Wenn ja, wie würde das dann aussehen?

Ich habe meinen NS bereits so konfiguriert, dass er mit einem externen JS (auch bekannt als JS von TTN Stack) funktioniert, aber mit Port 8886 (Interop/tls) des Join-Servers zum Senden des Join_Req wird die Verbindung abgelehnt, obwohl die JS scheint auf diesem Port zu lauschen.

Vielen Dank!

@zamashal Hier sind ungefähr die Dinge, die getan werden müssen;

Join Server-Interop-Konfiguration

Siehe Flaggen:

      --interop.listen-tls string                                      Address for the interop server to listen on (default ":8886")
      --interop.sender-client-ca.blob.bucket string                    Bucket to use
      --interop.sender-client-ca.blob.path string                      Path to use
      --interop.sender-client-ca.directory string                      OS filesystem directory, which contains sender client CA configuration
      --interop.sender-client-ca.source string                         Source of the sender client CA configuration (static, directory, url, blob)
      --interop.sender-client-ca.url string                            URL, which contains sender client CA configuration

Interop verfügt über einen eigenen dedizierten Listener, der die TLS-Clientauthentifizierung verwendet. Sie können dieselbe öffentliche IP-Adresse wie für gRPC verwenden und einen dedizierten Interop-Port verwenden (Standard 8886).

Sie benötigen eine private CA, die Clientzertifikate ausstellt. Diese werden am Rand von NS verwendet. Sie können die vertrauenswürdigen Client-CAs im Join-Server konfigurieren, und zwar pro NetID. Sie können die NetIDs 000000 und 000001 jederzeit in Ihrem privaten Netzwerk verwenden oder der LoRa Alliance beitreten und selbst eine erhalten.

Setzen Sie interop.sender-client-ca.source auf directory und geben Sie dort ein config.yml zum Beispiel:

# Experimentation
000000: ca-000000.pem

# The Things Network Foundation
#000013: ca-000013.pem

Ihre private CA geht in ca-000000.pem . Sie könnten die CA von TTN für die TTN-NetID wie im Beispiel hinzufügen, nur um Ihnen zu zeigen, wie dies funktioniert.

Netzwerkserver-Interop-Konfiguration

Dies ist wie dokumentiert , aber was Sie tatsächlich brauchen, ist die lokale JS-Konfiguration. Dies wäre wie folgt:

fqdn: 'thethings.example'
port: 8886
protocol: 'BI1.0'
tls:
  root-ca: 'path/to/clientca.pem'
  certificate: 'path/to/clientcert.pem'
  key: 'path/to/clientkey.pem'

Hier ist thethings.example der FQDN Ihres Join-Servers und 8886 der Port dieses listen-tls , das Sie im JS-Interop konfiguriert haben.

Außerdem ist root-ca (anders als im Beispiel) die Stammzertifizierungsstelle des _Serverzertifikats_. Dies könnte die gleiche CA sein. Sie können es auch weglassen, wenn Sie ein kommerzielles (oder Let's Encrypt) Serverzertifikat verwenden, dem bereits NS vertraut.

Aktivieren Sie Debug-Protokolle auf beiden Seiten ( log.level=debug ) und Sie sollten sehen, dass die Dinge funktionieren oder nachverfolgen, warum die Dinge nicht funktionieren. Viel Glück!

Wenn dies funktioniert, können Sie auch einen Pull-Request einreichen, um dies zu dokumentieren. Es würde wahrscheinlich eine Anleitung brauchen, aber die Referenzseite braucht auch etwas Liebe.

@johanstokking , ich werde daran arbeiten und hoffentlich, sobald ich es herausgefunden habe, eine Pull-Anfrage stellen, um den Leitfaden zu aktualisieren. Ich kann Ihnen nicht genug für Ihre Hilfe danken!

Hey @johanstokking - ich hoffe bei dir ist alles gut gegangen. Ich möchte Sie über meine Fortschritte auf dem Laufenden halten. Leider habe ich viele Fehler behoben, um dies zum Laufen zu bringen, und ich werde Ihnen hier die neuesten Fehler mitteilen, mit denen ich konfrontiert bin. Nachdem ich Interop eingerichtet und meinen Netzwerkserver so konfiguriert habe, dass er Join-Anfragen an den Join-Server am Standardport 8886 sendet, erhalte ich in meinem Netzwerkserver-Protokoll immer die folgende Fehlermeldung:
error="join-request to join-server error: http post error: Post http://js-server_ip:8886: dial tcp js-server_ip:8886: connect: connection refused"

Wenn ich meinen Netzwerkserver so konfiguriere, dass er die Beitrittsanfragen an Port 1884 des gRPC-Servers sendet, erhalte ich stattdessen die folgende Fehlermeldung im Netzwerkserverprotokoll:
level=error msg="uplink: processing uplink frame error" ctx_id=f046310d-e528-4dd2-9dcb-6d5c8232a799 error="join-request to join-server error: http post error: Post http://js-server_ip:1884: net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\\x00\\x00\\f\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\\x00\\x03\\x00\\x00\\xff\\xff\""
kombiniert mit folgendem Fehler aus dem ttn-Stack-Log:
stack_1 | WARN grpc: Server.Serve failed to create ServerTransport: connection error: desc = "transport: http2Server.HandleStreams received bogus greeting from client: \"POST / HTTP/1.1\\r\\nHost: 1\"" namespace=grpc

Ich hoffe, dass Sie oder jemand anderes mir helfen kann, diese Fehler zu beheben und zu wissen, was solche Fehler verursachen kann.

Nochmals vielen Dank für Ihre anhaltende Unterstützung!

Der Join-Server ist nur über https verfügbar.

Es sieht auch so aus, als ob NS js-server_ip über DNS auflösen kann.

Danke @johanstokking! Also ja, es stellt sich heraus, dass ich Port 8886 meinem Host in der docker-compose.yml nicht zugeordnet habe. Jetzt ist das Problem, mit dem ich konfrontiert bin, ein TLS-Handshake-Fehler:

tls: failed to verify client's certificate: x509: certificate signed by unknown authority

Zum einen habe ich das Flag --tls.insecure-skip-verify aber es bestand trotzdem darauf, das Zertifikat zu überprüfen und gab mir den gleichen Fehler. Ich denke, das Problem ist, dass ich der Zertifizierungsstelle in meinem Docker-Container vertrauen muss. Ich öffnete eine Shell im Stack und es gab mir einen Permission denied Fehler, wenn ich versuche, die Zertifikate in /usr/local/share/ca-certificates/ zu kopieren, um ihnen von der Maschine zu vertrauen.

Ich denke, das Flag --tls.insecure-skip-verify hätte es zulassen sollen, aber vielleicht ist Ihre Implementierung anders. Mein Problem ist jetzt, dass der Docker-Container mir keine Option bietet, meinem selbstsignierten Zertifikat zu vertrauen. Fehlt mir da etwas?

Ist das Client-Zertifikat von einer der CAs für SenderID signiert, wie in der Client-CA-Konfiguration definiert ?

Dies verwendet der Join-Server, um das Client-Zertifikat zu überprüfen; nicht das Systemvertrauen oder so.

Ich habe versucht, dem zu folgen, aber es stimmt nicht vollständig mit den Anweisungen auf der Website überein .
In meiner config.yml habe ich folgendes:

000000: ca-000000.pem
join-servers:
  - file: './example/js.yml'
    join-euis:
    - 'abcd000000000000/16'

und dann füge ich das in meine js.yml ein:

fqdn: 'thethings.example'
port: 8886
protocol: 'BI1.0'
tls:
  root-ca: 'path/to/clientca.pem'
  certificate: 'path/to/clientcert.pem'
  key: 'path/to/clientkey.pem'

Die Absender-Client-CAs sind noch nicht dokumentiert, wir werden dies als Teil des Schließens oder Ersetzens dieses Problems tun. Siehe (hier) [ https://github.com/TheThingsNetwork/lorawan-stack/issues/1818#issuecomment -575534345]. Es ist eine spezielle Datei und hat eine eigene Einstellung, um auf die Datei zu verweisen:

      --interop.sender-client-ca.blob.bucket string                    Bucket to use
      --interop.sender-client-ca.blob.path string                      Path to use
      --interop.sender-client-ca.directory string                      OS filesystem directory, which contains sender client CA configuration
      --interop.sender-client-ca.source string                         Source of the sender client CA configuration (static, directory, url, blob)
      --interop.sender-client-ca.url string                            URL, which contains sender client CA configuration

Also muss source auf directory und Sie legen die Konfiguration im oben genannten Format in config.yml in diesem Ordner ab. Das ist ein anderes Verzeichnis als die Interop-Konfiguration.

Danke @johanstokking! Mir war nicht klar, dass sich das in einem anderen Verzeichnis befinden sollte, ich habe das Zertifikatsproblem endlich überwunden und behandle jetzt diesen Fehler aus dem ttn-stack-Debug-Protokoll (ich habe die Schlüssel absichtlich vertuscht, aber sie waren korrekt):

stack_1      |   INFO Join not accepted                        dev_eui=0000000000000000 error=error:pkg/redis:not_found (entity not found) join_eui=0000000000000000 method=POST namespace=joinserver/interop remote_addr=gateway_ip:49426 request_id=01E1D3PZ63CQ7VNCE5JE8SDC3J url=/
stack_1      |   INFO Request handled                          duration=2.948762ms error=error:pkg/interop:join_req (join-request failed) error_cause=error:pkg/redis:not_found (entity not found) method=POST namespace=interop remote_addr=gateway_ip:49426 request_id=01E1D3PZ63CQ7VNCE5JE8SDC3J status=400 url=/

Beachten Sie, dass gateway_ip auch der Ort ist, an dem sich NS und AS befinden.

Das sehe ich auch im NS-Debug-Log:

time="2020-02-18T16:36:52-05:00" level=error msg="uplink: processing uplink frame error" ctx_id=ef20804f-13a8-4f7f-b90e-ce279c1e11ea error="join-request to join-server error: response error, code: JoinReqFailed, description: error:pkg/redis:not_found (entity not found)"

Nach allem, was ich lesen kann, scheint sich der Fehler über eine Fehlkonfiguration meiner Redis-Komponente des Docker-Compose zu beschweren. Ich habe das Konfigurations-Tutorial noch einmal besucht, um sicherzustellen, dass alles übereinstimmt. Was ich in meiner Konfiguration hatte, war dies:

volumes:
      - ${DEV_DATA_DIR:-.env/data}/redis:/data

Also ging ich vor und änderte es in folgendes:

volumes:
    - './data/redis:/data'

Dann sah ich den folgenden Fehler, der mich nicht einmal den Stack ausführen lässt:

stack_1      | error:cmd/internal/shared:initialize_identity_server (could not initialize Identity Server)
stack_1      | --- error:pkg/identityserver:db_needs_migration (the database needs to be migrated)
stack_1      | --- pq: database "ttn_lorawan" does not exist

Ich war mir nicht sicher, ob diese Änderung überhaupt notwendig ist, unter ./data/redis/ sehe ich nur eine Datei ``appendonly.aof```, also scheint mir etwas zu fehlen.

Ich war mir nicht sicher, ob diese Änderung überhaupt notwendig ist, unter ./data/redis/ sehe ich nur eine Datei ``appendonly.aof```, also scheint mir etwas zu fehlen.

Nein, das ist eigentlich in Ordnung für Redis.

Ihr Gerät ist anscheinend nicht beim Join-Server registriert?

Oh das ist wahrscheinlich der Grund. Nun, ich habe nur das Flag --js.join-eui-prefix aber das scheint nicht genug zu sein. Ich stecke bei einem anderen Problem fest, das ich zu ignorieren versucht habe: Ausgabe 1942

Kann ich das Gerät registrieren, indem ich der Redis-Datenbank manuell Zeilen hinzufüge? Wenn ja, in welchem ​​Format? Das könnte mir helfen, das andere Problem in der Zwischenzeit weiterhin zu ignorieren.

Beim anderen Problem konnte ich auf das Dashboard zugreifen und das Gerät im Dashboard registrieren. Ich sehe jetzt einen Fehler, der sender unknown sagt, was meiner Meinung nach sich darüber beschwert, dass das Gateway nicht erkannt wird. Ich habe versucht, das Gateway von der Konsole aus hinzuzufügen, aber es sagt immer noch Disconnected . Ich habe versucht, die Adresse der gateway_ip und der server_ip einzugeben, aber beides schien noch keinen Unterschied zu machen.

Absender unbekannt bedeutet wahrscheinlich, dass die NetID des Endgeräts nicht auf die NetID Ihres Netzwerkservers eingestellt ist. Beide sollten auf 000000 .

Die NetID des Endgerätes können Sie per CLI mit ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000 einstellen

Mein ttn-lw-cli verhält sich seltsam, ich kann den Login-Befehl nur mit den Standardoptionen ausführen, und wenn ich etwas in einer Konfigurationsdatei oder Zertifizierungsstelle angebe, bekomme ich nur permission denied . Ich habe verschiedene Möglichkeiten ausprobiert, um Berechtigungen zu umgehen, indem ich chmod und chown geändert habe. Ich erhalte weiterhin permission denied . Wenn ich die Standardkonfigurationen ausführe, indem ich nur ttn-lw-cli login eintippe, erhalte ich:

Post https://localhost:8885/oauth/token: x509: certificate signed by unknown authority

Obwohl docker-compose up ohne Zertifikatsprobleme oder andere Fehler problemlos läuft. Irgendeine Idee, was ich übersehen könnte, was wahrscheinlich dazu führt, dass die Berechtigungen verweigert werden?
Vielen Dank!

Können Sie Ihre Server- und CLI-Konfiguration posten und was Sie genau versuchen?

Ich habe gerade versucht, mich zuerst mit dem Befehl sudo ttn-lw-cli login anzumelden, hier ist meine Konfiguration:

# sudo ttn-lw-cli config
                         --allow-unknown-hosts="false"
                  --application-server-enabled="true"
             --application-server-grpc-address="localhost:8884"
                                          --ca=""
                                      --config="/etc/ttn-cli/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.config/.ttn-lw-cli.yml"
                              --credentials-id=""
         --device-claiming-server-grpc-address="localhost:8884"
      --device-template-converter-grpc-address="localhost:8884"
                      --gateway-server-enabled="true"
                 --gateway-server-grpc-address="localhost:8884"
                --identity-server-grpc-address="localhost:8884"
                                --input-format="json"
                                    --insecure="false"
                         --join-server-enabled="true"
                    --join-server-grpc-address="localhost:8884"
                                   --log.level="info"
                      --network-server-enabled="true"
                 --network-server-grpc-address="localhost:8884"
                        --oauth-server-address="https://localhost:8885/oauth"
                               --output-format="json"
              --qr-code-generator-grpc-address="localhost:8884"

Das Ausführen der Standardeinstellung gibt mir den certificate signed by unknown authority Fehler, den ich zuvor geteilt habe. Aufgrund der Zertifikatsprobleme habe ich jedoch versucht, die folgende Option hinzuzufügen: sudo ttn-lw-cli login --ca "path/to/ca.pem" aber das gab mir einen Berechtigungsverweigerungsfehler.

Ich habe versucht, die folgende Option hinzuzufügen: sudo ttn-lw-cli login --ca "path/to/ca.pem"

Das ist gut. Sie können dies auch in eine Konfigurationsdatei oder Umgebung einfügen.

aber das gab mir einen Erlaubnisfehler.

Auf der CLI oder dem Server? Hast du Protokolle?

Serverfehler denke ich? das ist alles was ich sehen kann:

root<strong i="6">@myserver</strong>:/etc/ttn-cli# sudo ttn-lw-cli login --ca="/etc/ttn-cli/ca.pem" --log.level="debug"
open /etc/ttn-cli/ca.pem: permission denied

Ich habe auch versucht, ihm chmod 777 Berechtigungen zu erteilen und immer noch den gleichen Fehler zu erhalten.

Ich konnte dieses Problem endlich umgehen, indem ich die Konfigurationsdatei zu /root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml hinzugefügt habe!

Ich erhalte jetzt einen certificate signed by unknown authority Fehler. Wie vertraut das ttn-lw-cli Tool einem Zertifikat? Hier ist das vollständige Protokoll:

root<strong i="8">@localhost</strong>:/etc/ttn-stack# sudo ttn-lw-cli login --callback=false --config="/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml" --log.level="debug" --insecure="true" --allow-unknown-hosts="true" --ca="/root/snap/ttn-lw-stack/149/ca.pem"
  WARN Access token expired at 5:17PM
 ERROR Please login with the login command
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:1884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00087caa0, {CONNECTING <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00087caa0, {READY <nil>}
 DEBUG Finished unary call                      duration=2.376756ms grpc_method=AuthInfo grpc_service=ttn.lorawan.v3.EntityAccess namespace=grpc
  INFO Opening your browser on https://localhost/oauth/authorize?client_id=cli&redirect_uri=code&response_type=code
  WARN Could not open your browser, you'll have to go there yourself error=fork/exec /usr/bin/xdg-open: permission denied
  INFO After logging in and authorizing the CLI, we'll get an access token for future commands.
  INFO Please paste the authorization code and press enter
> MF2XI.JX2QFUHNVVWMEYTTRQ3S4DTGPI5VXBYJWVJQ2ZI.OG5C4HQXGMRQ4LVW7ES4IZRNH2L5OJOING2SWOW74LFLQAYDH64Q
 ERROR Could not exchange OAuth access token    error=Post https://localhost/oauth/token: x509: certificate signed by unknown authority
Post https://localhost/oauth/token: x509: certificate signed by unknown authority

Ich verwende das gleiche ca.pem, dem das ttn-stack vertraut, das ich mit docker-compose ausführe.

Ich habe das Problem mit dem Login/Zertifikat wieder überwunden, indem ich http-URI und http-Ports in der ttn-lw-cli Konfiguration verwendet habe. Wenn ich sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug" ausführe, sehe ich Folgendes:

root<strong i="8">@localhost</strong>:/etc/ttn-stack$ sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug"
 DEBUG Using access token (valid until 6:42PM)
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:1884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {CONNECTING <nil>}
  WARN grpc: addrConn.createTransport failed to connect to {localhost:1884  <nil> 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: context deadline exceeded". Reconnecting...
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {TRANSIENT_FAILURE connection error: desc = "transport: authentication handshake failed: context deadline exceeded"}
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc000414730, {CONNECTING <nil>}
  WARN grpc: addrConn.createTransport failed to connect to {localhost:1884  <nil> 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

Hier ist meine ttn-lw-cli Konfiguration:

                         --allow-unknown-hosts="true"
                  --application-server-enabled="true"
             --application-server-grpc-address="localhost:1884"
                                          --ca="/root/snap/ttn-lw-stack/149/ca.pem"
                                      --config="/etc/ttn-stack/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml,/root/snap/ttn-lw-stack/149/.config/.ttn-lw-cli.yml"
                              --credentials-id=""
         --device-claiming-server-grpc-address="localhost:1884"
      --device-template-converter-grpc-address="localhost:1884"
                      --gateway-server-enabled="true"
                 --gateway-server-grpc-address="localhost:1884"
                --identity-server-grpc-address="localhost:1884"
                                --input-format="json"
                                    --insecure="true"
                         --join-server-enabled="true"
                    --join-server-grpc-address="localhost:1884"
                                   --log.level="info"
                      --network-server-enabled="true"
                 --network-server-grpc-address="localhost:1884"
                        --oauth-server-address="http://localhost/oauth"
                               --output-format="json"
              --qr-code-generator-grpc-address="localhost:1884"

Ich denke, dass dies mit meinem http-Setup zusammenhängen könnte, obwohl ich nach der Anmeldung eine INFO Got OAuth access token Meldung hatte, die eine erfolgreiche Authentifizierung anzuzeigen scheint.

Ich begann auch, den folgenden Fehler in meinen docker-compose Protokollen zu sehen:

stack_1      |  DEBUG Rejected authentication                  client_id=mqtt_5bc528ca.ae4ea8 error=error:pkg/ttnpb:identifiers (invalid identifiers) error_cause=error:pkg/errors:validation (invalid `application_id`: value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$") field=application_id name=ApplicationIdentifiersValidationError namespace=applicationserver/io/mqtt reason=value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$" username=
stack_1      |   WARN Failed to setup connection               error=error:pkg/ttnpb:identifiers (invalid identifiers) error_cause=error:pkg/errors:validation (invalid `application_id`: value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$") field=application_id name=ApplicationIdentifiersValidationError namespace=applicationserver/io/mqtt reason=value does not match regex pattern "^[a-z0-9](?:[-]?[a-z0-9]){2,}$" remote_addr=172.18.0.1:57472

Ich konnte nicht herausfinden, worauf es sich bezieht, aber ich dachte, es könnte sich über dasselbe Gerät und dieselbe Anwendung beschweren, die ich hinzugefügt habe und der Sensor immer noch nicht angeschlossen ist.

Ich erhalte jetzt einen certificate signed by unknown authority Fehler. Wie vertraut das ttn-lw-cli Tool einem Zertifikat?

Es verwendet die CA-Datei, die Sie mit ca . Diese Datei sollte entweder auf das Serverzertifikat verweisen (wenn es selbstsigniert ist) oder auf die Zertifizierungsstelle, die das Serverzertifikat signiert hat.

Hier ist meine ttn-lw-cli Konfiguration:

Diese Konfiguration sieht gut aus, wenn Sie TLS nicht verwenden möchten. Aber hört der Server diese Adressen in seiner Nicht-TLS-Konfiguration ab?

Ich begann auch, den folgenden Fehler in meinen docker-compose Protokollen zu sehen:

Dies ist ein MQTT-Client, der sich mit einem Benutzernamen verbindet, der keine gültige Anwendungs-ID ist.

Danke für die Hinweise! Das Zeigen auf cert.pem anstelle von ca.pem löste das Problem mit certificate signed by unknown authority . Allerdings erhalte ich immer noch den anderen Verbindungsfehler. Ich höre definitiv auf Port 1884 :

user<strong i="10">@localhost</strong>:/etc/ttn-stack$ sudo netstat -tulpn | grep LISTEN
tcp6       0      0 :::1884                 :::*                    LISTEN      18793/docker-proxy

Ich kann auch sehen, dass Datenpakete durchkommen, wenn ich mit dem Port 1884 telnet und das Tool ttn-lw-cli ausführe. Es findet also definitiv ein Austausch von Paketen statt, aber das Debug-Protokoll gibt mir immer noch die folgende Fehlermeldung: "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

Ich habe dieses Problem endlich gelöst, indem ich das --insecure Flag zum end-device set Befehl hinzugefügt habe!! Es scheint, dass ich Probleme mit TLS habe, aber darüber mache ich mir jetzt sowieso keine Sorgen
Danke noch einmal!

Ich freue mich, Ihnen mitteilen zu können, dass nach dem Setzen von --root-keys.app-key.key zusätzlich zu --net-id der Beitrittsprozess für end-device erfolgreich abgeschlossen wurde und ich damit begonnen habe, die Daten vom Endgerät auf dem unabhängigen Gerät zu erhalten Anwendungsserver! Nochmals vielen Dank für Ihre großartige Hilfe bei all den Problemen, mit denen ich konfrontiert war!

Das ist großartig! Es wäre toll, wenn Sie Ihr Szenario hier dokumentieren könnten, damit wir es einarbeiten können.

Danke auch für die Motivation und das erste Pfannkuchen zu sein.