Lorawan-stack: Dukungan untuk menginstal server di lokasi yang berbeda

Terima kasih atas sarannya @zamashal

Memang, Memulai saat ini untuk pendekatan proses tunggal, tetapi seperti yang mungkin telah Anda lihat, Anda dapat memulai komponen satu per satu. Lihat;

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

Tidak terlalu sulit untuk menelurkan layanan per komponen ketika layanan ini merupakan bagian dari cluster dan subnet yang sama.

Saya membatasi masalah ini untuk saat ini ke instruksi tentang cara;

• Instal Server Identitas yang berdiri sendiri
• Instal Server Bergabung yang berdiri sendiri
• Instal cluster perutean dengan Server Gateway, Server Jaringan, dan Server Aplikasi yang menggunakan layanan yang berdiri sendiri

@johanstokking Terima kasih banyak atas tanggapan Anda dan menambahkan masalah ke backlog. Sementara itu, saya ingin tahu apakah Anda dapat membantu saya dengan ini. Saya memulai server bergabung sendiri dengan perintah berikut:
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

Apa yang saya tidak tahu adalah di port mana Server Bergabung menerima Join_Req dan apakah itu akan secara otomatis mengirim Join_Ans ke Server Jaringan yang ditentukan?

Terima kasih lagi!

@zamashal sebenarnya JS adalah server dan NS dan AS adalah klien. Jadi konfigurasikan alamat cluster JS di NS dan AS. Itu membuat mereka bekerja di cluster yang sama, meskipun mereka adalah komponen individu. Perhatikan bahwa ini menggunakan otentikasi cluster, yang dirancang untuk komponen yang saling percaya dalam cluster yang sama. Jika Anda menggunakan GS, NS dan AS di edge, dan JS di cloud, ini mungkin bukan masalahnya.

Dalam hal ini, Anda harus menggunakan interop, melalui Antarmuka Backend LoRaWAN, yang juga didukung. Ini memungkinkan NS untuk menghubungi JS Anda melalui otentikasi klien TLS.

Itu datang dalam dua bagian: mengonfigurasi NS untuk menggunakan JS Anda dan mengonfigurasi JS Anda dengan konfigurasi interop (lihat --help ). Sayangnya, ini belum sepenuhnya didokumentasikan.

Terima kasih sekali lagi @johanstokking ! Saya telah mencoba membuat pengaturan ini berfungsi seperti yang Anda jelaskan. Ada satu hal yang membuatku bingung. Pada link yang Anda berikan, ada contoh cara mengatur Interoperabilitas dengan Semtech Join Server . Namun, saya mencoba menggunakan Server Gabung TTN Stack itu sendiri, dan bukan sesuatu yang eksternal seperti milik Semtech atau lainnya. Apakah saya masih perlu memasukkan konfigurasi untuk configure.yml dan example/js.yml ? Jika demikian, bagaimana tampilannya?

Saya telah mengonfigurasi NS saya untuk bekerja dengan JS eksternal (alias, JS TTN Stack), tetapi menggunakan port 8886 (Interop/tls) dari server bergabung untuk mengirim Join_Req, koneksi ditolak meskipun JS tampaknya mendengarkan di port itu.

Terima kasih!

@zamashal Berikut adalah kira-kira hal-hal yang perlu dilakukan;

Bergabunglah dengan konfigurasi interop Server

Lihat bendera:

      --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 memiliki pendengar khusus sendiri yang menggunakan otentikasi klien TLS. Anda dapat menggunakan alamat IP publik yang sama seperti untuk gRPC dan menggunakan port interop khusus (default 8886).

Anda memerlukan CA pribadi yang mengeluarkan sertifikat klien. Ini digunakan di tepi oleh NS. Anda dapat mengonfigurasi CA klien tepercaya di Join Server, dan ini per NetID. Anda selalu dapat menggunakan NetID 000000 dan 000001 di jaringan pribadi Anda, atau bergabung dengan Aliansi LoRa dan Anda akan mendapatkannya sendiri.

Atur interop.sender-client-ca.source menjadi directory dan masukkan config.yml dengan misalnya:

# Experimentation
000000: ca-000000.pem

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

CA pribadi Anda masuk ca-000000.pem . Anda dapat menambahkan CA TTN untuk TTN NetID seperti pada contoh, hanya untuk menunjukkan cara kerjanya.

Konfigurasi interop Server Jaringan

Ini seperti didokumentasikan , tetapi memang yang Anda butuhkan adalah konfigurasi JS lokal. Ini akan menjadi sebagai berikut:

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'

Di sini, thethings.example adalah FQDN dari Join Server Anda dan 8886 port dari listen-tls yang Anda konfigurasikan di interop JS.

Juga, root-ca adalah (tidak seperti yang dikatakan contoh) root CA dari _server certificate_. Ini bisa menjadi CA yang sama. Anda juga dapat mengabaikannya jika Anda menggunakan sertifikat server komersial (atau Let's Encrypt) yang sudah dipercaya oleh NS.

Aktifkan log debug di kedua sisi ( log.level=debug ) dan Anda akan melihat hal-hal bekerja atau melacak mengapa hal-hal tidak bekerja. Semoga beruntung!

Juga, jika Anda membuat ini berfungsi, jangan ragu untuk mengajukan permintaan tarik untuk mendokumentasikan ini. Mungkin akan membutuhkan panduan, tetapi halaman referensi juga membutuhkan cinta.

@johanstokking , saya akan mengerjakan ini dan semoga segera setelah saya mengetahuinya, saya pasti akan membuat permintaan tarik untuk memperbarui panduan. Tidak bisa cukup berterima kasih atas semua bantuan Anda!

Hai @johanstokking - Saya harap semuanya baik-baik saja dengan Anda. Saya ingin memberi tahu Anda tentang kemajuan saya. Sayangnya, saya telah mengatasi banyak kesalahan agar ini berfungsi dan saya akan berbagi dengan Anda di sini kesalahan terbaru yang saya hadapi. Setelah mengatur interop dan mengkonfigurasi server jaringan saya untuk mengirim permintaan bergabung ke server bergabung di port default 8886, saya terus mendapatkan kesalahan berikut pada log server jaringan saya:
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"

Jika saya mengonfigurasi server jaringan saya untuk mengirim permintaan bergabung ke port 1884 dari server gRPC, saya malah mendapatkan kesalahan berikut pada log server jaringan:
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\""
dikombinasikan dengan kesalahan berikut dari log tumpukan 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

Saya harap Anda atau siapa pun dapat membantu saya memahami cara mengatasi kesalahan ini dan mengetahui apa yang dapat menyebabkan kesalahan tersebut.

Sekali lagi terima kasih atas dukungan Anda yang berkelanjutan!

Join Server hanya tersedia melalui https.

Sepertinya NS juga tidak dapat menyelesaikan js-server_ip melalui DNS.

Terima kasih @johanstokking! Jadi ya ternyata saya tidak memetakan port 8886 ke Host saya di docker-compose.yml. Sekarang masalah yang saya hadapi adalah kesalahan jabat tangan TLS:

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

Untuk satu hal, saya menggunakan flag --tls.insecure-skip-verify tetapi masih bersikeras untuk memverifikasi sertifikat dan memberi saya kesalahan yang sama. Saya pikir masalahnya adalah saya harus mempercayai otoritas sertifikat di wadah buruh pelabuhan saya. Saya membuka Shell ke dalam tumpukan dan itu memberi saya kesalahan Permission denied setiap kali saya mencoba menyalin sertifikat ke /usr/local/share/ca-certificates/ untuk mempercayainya oleh mesin.

Saya pikir flag --tls.insecure-skip-verify seharusnya mengizinkannya, tetapi mungkin implementasi Anda berbeda. Masalah saya sekarang adalah bahwa wadah buruh pelabuhan tidak memberi saya opsi untuk mempercayai sertifikat yang saya tanda tangani sendiri. Apakah ada sesuatu yang saya lewatkan di sana?

Apakah sertifikat klien ditandatangani oleh salah satu CA untuk SenderID seperti yang didefinisikan dalam konfigurasi CA klien ?

Itulah yang digunakan Server Gabung untuk memverifikasi sertifikat klien; bukan sistem kepercayaan atau apa pun.

Saya mencoba mengikutinya, tetapi tidak sepenuhnya sesuai dengan petunjuk di situs web .
Apa yang saya miliki adalah yang berikut di config.yml saya:

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

dan kemudian saya memasukkan ini ke js.yml saya:

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'

CA klien pengirim belum didokumentasikan, kami akan melakukannya sebagai bagian dari menutup atau mengganti masalah ini. Lihat (di sini)[ https://github.com/TheThingsNetwork/lorawan-stack/issues/1818#issuecomment -575534345]. Ini adalah file khusus dan memiliki pengaturan sendiri untuk referensi file:

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

Jadi source perlu disetel ke directory dan Anda meletakkan konfigurasi dalam format yang disebutkan di atas di config.yml di folder itu. Itu adalah direktori yang berbeda dari konfigurasi interop.

Terima kasih @johanstokking! Saya tidak menyadari bahwa itu harus berada di direktori yang berbeda, saya akhirnya melewati masalah sertifikat dan sekarang menangani kesalahan ini dari log debug ttn-stack (saya sengaja menutupi kunci, tetapi mereka benar):

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

Catatan, gateway_ip juga merupakan tempat NS dan AS berada.

Ini juga yang saya lihat di log debug 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)"

Dari apa yang saya baca, kesalahan tampaknya mengeluhkan kesalahan konfigurasi komponen redis saya dari file docker-compose. Saya mengunjungi kembali tutorial konfigurasi untuk memastikan semuanya cocok. Apa yang saya miliki di konfigurasi saya adalah ini:

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

Jadi saya melanjutkan dan mengubahnya menjadi ini:

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

Kemudian, saya mulai melihat kesalahan berikut yang bahkan tidak memungkinkan saya menjalankan tumpukan:

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

Saya tidak yakin apakah perubahan ini diperlukan sama sekali, di bawah ./data/redis/ Saya hanya melihat satu file ``appendonly.aof```, jadi sepertinya saya melewatkan sesuatu..

Saya tidak yakin apakah perubahan ini diperlukan sama sekali, di bawah ./data/redis/ Saya hanya melihat satu file ``appendonly.aof```, jadi sepertinya saya melewatkan sesuatu..

Tidak, itu bagus untuk Redis sebenarnya.

Sepertinya perangkat Anda tidak terdaftar di Join Server?

Oh mungkin itu sebabnya. Yah yang saya lakukan hanyalah menggunakan flag --js.join-eui-prefix tetapi sepertinya itu tidak cukup. Saya terjebak pada masalah lain yang saya coba abaikan: masalah 1942

Bisakah saya mendaftarkan perangkat dengan menambahkan baris ke database redis secara manual? Jika ya, apa formatnya? Itu mungkin membantu saya terus mengabaikan masalah lain sementara itu..

Saya dapat mengakses dasbor pada masalah lain dan mendaftarkan perangkat di dasbor. Saya sekarang melihat kesalahan yang mengatakan sender unknown yang saya yakini mengeluh tentang gateway tidak dikenali. Saya mencoba menambahkan gateway dari konsol tetapi masih tertulis Disconnected . Saya mencoba memasukkan alamat gateway_ip dan server_ip tetapi keduanya tampaknya belum membuat perbedaan.

Pengirim tidak diketahui kemungkinan berarti bahwa NetID perangkat akhir tidak disetel ke NetID Server Jaringan Anda. Keduanya harus disetel ke 000000 .

Anda dapat mengatur NetID perangkat akhir melalui CLI dengan ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000

ttn-lw-cli bertingkah aneh, saya hanya dapat menjalankan perintah login dengan opsi default, dan jika saya menentukan sesuatu file konfigurasi atau otoritas sertifikat saya hanya mendapatkan permission denied . Saya mencoba beberapa cara di sekitar izin dengan mengubah chmod dan chown saya terus mendapatkan permission denied . Jika saya menjalankan konfigurasi default hanya dengan mengetik ttn-lw-cli login saya mendapatkan:

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

Meskipun docker-compose up berjalan dengan baik tanpa masalah sertifikat atau kesalahan lainnya. Adakah yang tahu apa yang mungkin saya lewatkan yang kemungkinan menyebabkan izin ditolak?
Terima kasih!

Bisakah Anda memposting konfigurasi server dan CLI Anda dan apa yang sebenarnya Anda coba lakukan?

Saya baru saja mencoba masuk terlebih dahulu dengan perintah sudo ttn-lw-cli login , ini konfigurasi saya:

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

Jadi menjalankan default memberi saya kesalahan certificate signed by unknown authority yang saya bagikan sebelumnya. Tetapi karena masalah sertifikat, saya mencoba menambahkan opsi berikut: sudo ttn-lw-cli login --ca "path/to/ca.pem" tetapi itu memberi saya kesalahan izin ditolak.

Saya mencoba menambahkan opsi berikut: sudo ttn-lw-cli login --ca "path/to/ca.pem"

Ini bagus. Anda juga dapat meletakkan ini di file konfigurasi atau lingkungan.

tapi itu memberi saya izin ditolak kesalahan.

Di CLI atau server? Apakah Anda memiliki log?

kesalahan server saya pikir? hanya ini yang bisa saya lihat:

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

Saya juga mencoba memberikan izin chmod 777 dan masih mendapatkan kesalahan yang sama..

Saya akhirnya bisa mengatasi masalah ini dengan menambahkan file konfigurasi ke /root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml !

Saya sekarang mendapatkan kesalahan certificate signed by unknown authority . Bagaimana alat ttn-lw-cli memercayai sertifikat? Berikut log lengkapnya:

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

Saya menggunakan ca.pem yang sama yang dipercaya oleh ttn-stack yang saya jalankan dengan docker-compose.

Saya berhasil melewati masalah login/sertifikat lagi dengan menggunakan http URI dan port http di konfigurasi ttn-lw-cli . Ketika saya menjalankan sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug" , saya melihat yang berikut:

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

Ini adalah konfigurasi 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"

Saya pikir ini bisa terkait dengan pengaturan http saya, meskipun saya memiliki pesan INFO Got OAuth access token setelah login yang tampaknya menunjukkan otentikasi yang berhasil.

Saya juga mulai melihat kesalahan berikut dari log 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

Saya tidak tahu apa yang dimaksud tetapi saya pikir itu mungkin mengeluh tentang perangkat dan aplikasi yang sama yang telah saya tambahkan dan sensor masih belum bergabung.

Saya sekarang mendapatkan kesalahan certificate signed by unknown authority . Bagaimana alat ttn-lw-cli memercayai sertifikat?

Ini menggunakan file CA yang Anda berikan ca . File itu harus mengarah ke sertifikat server (jika ditandatangani sendiri) atau CA yang menandatangani sertifikat server.

Ini adalah konfigurasi ttn-lw-cli :

Konfigurasi ini terlihat bagus jika Anda tidak ingin menggunakan TLS. Tapi, apakah server mendengarkan alamat ini, dalam konfigurasi non-TLS?

Saya juga mulai melihat kesalahan berikut dari log docker-compose :

Ini adalah klien MQTT yang terhubung dengan nama pengguna yang bukan ID aplikasi yang valid.

Terima kasih atas petunjuknya! Menunjuk ke cert.pem alih-alih ca.pem memecahkan masalah certificate signed by unknown authority . Namun, saya masih mendapatkan kesalahan koneksi lainnya. Saya pasti mendengarkan di port 1884 :

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

Saya juga dapat melihat paket data yang masuk ketika saya melakukan telnet ke port 1884 dan menjalankan alat ttn-lw-cli . Jadi pasti ada pertukaran paket yang terjadi, tetapi log debug masih memberi saya kesalahan berikut: "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

Saya akhirnya memecahkan masalah ini dengan menambahkan flag --insecure ke perintah end-device set !! Sepertinya saya mengalami masalah dengan TLS, tetapi saya tidak khawatir tentang itu sekarang
Terima kasih lagi!

Saya senang memberi tahu Anda bahwa setelah mengatur --root-keys.app-key.key selain --net-id , proses bergabung untuk end-device berhasil diselesaikan dan saya mulai mendapatkan data dari perangkat akhir di independen Server Aplikasi! Sekali lagi terima kasih atas bantuan besar Anda melalui semua masalah yang saya hadapi!

Itu hebat! Akan luar biasa jika Anda dapat mendokumentasikan skenario Anda di sini, sehingga kami dapat menggabungkannya.

Terima kasih juga atas motivasi dan menjadi pancake pertama.