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]

ليس من الصعب جدًا نشر الخدمات لكل مكون عندما تكون هذه الخدمات جزءًا من نفس المجموعة والشبكة الفرعية.

أقوم بتحديد نطاق هذه المشكلة في الوقت الحالي للحصول على إرشادات حول كيفية ؛

• قم بتثبيت خادم هوية مستقل
• قم بتثبيت خادم انضمام مستقل
• قم بتثبيت مجموعة توجيه باستخدام Gateway Server و Network Server و Application Server التي تستخدم الخدمات المستقلة

johanstokking شكرًا جزيلاً لك على ردك وإضافة المشكلة إلى التراكم. في غضون ذلك ، أتساءل عما إذا كان بإمكانك مساعدتي في هذا الأمر. لقد بدأت خادم الانضمام بمفرده باستخدام الأمر التالي:
ttn-lw-stack start js --cluster.network-server "ns_ip_address" --cluster.application-server "as_ip_address"

ما لا يمكنني معرفته هو في أي منفذ يتلقى خادم الانضمام طلب الانضمام وهل سيرسل تلقائيًا Join_Ans إلى خادم الشبكة المحدد؟

شكرا لك مرة أخرى!

zamashal في الواقع JS هو الخادم و NS و AS عملاء. لذا قم بتكوين عنوان مجموعة JS في NS و AS. هذا يجعلها تعمل في نفس المجموعة ، على الرغم من أنها مكونات فردية. لاحظ أن هذا يستخدم مصادقة الكتلة ، المصممة للمكونات التي تثق ببعضها البعض في نفس المجموعة. إذا كنت تنشر GS و NS و AS على الحافة و JS في السحابة ، فربما لا يكون هذا هو الحال.

في هذه الحالة ، يجب عليك استخدام interop ، عبر LoRaWAN Backend Interfaces ، وهي مدعومة أيضًا. يسمح هذا لـ NS بالاتصال بـ JS الخاص بك عبر مصادقة عميل TLS.

يأتي ذلك في جزأين: تكوين NS لاستخدام JS الخاص بك وتكوين interop (انظر --help ). هذا لم يتم توثيقه بالكامل حتى الآن للأسف.

شكرا مرة أخرى johanstokking ! لقد كنت أحاول تشغيل هذا الإعداد كما أوضحت. هناك شيء واحد يحيرني. في الرابط الذي قدمته ، يوجد مثال على كيفية إعداد إمكانية التشغيل التفاعلي مع Semtech Join Server . ومع ذلك ، أحاول استخدام TTN Stack's Join Server نفسه ، وليس شيئًا خارجيًا مثل Semtech أو غيره. هل ما زلت بحاجة إلى وضع التكوين لـ configure.yml و example/js.yml ؟ إذا كان الأمر كذلك ، فكيف سيبدو ذلك بعد ذلك؟

لقد قمت بالفعل بتكوين NS الخاص بي للعمل مع JS خارجي (المعروف أيضًا باسم TTN Stack's JS) ، ولكن باستخدام المنفذ 8886 (Interop / tls) لخادم الانضمام لإرسال Join_Req ، يتم رفض الاتصال على الرغم من يبدو أن 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. يمكنك استخدام نفس عنوان IP العام الخاص بـ gRPC واستخدام منفذ توافق داخلي مخصص (افتراضي 8886).

أنت بحاجة إلى مرجع مصدق خاص يصدر شهادات العميل. يتم استخدامها على الحافة بواسطة NS. يمكنك تكوين المراجع المصدقة للعميل الموثوق به في الانضمام إلى الخادم ، وهذا حسب NetID. يمكنك دائمًا استخدام NetIDs 000000 و 000001 في شبكتك الخاصة ، أو الانضمام إلى تحالف LoRa وستحصل على واحد بنفسك.

عيّن 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's CA لـ TTN NetID كما في المثال ، فقط لتوضيح كيفية عمل ذلك.

تكوين توافق خادم الشبكة

هذا موثق ، لكن ما تحتاجه بالفعل هو تهيئة 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 لخادم الانضمام الخاص بك و 8886 منفذ ذلك listen-tls الذي قمت بتكوينه في JS interop.

أيضًا ، root-ca (على عكس ما يقوله المثال) هو المرجع المصدق الجذر لشهادة الخادم_. قد يكون هذا هو نفس المرجع المصدق. يمكنك أيضًا تركها إذا كنت تستخدم شهادة خادم تجارية (أو Let's Encrypt) موثوقة بالفعل من قبل NS.

قم بتمكين سجلات تصحيح الأخطاء على كلا الجانبين ( log.level=debug ) وسترى الأشياء تعمل أو تتبعات لماذا لا تعمل الأشياء. حظا طيبا وفقك الله!

أيضًا ، إذا قمت بهذا العمل ، فلا تتردد في تقديم طلب سحب لتوثيق ذلك. ربما تحتاج إلى دليل ، لكن الصفحة المرجعية تحتاج أيضًا إلى بعض الحب.

johanstokking ، سأعمل على هذا وآمل أن أتأكد من تقديم طلب سحب لتحديث الدليل بمجرد أن أحصل عليه. لا أستطيع أن أشكرك بما فيه الكفاية على كل ما تبذلونه من المساعدة!

مرحبًا johanstokking - أتمنى أن يكون كل شيء على ما يرام معك. أود أن أطلعكم على تقدمي. لسوء الحظ ، لقد كنت أعالج الكثير من الأخطاء لإنجاح هذا الأمر وسأشارك معك هنا آخر الأخطاء التي أواجهها. بعد إعداد التشغيل المتداخل وتكوين خادم الشبكة لإرسال طلبات الانضمام إلى خادم الانضمام على المنفذ الافتراضي 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"

إذا قمت بتكوين خادم الشبكة الخاص بي لإرسال طلبات الانضمام إلى المنفذ 1884 لخادم gRPC ، فسأحصل بدلاً من ذلك على الخطأ التالي في سجل خادم الشبكة:
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

آمل أن تتمكن أنت أو أي شخص آخر من مساعدتي في فهم كيفية حل هذه الأخطاء ومعرفة ما قد يسبب مثل هذه الأخطاء.

شكرا مرة أخرى على دعمكم المتواصل!

الانضمام إلى الخادم متاح فقط عبر https.

يبدو أيضًا أن NS لا يمكنها حل js-server_ip عبر DNS.

شكرا @ johanstokking! لذا ، نعم ، اتضح أنني لم أقم بتعيين المنفذ 8886 إلى مضيفي في docker-compose.yml. الآن المشكلة التي أواجهها هي خطأ مصافحة TLS:

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

لسبب واحد ، لقد استخدمت العلامة --tls.insecure-skip-verify لكنها ما زالت تصر على التحقق من الشهادة وأعطتني الخطأ نفسه. أعتقد أن المشكلة هي أنني بحاجة إلى الوثوق بالمرجع المصدق في حاوية عامل الإرساء. فتحت قذيفة في المكدس وأعطاني خطأ Permission denied عندما أحاول نسخ الشهادات إلى /usr/local/share/ca-certificates/ أجل الوثوق بها من قبل الجهاز.

أعتقد أن العلم --tls.insecure-skip-verify يجب أن يسمح بذلك ، لكن ربما يكون تطبيقك مختلفًا. مشكلتي الآن هي أن حاوية عامل الإرساء لا تمنحني خيارًا للثقة في شهادتي الموقعة ذاتيًا. هل هناك شيء أفتقده هناك؟

هل شهادة العميل موقعة من أحد المراجع المصدقة لـ 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'

لم يتم توثيق المراجع المصدقة لعميل المرسل بعد ، وسنفعل ذلك كجزء من إغلاق هذه المشكلة أو استبدالها. انظر (هنا) [ 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 في هذا المجلد. هذا دليل مختلف عن ملف التكوين المتداخل.

شكرا @ 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)"

مما يمكنني قراءته ، يبدو أن الخطأ يشكو من خطأ في تكوين مكون 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 في الواقع.

يبدو أن جهازك غير مسجل في الانضمام إلى الخادم؟

أوه ربما هذا هو السبب. حسنًا ، كل ما فعلته هو استخدام العلم --js.join-eui-prefix لكن يبدو أن هذا ليس كافيًا. أنا عالق في قضية أخرى كنت أحاول تجاهلها: إصدار 1942

هل يمكنني تسجيل الجهاز عن طريق إضافة صفوف يدويًا إلى قاعدة بيانات redis؟ إذا كان الأمر كذلك ، فما هو الشكل؟ قد يساعدني ذلك في الاستمرار في تجاهل المشكلة الأخرى في هذه الأثناء ..

تمكنت من الوصول إلى لوحة القيادة في المشكلة الأخرى وتسجيل الجهاز على لوحة القيادة. أرى الآن خطأ يقول sender unknown والذي أعتقد أنه يشكو من عدم التعرف على البوابة. حاولت إضافة البوابة من وحدة التحكم لكنها لا تزال تقول Disconnected . حاولت إدخال عنوان gateway_ip و server_ip ولكن لا يبدو أن كلاهما يحدث أي فرق بعد.

من المحتمل أن يعني المرسل غير معروف أن NetID للجهاز النهائي لم يتم تعيينه على NetID الخاص بخادم الشبكة. يجب تعيين كلاهما على 000000 .

يمكنك تعيين NetID للجهاز النهائي عبر CLI باستخدام ttn-lw-cli end-device set <app-id> <dev-id> --net-id=000000

يتصرف 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 يعمل بشكل جيد دون مشاكل في الشهادة أو أي أخطاء أخرى. هل لديك أي فكرة عما قد أفتقده والذي من المحتمل أن يتسبب في رفض الأذونات؟
شكرا!

هل يمكنك نشر تهيئة الخادم و 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

أنا أستخدم نفس ca.pem الذي يثق به ttn-stack الذي أديره مع عامل إنشاء السفن.

لقد تجاوزت مشكلة تسجيل الدخول / الشهادة مرة أخرى باستخدام منافذ http URI و http في ttn-lw-cli config. عندما أقوم بتشغيل 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"

أعتقد أن هذا قد يكون مرتبطًا بإعداد http الخاص بي ، على الرغم من أنني تلقيت رسالة INFO Got OAuth access token بعد تسجيل الدخول والتي يبدو أنها تشير إلى مصادقة ناجحة.

بدأت أيضًا في رؤية الخطأ التالي من سجلاتي 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 . يجب أن يشير هذا الملف إما إلى شهادة الخادم (إذا كانت موقعة ذاتيًا) أو إلى المرجع المصدق الذي وقع على شهادة الخادم.

هنا هو التهيئة الخاصة بي ttn-lw-cli :

يبدو هذا التكوين جيدًا إذا كنت لا تريد استخدام TLS. ولكن ، هل يستمع الخادم إلى هذه العناوين ، في تكوينه بخلاف TLS؟

بدأت أيضًا في رؤية الخطأ التالي من سجلاتي docker-compose :

هذا عميل 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

يمكنني أيضًا رؤية حزم البيانات القادمة من خلال الاتصال عبر telnet إلى المنفذ 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 بنجاح وبدأت في الحصول على البيانات من الجهاز النهائي على الجهاز المستقل خادم التطبيق! شكرًا لك مرة أخرى على مساعدتك الرائعة في جميع المشكلات التي واجهتها!

هذا جيد! سيكون من الرائع أن تتمكن من توثيق السيناريو الخاص بك هنا ، حتى نتمكن من دمجه.

شكرًا لك أيضًا على الدافع وكونك أول فطيرة.