Lorawan-stack: 다른 위치에 서버 설치 지원

@zamashal 제안 감사합니다.

실제로 시작하기는 현재 단일 프로세스 접근 방식을 위한 것이지만 이미 본 것처럼 구성 요소를 개별적으로 시작할 수 있습니다. 보다;

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

이러한 서비스가 동일한 클러스터 및 서브넷의 일부인 경우 구성 요소당 서비스를 생성하는 것은 그리 어렵지 않습니다.

지금은 이 문제의 범위를 다음 방법에 대한 지침으로 지정하고 있습니다.

• 독립 실행형 Identity Server 설치
• 독립 실행형 가입 서버 설치
• 독립형 서비스를 사용하는 게이트웨이 서버, 네트워크 서버 및 애플리케이션 서버와 함께 라우팅 클러스터 설치

@johanstokking 귀하의 응답과 백로그에 문제를 추가해 주셔서 대단히 감사합니다. 그 동안, 당신이 이것을 도와줄 수 있는지 궁금합니다. 다음 명령으로 조인 서버를 단독으로 시작했습니다.
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

내가 알 수없는 것은 Join 서버가 Join_Req를 수신하고 지정된 네트워크 서버에 Join_Ans를 자동으로 보낼 포트입니다.

다시 한번 감사합니다!

@zamashal 사실 JS는 서버이고 NS와 AS는 클라이언트입니다. 따라서 NS 및 AS에서 JS 클러스터 주소를 구성하십시오. 따라서 개별 구성 요소이지만 동일한 클러스터에서 작동합니다. 이것은 동일한 클러스터에서 서로를 신뢰하는 구성 요소를 위해 설계된 클러스터 인증을 사용합니다. 에지에 GS, NS 및 AS를 배포하고 클라우드에 JS를 배포하는 경우에는 그렇지 않을 수 있습니다.

이 경우 지원되는 LoRaWAN 백엔드 인터페이스를 통해 interop을 사용해야 합니다. 이를 통해 NS는 TLS 클라이언트 인증을 통해 JS에 연결할 수 있습니다.

JS를 사용하도록 NS를 구성하는 것과 interop 구성으로 JS를 구성하는 두 부분으로 구성됩니다( --help ). 이것은 불행히도 아직 완전히 문서화되지 않았습니다.

@johanstokking 다시 한번 감사드립니다! 나는 당신이 설명 한대로이 설정을 작동 시키려고 노력해 왔습니다. 한 가지 헷갈리는 것이 있습니다. 제공한 링크 에 Semtech Join Server와의 상호 운용성 을 설정하는 방법에 대한 예제가 있습니다. 그러나 Semtech 또는 기타와 같은 외부가 아닌 TTN Stack의 Join Server 자체를 사용하려고합니다. configure.yml 및 example/js.yml 에 대한 구성을 계속 입력해야 합니까? 그렇다면 어떻게 생겼을까?

외부 JS(TTN 스택의 JS라고도 함)와 함께 작동하도록 NS를 이미 구성했지만 Join_Req를 보내기 위해 조인 서버의 포트 8886 (Interop/tls)를 사용하면 연결이 거부되지만 JS는 해당 포트에서 수신 대기하는 것 같습니다.

감사 해요!

@zamashal 다음은 대략적으로 수행해야 할 작업입니다.

조인 서버 상호 운용성 구성

플래그 참조:

      --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에는 TLS 클라이언트 인증을 사용하는 자체 전용 수신기가 있습니다. gRPC와 동일한 공용 IP 주소를 사용하고 전용 interop 포트(기본값 8886)를 사용할 수 있습니다.

클라이언트 인증서를 발급하는 사설 CA가 필요합니다. 이들은 NS에 의해 에지에서 사용됩니다. 조인 서버에서 신뢰할 수 있는 클라이언트 CA를 구성할 수 있으며 이는 NetID별로 이루어집니다. 항상 개인 네트워크에서 NetID 000000 및 000001 를 사용하거나 LoRa Alliance에 가입하여 직접 얻을 수 있습니다.

interop.sender-client-ca.source 를 directory 하고 여기에 config.yml 과 같이 입력합니다.

# Experimentation
000000: ca-000000.pem

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

사설 CA는 ca-000000.pem 갑니다. 예제와 같이 TTN NetID에 대해 TTN의 CA를 추가하여 이것이 어떻게 작동하는지 보여줄 수 있습니다.

네트워크 서버 상호 운용성 구성

이것은 문서화 된 것과 같지만 실제로 필요한 것은 로컬 JS 구성입니다. 이것은 다음과 같을 것입니다:

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'

여기서 thethings.example 는 조인 서버의 FQDN이고 JS interop에서 구성한 listen-tls 의 8886 포트입니다.

또한 root-ca 는 (예시와 달리) _server 인증서_의 루트 CA입니다. 동일한 CA일 수 있습니다. NS에서 이미 신뢰하는 상용(또는 Let's Encrypt) 서버 인증서를 사용하는 경우에도 생략할 수 있습니다.

양쪽에서 디버그 로그를 활성화하면( log.level=debug ) 작동하는 것을 보거나 작동하지 않는 이유를 추적해야 합니다. 행운을 빕니다!

또한 이 작업을 수행하는 경우 이를 문서화하기 위한 풀 요청을 자유롭게 제출하십시오. 가이드가 필요할 수도 있지만 참조 페이지 에도 약간의 사랑이 필요합니다.

@johanstokking , 나는 이것에 대해 작업할 것이며,

안녕하세요 @johanstokking - 모든 일이 잘 되길 바랍니다. 진행 상황을 알려드리고 싶습니다. 불행히도, 저는 이 작업을 수행하기 위해 많은 오류를 해결해 왔으며 여기에서 제가 직면한 최신 오류를 공유하겠습니다. interop을 설정하고 기본 포트 8886에서 가입 서버로 가입 요청을 보내도록 네트워크 서버를 구성한 후 네트워크 서버 로그에 다음 오류가 계속 발생합니다.
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"

gRPC 서버의 포트 1884로 가입 요청을 보내도록 네트워크 서버를 구성하면 네트워크 서버 로그에 다음 오류가 대신 표시됩니다.
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\""
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

귀하 또는 다른 사람이 이러한 오류를 해결하는 방법을 이해하고 그러한 오류의 원인이 될 수 있는 원인을 아는 데 도움이 되기를 바랍니다.

귀하의 지속적인 지원에 다시 한 번 감사드립니다!

Join Server는 https를 통해서만 사용할 수 있습니다.

NS가 DNS를 통해 js-server_ip 를 확인할 수 없는 것 같습니다.

@johanstokking 감사합니다! 예, 포트 8886을 docker-compose.yml의 호스트에 매핑하지 않은 것으로 나타났습니다. 이제 내가 직면한 문제는 TLS 핸드셰이크 오류입니다.

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

우선 --tls.insecure-skip-verify 플래그를 사용했지만 여전히 인증서 확인을 요구하고 동일한 오류가 발생했습니다. 문제는 내 도커 컨테이너의 인증 기관을 신뢰해야 한다는 것입니다. 스택에 셸을 열었는데 컴퓨터에서 인증서를 신뢰하기 위해 인증서를 /usr/local/share/ca-certificates/ 에 복사하려고 할 때마다 Permission denied 오류가 발생했습니다.

--tls.insecure-skip-verify 플래그가 허용했어야 한다고 생각하지만 구현이 다를 수 있습니다. 이제 내 문제는 도커 컨테이너가 내 자체 서명 인증서를 신뢰할 수 있는 옵션을 제공하지 않는다는 것입니다. 거기에 내가 누락 된 것이 있습니까?

클라이언트 CA 구성에 정의된 대로 SenderID 에 대해 CA 중 하나가 클라이언트 인증서에 서명했습니까?

이것이 조인 서버가 클라이언트 인증서를 확인하는 데 사용하는 것입니다. 시스템 트러스트나 그 어떤 것도 아닙니다.

나는 그것을 따르려고했지만 웹 사이트 의 지침과 완전히 일치하지 않습니다.
내가 가지고있는 것은 내 config.yml에 다음과 같습니다.

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

그런 다음 이것을 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'

발신자 클라이언트 CA는 아직 문서화되지 않았으며 이 문제를 종결하거나 교체하는 과정에서 이를 수행할 것입니다. (여기)[ https://github.com/TheThingsNetwork/lorawan-stack/issues/1818#issuecomment -575534345]를

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

따라서 source 를 directory 로 설정해야 하며 앞서 언급한 형식의 구성을 해당 폴더에 config.yml 에 넣어야 합니다. interop 구성과 다른 디렉터리입니다.

@johanstokking 감사합니다! 나는 그것이 다른 디렉토리에 있어야한다는 것을 깨닫지 못했습니다. 마침내 인증서 문제를 극복하고 이제 ttn-stack 디버그 로그에서이 오류를 처리합니다 (의도적으로 키를 가렸지만 정확했습니다).

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

gateway_ip는 NS와 AS가 상주하는 곳이기도 합니다.

이것은 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)"

내가 읽을 수있는 것에서 오류는 docker-compose의 redis 구성 요소의 잘못된 구성에 대해 불평하는 것 같습니다. 모든 것이 일치하는지 확인하기 위해 구성 자습서를 다시 방문했습니다. 내 구성에 있었던 것은 다음과 같습니다.

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

그래서 다음과 같이 변경했습니다.

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

그런 다음 스택을 실행할 수 없는 다음 오류가 표시되기 시작했습니다.

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

이 변경이 필요한지 전혀 확신이 서지 않았습니다. ./data/redis/ 아래에는 ``appendonly.aof``` 파일이 하나만 표시되므로 뭔가 빠진 것 같습니다..

이 변경이 필요한지 전혀 확신이 서지 않았습니다. ./data/redis/ 아래에 ``appendonly.aof``` 파일이 하나만 표시되어 뭔가 빠진 것 같습니다..

아니요, 사실 Redis에는 괜찮습니다.

귀하의 장치가 Join Server에 등록되지 않은 것 같습니다.

아, 아마 그 때문일 것입니다. 글쎄, 내가 한 것은 --js.join-eui-prefix 플래그를 사용하는 것이지만 충분하지 않은 것 같습니다. 무시하려고 했던 또 다른 문제에 갇혔습니다: 문제 1942

수동으로 redis 데이터베이스에 행을 추가하여 장치를 등록할 수 있습니까? 그렇다면 형식은 무엇입니까? 그 동안 다른 문제를 계속 무시하는 데 도움이 될 수 있습니다.

다른 문제의 대시보드에 액세스하여 대시보드에 장치를 등록할 수 있었습니다. 이제 sender unknown 라는 오류가 표시되며 게이트웨이가 인식되지 않는다고 불평하는 것 같습니다. 콘솔에서 게이트웨이를 추가하려고 했지만 여전히 Disconnected 됩니다. gateway_ip와 server_ip의 주소를 입력하려고 했지만 둘 다 아직 아무런 차이가 없는 것 같습니다.

Sender unknown은 최종 장치의 NetID가 네트워크 서버의 NetID로 설정되지 않았음을 의미합니다. 둘 다 000000 로 설정해야 합니다.

ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000 하여 CLI를 통해 최종 장치의 NetID를 설정할 수 있습니다.

내 ttn-lw-cli 가 이상하게 작동하고 기본 옵션으로 로그인 명령만 실행할 수 있으며 구성 파일이나 인증 기관을 지정하면 permission denied 됩니다. chmod 및 chown 을 변경하여 권한에 대해 여러 가지 방법을 시도했지만 계속 permission denied 됩니다. ttn-lw-cli login 만 입력하여 기본 구성을 실행하면 다음을 얻습니다.

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

docker-compose up이 인증서 문제나 다른 오류 없이 잘 실행되고 있지만. 권한 거부의 원인이 될 수 있는 누락된 항목이 무엇인지 알고 있습니까?
감사 해요!

서버 및 CLI 구성과 정확히 무엇을 하려고 하는지 게시할 수 있습니까?

sudo ttn-lw-cli login 명령을 사용하여 먼저 로그인하려고 했습니다. 여기 내 구성이 있습니다.

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

따라서 기본값을 실행하면 이전에 공유한 certificate signed by unknown authority 오류가 발생합니다. 그러나 인증서 문제로 인해 sudo ttn-lw-cli login --ca "path/to/ca.pem" 옵션을 추가하려고 시도했지만 권한 거부 오류가 발생했습니다.

다음 옵션을 추가하려고 했습니다. sudo ttn-lw-cli login --ca "path/to/ca.pem"

이것은 좋은 것입니다. 이것을 구성 파일이나 환경에 넣을 수도 있습니다.

그러나 그것은 나에게 허가 거부 오류를 주었다.

CLI 또는 서버에서? 로그가 있습니까?

내가 생각하는 서버 오류? 이것이 내가 볼 수있는 전부입니다.

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

나는 또한 chmod 777 권한을 부여하려고 시도했지만 여전히 동일한 오류가 발생합니다..

/root/snap/ttn-lw-stack/149/.ttn-lw-cli.yml 구성 파일을 추가하여 마침내 이 문제를 해결할 수 있었습니다!

지금 certificate signed by unknown authority 오류가 발생합니다. ttn-lw-cli 도구는 인증서를 어떻게 신뢰합니까? 전체 로그는 다음과 같습니다.

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

docker-compose로 실행하는 ttn-stack 신뢰하는 것과 동일한 ca.pem을 사용하고 있습니다.

ttn-lw-cli 구성에서 http URI 및 http 포트를 사용하여 로그인/인증서 문제를 다시 해결했습니다. sudo ttn-lw-cli end-device set "mysensor1app" "mysensor1dev" --net-id=000000 --log.level="debug" 실행하면 다음이 표시됩니다.

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

다음은 내 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"

로그인 후 성공적인 인증을 나타내는 INFO Got OAuth access token 메시지가 있었지만 이것이 내 http 설정과 관련이 있을 수 있다고 생각합니다.

또한 내 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

나는 그것이 무엇을 말하는지 알 수 없었지만 내가 추가했지만 여전히 센서가 연결되지 않은 동일한 장치 및 응용 프로그램에 대해 불평하는 것일 수 있다고 생각했습니다.

지금 certificate signed by unknown authority 오류가 발생합니다. ttn-lw-cli 도구는 인증서를 어떻게 신뢰합니까?

ca 전달한 CA 파일을 사용합니다. 해당 파일은 서버 인증서(자체 서명된 경우) 또는 서버 인증서에 서명한 CA를 가리켜야 합니다.

다음은 내 ttn-lw-cli 구성입니다.

이 구성은 TLS를 사용하지 않으려는 경우에 적합합니다. 그러나 서버가 비 TLS 구성에서 이러한 주소를 수신하고 있습니까?

또한 docker-compose 로그에서 다음 오류가 표시되기 시작했습니다.

유효한 애플리케이션 ID가 아닌 사용자 이름으로 연결하는 MQTT 클라이언트입니다.

힌트 감사합니다! 가리키며 cert.pem 대신 ca.pem 밝혀진 certificate signed by unknown authority 문제. 그러나 여전히 다른 연결 오류가 발생합니다. 1884 포트에서 확실히 듣고 있습니다.

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

또한 포트 1884에 텔넷을 연결하고 ttn-lw-cli 도구를 실행할 때 데이터 패킷이 들어오는 것을 볼 수 있습니다. 따라서 확실히 패킷 교환이 발생하지만 디버그 로그는 여전히 다음 오류를 표시합니다. "transport: authentication handshake failed: context deadline exceeded". Reconnecting...

마침내 --insecure 플래그를 end-device set 명령에 추가하여 이 문제를 해결했습니다!! TLS에 문제가 있는 것 같지만 어쨌든 지금은 걱정하지 않습니다.
다시 한번 감사합니다!

내가 그 설정 한 후 알려 오싹 --root-keys.app-key.key 뿐만 아니라 --net-id 의은을위한 과정에 참여 end-device 성공적으로 완료 나는 독립에 최종 장치에서 데이터를 받기 시작 애플리케이션 서버! 내가 직면한 모든 문제를 통해 큰 도움을 주셔서 다시 한 번 감사드립니다!

대단해! 여기에 시나리오를 문서화하여 통합할 수 있다면 정말 좋을 것입니다.

동기 부여도 해주시고 첫 팬케이크가 되어주셔서 감사합니다.