Lorawan-stack: Prise en charge de l'installation de serveurs sur différents emplacements

Merci pour la suggestion @zamashal

En effet, la mise en route concerne actuellement l'approche processus unique, mais comme vous l'avez peut-être vu, vous pouvez démarrer les composants individuellement. Voir;

$ 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]

Il n'est pas très difficile de générer des services par composant lorsque ces services font partie du même cluster et sous-réseau.

Je limite ce problème pour l'instant aux instructions sur la façon de procéder ;

• Installer un serveur d'identité autonome
• Installer un serveur de jointure autonome
• Installez un cluster de routage avec Gateway Server, Network Server et Application Server qui utilise les services autonomes

@johanstokking Merci beaucoup pour votre réponse et l'ajout du problème au backlog. En attendant, je me demande si vous pouvez m'aider. J'ai démarré le serveur de jointure seul avec la commande suivante :
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

Ce que je ne peux pas comprendre, c'est à quel port le Join Server reçoit le Join_Req et va-t-il envoyer automatiquement le Join_Ans au serveur réseau spécifié ?

Merci encore!

@zamashal en fait JS est le serveur et NS et AS sont des clients. Configurez donc l'adresse du cluster JS dans NS et AS. Cela les fait fonctionner dans le même cluster, bien qu'il s'agisse de composants individuels. Notez que cela utilise l'authentification de cluster, qui est conçue pour les composants qui se font confiance dans le même cluster. Si vous déployez GS, NS et AS en périphérie, et JS dans le cloud, ce n'est probablement pas le cas.

Dans ce cas, vous devez utiliser l'interopérabilité, via les interfaces backend LoRaWAN, qui sont également prises en charge. Cela permet à NS de contacter votre JS via l'authentification client TLS.

Cela se fait en deux parties : configurer le NS pour utiliser votre JS et configurer votre JS avec la configuration interop (voir --help ). Ce n'est pas encore entièrement documenté non plus, malheureusement.

Merci encore @johanstokking ! J'ai essayé de faire fonctionner cette configuration comme vous l'avez expliqué. Il y a une chose qui m'embrouille. Sur le lien que vous avez fourni, il y a un exemple sur la façon de configurer l' interopérabilité avec Semtech Join Server . Cependant, j'essaie d'utiliser le serveur de jonction de TTN Stack lui-même, et non quelque chose d'externe comme celui de Semtech ou d'autres. Dois-je encore mettre la configuration pour configure.yml et example/js.yml ? Si oui, à quoi cela ressemblerait-il alors ?

J'ai déjà configuré mon NS pour qu'il fonctionne avec un JS externe (alias, JS de TTN Stack), mais en utilisant le port 8886 (Interop/tls) du serveur de jointure pour envoyer le Join_Req, la connexion est refusée bien que le JS semble écouter sur ce port.

Merci!

@zamashal Voici à peu près les choses à faire;

Rejoindre la configuration d'interopérabilité du serveur

Voir les drapeaux :

      --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 possède son propre écouteur dédié qui utilise l'authentification client TLS. Vous pouvez utiliser la même adresse IP publique que pour gRPC et utiliser un port d'interopérabilité dédié (par défaut 8886).

Vous avez besoin d'une autorité de certification privée qui émet des certificats clients. Ceux-ci sont utilisés en périphérie par NS. Vous pouvez configurer les CA clientes de confiance dans le serveur de jointure, et cela par NetID. Vous pouvez toujours utiliser les NetIDs 000000 et 000001 dans votre réseau privé, ou rejoindre la LoRa Alliance et vous en obtenez un vous-même.

Définissez interop.sender-client-ca.source sur directory et mettez-y un config.yml avec par exemple :

# Experimentation
000000: ca-000000.pem

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

Votre CA privé va dans ca-000000.pem . Vous pouvez ajouter le CA de TTN pour le NetID TTN comme dans l'exemple, juste pour vous montrer comment cela fonctionne.

Configuration de l'interopérabilité du serveur réseau

C'est comme documenté , mais en effet, ce dont vous avez besoin, c'est de la configuration JS locale. Ce serait comme suit :

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'

Ici, thethings.example est le FQDN de votre Join Server et 8886 le port de ce listen-tls que vous avez configuré dans l'interopérabilité JS.

De plus, root-ca est (contrairement à ce que dit l'exemple) l'autorité de certification racine du _certificat de serveur_. Cela pourrait être le même CA. Vous pouvez également l'omettre si vous utilisez un certificat de serveur commercial (ou Let's Encrypt) qui est déjà approuvé par NS.

Activez les journaux de débogage de chaque côté ( log.level=debug ) et vous devriez voir les choses fonctionner ou expliquer pourquoi les choses ne fonctionnent pas. Bonne chance!

De plus, si vous faites en sorte que cela fonctionne, n'hésitez pas à déposer une demande de tirage pour documenter cela. Il faudrait probablement un guide, mais la page de référence a également besoin d'un peu d'amour.

@johanstokking , je vais travailler dessus et j'espère que dès que je comprendrai, je serai sûr de faire une pull request pour mettre à jour le guide. Je ne vous remercierai jamais assez pour toute votre aide !

Salut @johanstokking - J'espère que tout se passe bien pour toi. Je voudrais vous tenir au courant de mes progrès. Malheureusement, j'ai corrigé beaucoup d'erreurs pour que cela fonctionne et je vais partager avec vous ici les dernières erreurs auxquelles je suis confronté. Après avoir configuré l'interopérabilité et configuré mon serveur réseau pour envoyer des demandes de jointure au serveur de jointure sur le port par défaut 8886, je continue à recevoir l'erreur suivante sur le journal de mon serveur réseau :
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"

Si je configure mon serveur réseau pour envoyer les demandes de jointure au port 1884 du serveur gRPC, j'obtiens à la place l'erreur suivante sur le journal du serveur réseau :
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\""
combiné avec l'erreur suivante du journal de la pile ttn :
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

J'espère que vous ou quelqu'un d'autre pouvez m'aider à comprendre comment résoudre ces erreurs et savoir ce qui peut provoquer de telles erreurs.

Merci encore pour votre soutien continu!

Le serveur de jointure n'est disponible que sur https.

Il semble également que NS ne puisse pas résoudre js-server_ip via DNS.

Merci @johanstokking ! Alors oui, il s'avère que je n'ai pas mappé le port 8886 à mon hôte dans le fichier docker-compose.yml. Maintenant, le problème auquel je suis confronté est une erreur de négociation TLS :

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

D'une part, j'ai utilisé le drapeau --tls.insecure-skip-verify mais il a quand même insisté pour vérifier le certificat et m'a donné la même erreur. Je pense que le problème est que je dois faire confiance à l'autorité de certification dans mon conteneur Docker. J'ai ouvert un shell dans la pile et cela m'a donné une erreur Permission denied chaque fois que j'essaie de copier les certificats dans /usr/local/share/ca-certificates/ afin de leur faire confiance par la machine.

Je pense que le drapeau --tls.insecure-skip-verify aurait dû le permettre, mais peut-être que votre implémentation est différente. Mon problème maintenant est que le conteneur Docker ne me donne pas la possibilité de faire confiance à mon certificat auto-signé. Y a-t-il quelque chose qui me manque là-bas?

Le certificat client est-il signé par l'une des autorités de certification pour le SenderID tel que défini dans la configuration de l'autorité de certification client ?

C'est ce que le serveur de jointure utilise pour vérifier le certificat client ; pas la confiance du système ou quoi que ce soit.

J'ai essayé de suivre cela, mais ce n'est pas complètement conforme aux instructions du site Web .
Ce que j'ai est le suivant dans mon config.yml :

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

puis j'ai mis ceci dans mon js.yml :

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'

Les autorités de certification client expéditeur ne sont pas encore documentées, nous le ferons dans le cadre de la clôture ou du remplacement de ce problème. Voir (ici)[ https://github.com/TheThingsNetwork/lorawan-stack/issues/1818#issuecomment -575534345]. C'est un fichier spécial et il a son propre paramètre pour référencer le fichier :

      --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

Donc, source doit être défini sur directory et vous mettez la configuration au format susmentionné dans config.yml dans ce dossier. C'est un répertoire différent de celui de la configuration d'interopérabilité.

Merci @johanstokking ! Je ne savais pas que cela devrait être dans un répertoire différent, j'ai finalement surmonté le problème des certificats et je traite maintenant cette erreur du journal de débogage ttn-stack (j'ai intentionnellement caché les clés, mais elles étaient correctes):

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=/

Notez que gateway_ip est également l'endroit où résident le NS et l'AS.

C'est aussi ce que je vois sur le journal de débogage NS :

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)"

D'après ce que je peux lire, l'erreur semble se plaindre d'une mauvaise configuration de mon composant redis du docker-compose. J'ai revisité le tutoriel de configuration pour m'assurer que tout correspond. Ce que j'avais sur ma configuration était ceci:

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

Alors je suis allé de l'avant et je l'ai changé en ceci:

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

Ensuite, j'ai commencé à voir l'erreur suivante qui ne me permet même pas d'exécuter la pile :

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

Je ne savais pas du tout si ce changement était nécessaire, sous ./data/redis/ je ne vois qu'un seul fichier ``appendonly.aof```, il semble donc qu'il me manque quelque chose.

Je ne savais pas du tout si ce changement était nécessaire, sous ./data/redis/ je ne vois qu'un seul fichier ``appendonly.aof```, il semble donc qu'il me manque quelque chose.

Non, c'est bien pour Redis en fait.

Il semble que votre appareil ne soit pas enregistré dans le serveur de connexion ?

Oh c'est probablement pourquoi. Eh bien, tout ce que j'ai fait, c'est d'utiliser le drapeau --js.join-eui-prefix mais il semble que ce ne soit pas suffisant. Je suis bloqué sur un autre problème que j'ai essayé d'ignorer : le problème 1942

Puis-je enregistrer l'appareil en ajoutant manuellement des lignes à la base de données redis ? Si oui, quel est le format ? Cela pourrait m'aider à continuer à ignorer l'autre problème en attendant..

J'ai pu accéder au tableau de bord sur l'autre problème et enregistrer l'appareil sur le tableau de bord. Je vois maintenant une erreur qui dit sender unknown qui, je crois, se plaint du fait que la passerelle n'est pas reconnue. J'ai essayé d'ajouter la passerelle à partir de la console mais elle dit toujours Disconnected . J'ai essayé d'entrer l'adresse de gateway_ip et server_ip mais les deux ne semblaient pas encore faire de différence.

Expéditeur inconnu signifie probablement que le NetID du périphérique final n'est pas défini sur le NetID de votre serveur réseau. Les deux doivent être définis sur 000000 .

Vous pouvez définir le NetID du périphérique final via CLI avec ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000

Mon ttn-lw-cli agit bizarrement, je ne peux exécuter la commande de connexion qu'avec les options par défaut, et si je spécifie un fichier de configuration ou une autorité de certification, je reçois juste permission denied . J'ai essayé plusieurs façons de contourner les autorisations en changeant chmod et chown, je continue à obtenir permission denied . Si j'exécute les configurations par défaut en tapant uniquement ttn-lw-cli login j'obtiens :

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

Bien que docker-compose up fonctionne très bien sans problèmes de certificat ni aucune autre erreur. Avez-vous une idée de ce que je pourrais manquer, ce qui est probablement à l'origine des autorisations refusées ?
Merci!

Pouvez-vous publier votre configuration de serveur et de CLI et ce que vous essayez de faire exactement ?

J'essayais juste de me connecter d'abord avec la commande sudo ttn-lw-cli login , voici ma config :

# 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"

Donc, exécuter la valeur par défaut me donne l'erreur certificate signed by unknown authority que j'ai partagée plus tôt. Mais en raison des problèmes de certificat, j'ai tenté d'ajouter l'option suivante : sudo ttn-lw-cli login --ca "path/to/ca.pem" mais cela m'a donné une erreur d'autorisation refusée.

J'ai essayé d'ajouter l'option suivante : sudo ttn-lw-cli login --ca "path/to/ca.pem"

C'est bon. Vous pouvez également le mettre dans un fichier de configuration ou un environnement.

mais cela m'a donné une erreur de permission refusée.

Sur la CLI ou le serveur ? Avez-vous des journaux?

erreur de serveur je pense ? c'est tout ce que je vois :

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

J'ai également essayé de lui donner des autorisations chmod 777 et j'ai toujours la même erreur ..

J'ai enfin pu contourner ce problème en ajoutant le fichier de configuration à /root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml !

J'obtiens maintenant une erreur certificate signed by unknown authority . Comment l'outil ttn-lw-cli confiance à un certificat ? Voici le journal complet :

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

J'utilise le même ca.pem auquel fait confiance le ttn-stack que j'exécute avec docker-compose.

J'ai à nouveau surmonté le problème de connexion/certificat en utilisant les ports URI http et http dans la configuration ttn-lw-cli . Lorsque j'exécute sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug" , je vois ce qui suit :

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...

Voici ma configuration ttn-lw-cli :

                         --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"

Je pense que cela pourrait être lié à ma configuration http, bien que j'aie eu INFO Got OAuth access token message

J'ai également commencé à voir l'erreur suivante dans mes journaux docker-compose :

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

Je ne pouvais pas comprendre à quoi cela faisait référence, mais j'ai pensé qu'il pourrait se plaindre du même appareil et de la même application que j'ai ajoutés et que le capteur n'est toujours pas connecté.

J'obtiens maintenant une erreur certificate signed by unknown authority . Comment l'outil ttn-lw-cli confiance à un certificat ?

Il utilise le fichier CA que vous transmettez avec ca . Ce fichier doit pointer vers le certificat du serveur (s'il est auto-signé) ou l'autorité de certification qui a signé le certificat du serveur.

Voici ma configuration ttn-lw-cli :

Cette configuration semble bonne si vous ne voulez pas utiliser TLS. Mais, le serveur écoute-t-il sur ces adresses, dans sa configuration non-TLS ?

J'ai également commencé à voir l'erreur suivante dans mes journaux docker-compose :

Il s'agit d'un client MQTT se connectant avec un nom d'utilisateur qui n'est pas un ID d'application valide.

Merci pour les astuces ! Pointer sur cert.pem au lieu de ca.pem résolu le problème de certificate signed by unknown authority . Cependant, je reçois toujours l'autre erreur de connexion. J'écoute définitivement sur le port 1884 :

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

Je peux également voir des paquets de données arriver lorsque je me connecte au port 1884 et lance l'outil ttn-lw-cli . Il y a donc bien un échange de paquets, mais le journal de débogage me donne toujours l'erreur suivante : "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

J'ai finalement résolu ce problème en ajoutant le drapeau --insecure à la commande end-device set !! Il semble que j'ai des problèmes avec TLS, mais je ne m'en inquiète pas maintenant de toute façon
Merci encore!

Je suis ravi de vous informer qu'après avoir défini --root-keys.app-key.key en plus de --net-id , le processus de jointure pour end-device terminé avec succès et j'ai commencé à obtenir les données de l'appareil final sur l'indépendant Serveur d'application! Merci encore pour votre aide précieuse à travers tous les problèmes que j'ai rencontrés!

C'est génial! Ce serait génial si vous pouviez documenter votre scénario ici, afin que nous puissions l'intégrer.

Merci aussi pour la motivation et d'être la première crêperie.