Lorawan-stack: تم رفض الروابط الهابطة بواسطة بوابات لبعض صلاحيات الإرسال

تم إنشاؤها على ٩ مارس ٢٠٢٠  ·  18تعليقات  ·  مصدر: TheThingsNetwork/lorawan-stack

ملخص

نتلقى تقارير من المجتمع تفيد بأن بعض البوابات ترفض الوصلات الهابطة بسبب قيم TX Power غير المدعومة.

https://thethingsnetwork.slack.com/archives/C1D8GQMU5/p1582630203014800
https://thethingsnetwork.slack.com/archives/C1Q5XLNDT/p1582206674209100
https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833
https://www.thethingsnetwork.org/forum/t/packet-forwarder-who-sets-powe-in-json-downstream-txpk-packet/34481

خطوات التكاثر

  1. إرسال الوصلة الهابطة عبر البوابة
  2. تحقق من سجلات البوابة

ماذا ترى الآن؟

  • خطأ: حزمة مرفوضة ، طاقة RF غير مدعومة لـ TX - 11
  • خطأ: حزمة مرفوضة ، طاقة RF غير مدعومة لـ TX - 17
  • خطأ: حزمة مرفوضة ، طاقة RF غير مدعومة لـ TX - 24

ماذا تريد ان ترى بدلا من ذلك؟

انتقال ناجح

bug gateway server in progress

التعليق الأكثر فائدة

لقد نشرنا للتو تصحيحًا يجب أن يعكس السلوك. سأنتظر بعض الملاحظات قبل إغلاق هذا.

ال 18 كومينتر

يبدو أن الخطأ يحدث مع Lora-net/packet_forwarder . الكود ذو الصلة: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L2517 -L2527

من خلال تكوينات البوابة التي تم توزيعها عبر TTN (https://github.com/TheThingsNetwork/gateway-conf/) ، يتم قبول صلاحيات الإرسال التالية بواسطة البوابات:

-6 ، -3 ، 0 ، 3 ، 6 ، 10 ، 11 ، 12 ، 13 ، 14 ، 16 ، 20 ، 23 ، 25 ، 26 ، 27

في The Things Stack ، نستخدم نفس القائمة عندما نبني التكوين الديناميكي للبوابات: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/pfconfig/shared/shared.go#L259 -L276

هذا يعني أن _ERROR: Packet REJECTED ، وطاقة RF غير المدعومة لـ TX - 11_ هي مجرد تكوين خاطئ للبوابة ، لكن التقارير الأخرى صالحة.

أظن أن سبب ذلك هو إرسال خادم بوابة v3 قيمة طاقة TX غير مدعومة. نحتاج إلى التأكد من أن GS يرسل فقط قيم طاقة TX إلى بوابات UDP إذا كانت مدرجة في قائمة قوى TX المدعومة.

أي تحديثات أو رؤى حديثة حول هذا؟

هل يمكنك إضافة تقرير إلى https://status.thethings.network/ ؟ شكرا!

https://status.thethings.network/ مخصص لحوادث الشبكة. هذا ليس المكان المناسب لذلك. سنصدر تحديثًا جديدًا حيث سيتحقق الخادم من طاقة الإرسال المدعومة قبل الإرسال.

مرحبا كيرشنا ،

هل يمكنك أن تكون أكثر دقة عند إصدار هذا التحديث؟ هناك الكثير من الناس ينتظرون هذا الإصلاح.

بالمناسبة ، ماذا تقصد بـ "سوف نتحقق من قوة TX المدعومة قبل الإرسال"؟ هل سيتأكد الخادم من أن طاقة الإرسال "قياسية" أم أنها ستسقط الحزمة؟

شكرا لمساعدتك

https://status.thethings.network/ مخصص لحوادث الشبكة.

فقط للتعبير عن شعوري بأن هذا صارم للغاية. هذه _هي مشكلة تشغيلية للبعض ، أليس كذلك؟ على الأقل بالنسبة لبعض المستخدمين ، تنخفض الأجهزة إلى SF12 بسبب عدم تلقي وصلات ADR الهابطة ، ويرى آخرون فجأة فشل OTAA. بدون الوصول إلى سجل البوابة ، فهم لا يعرفون السبب ، والأكثر من ذلك أن الأمور كانت تسير على ما يرام حتى وقت قريب ، تم تغيير شيء ما لتوجيه حركة مرور V2. (أو شيء من هذا القبيل ؛ لا يوجد اتصال واضح حول هذه التغييرات أيضًا).

avbentem : لن يتم تصنيف هذا على أنه مشكلة تشغيلية نظرًا لأنه يتعلق بسلوك البرنامج وليس الاتصال / الإنتاجية / التوفر وما إلى ذلك. ومع ذلك فأنا أفهم أن هذا أمر مهم ليتم إصلاحه. يمكنك توقع الإصلاح في الأيام القادمة.
ملاحظة: أنت محق تمامًا. لم يتم إبلاغ هذا التغيير بشكل صحيح.

لم يتم إبلاغ هذا التغيير بشكل صحيح.

جانبا: لم يفت الأوان على الأقل لإصلاح ذلك؟ ليس من الواضح تمامًا ما الذي تغير ومتى وما إذا كان يجب على الأشخاص النظر إلى V2 أو V3 عند تصحيح الأخطاء ، KrishnaIyer وhtdvisser.

أرحب بشدة ، على سبيل المثال ، بأي مشاركة في المنتدى أو أي شيء على https://www.thethingsnetwork.org/updates حول هذا التغيير والتغييرات المستقبلية. شكرا!

لقد نشرنا للتو تصحيحًا يجب أن يعكس السلوك. سأنتظر بعض الملاحظات قبل إغلاق هذا.

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

كان التغيير في الأساس كما يلي:

تأكد من أن GS يرسل فقط قيم طاقة الإرسال إلى بوابات UDP إذا كانت مدرجة في قائمة قوى الإرسال المدعومة

https://github.com/TheThingsNetwork/lorawan-stack/issues/2106#issuecomment -596502171


بالإضافة إلى هذا التغيير ، اكتشفنا أن تحويل طاقة الإرسال في الوصلات الهابطة المتلقاة من أنظمة v2 لم يتم بشكل صحيح ، مما أدى إلى اختلاف 3 ديسيبل ميلي واط (11 كان يجب أن يكون 14 ؛ كان يجب أن يكون 17 هو 20 وكان يجب أن يكون 24 27). تم إصلاح هذا أيضًا.

شكرًا على التفاصيل ، "كان يجب أن يكون _24 27_" هو بالضبط سبب مشاكلنا. بمعرفة هذه التفاصيل ، لا نحتاج إلى تصحيح أخطاء GW في الموقع أكثر من ذلك.

لم أتمكن من إعادة إظهار المشكلة بعد الآن من جانبي. شكرا للتحديث!

شكرًا ، htdvisser وKrishnaIyer. نظرًا لأن هذا مرتبط بطريقة ما بتوصيل V2 و V3: هل يمكنك من فضلك توثيق في مكان ما كيف يتم توصيل الأشياء في الوقت الحاضر ، لشبكة المجتمع؟

على ما يبدو ، كما تم الإعلان بإيجاز خلال مؤتمر أواخر يناير 2020 ، فإن حركة مرور البوابات التي تم إنشاؤها في V2 يتم توجيهها عبر V3؟ ربما فاتني شيء ما ، ولكن من غير الواضح حقًا بالنسبة لي ما هي مكونات V2 التي لا تزال مستخدمة ، وما الذي يتم تفويضه الآن إلى V3. أيضًا ، من غير الواضح متى تم إجراء التغييرات.

(مثل: لا تزال شبكة المجتمع تستخدم V2 TTN Console ، وهذا يعمل بشكل جيد. أفترض أيضًا أن ADR لا يزال يتم التعامل معه بواسطة V2 ، حيث لا يزال يتم الإبلاغ عن https://github.com/TheThingsNetwork/ttn/issues/767 أجهزة OTAA التي انضمت قبل أكتوبر 2019. ولكن نظرًا لأن المشكلة المذكورة أعلاه قد تم إصلاحها في V3 ، فقد تم إجراء شيء ما بواسطة V3 أيضًا؟ معرفة متى تتغير الأشياء قد يساعد في تصحيح الأخطاء في المستقبل.)

تضمين التغريدة

لا نحتاج إلى تصحيح أخطاء GW في الموقع أكثر من ذلك

لاحظ أنه قد يكون من الجيد إصلاح جانب البوابة أيضًا ، أو تنفيذ آلية احتياطية للتغييرات المستقبلية أو للاستخدام المستقبلي لـ V3؟ لست متأكدا . انظر بعض التعليقات من Slack في https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14

لا أستطيع أن أرى كيف أدى ذلك إلى حل المشكلة عندما يكون لدى شخص ما (على سبيل المثال) هوائي 5dBi على بوابتهم. إذا تركوا Antenna Gain في ملف التكوين كـ 0dBi ، فسوف يتجاوزون الحد الأقصى لطاقة الإرسال القانونية وإذا قاموا بتغيير ملف التكوين إلى 5dBi ، فستكون هناك حالات يتم فيها رفض الحزمة بواسطة البوابة.

الرد على avbentem :

نظرًا لأن مجموعات شبكات المجتمع لدينا تبدو مختلفة ، والأشياء تتغير طوال الوقت ، فسوف يكلفنا الكثير من الوقت للحفاظ على نظرة عامة محدثة حول كيفية اتصال الأشياء في كل منطقة.

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

Screenshot 2020-04-03 at 10 40 38

كما ذكر johanstokking خلال عرضه التقديمي في المؤتمر ، فإن العديد من بوابات شبكة المجتمع تتصل بالفعل من خلال خادم بوابة v3 ، ونحن نقوم ببطء بتوصيل المزيد من البوابات من خلال خوادم بوابة v3 بمرور الوقت.

بصرف النظر عن خوادم البوابة هذه ، لا تزال شبكة المجتمع العام بأكملها تدير مكونات v2.

الرد على tonysmith55 :

هذا لم يحدث. إنه يغير السلوك مرة أخرى إلى ما كان عليه من قبل. نعم ، من الممكن (وسيظل دائمًا) أن تتجاوز البوابات الحد الأقصى لطاقة الإرسال القانونية إذا لم يتم تكوين هذه البوابات بشكل صحيح من قبل أصحابها.

آمل أن يكون هذا يجيب عن أسئلتك. نظرًا لأننا نبتعد قليلاً عن الموضوع هنا ، وبما أنه تم تأكيد حل هذه المشكلة الآن ، فسوف أغلق المشكلة الآن.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات