Lorawan-stack: Von Gateways für bestimmte TX-Leistungen abgelehnte Downlinks

Bei Lora-net/packet_forwarder scheint ein Fehler aufzutreten. Relevanter Code: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L2517 -L2527

Mit den über TTN (https://github.com/TheThingsNetwork/gateway-conf/) verteilten Gateway-Konfigurationen werden die folgenden TX-Befugnisse von Gateways akzeptiert:

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

In The Things Stack verwenden wir dieselbe Liste, wenn wir die dynamische Konfiguration für Gateways erstellen: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/pfconfig/shared/shared.go#L259 -L276

Dies bedeutet, dass die nicht unterstützte HF-Leistung _ERROR: Packet REJECTED für TX - 11_ nur eine Fehlkonfiguration des Gateways ist, die anderen Berichte jedoch gültig sind.

Ich vermute, dass diese durch einen v3-Gateway-Server verursacht werden, der einen nicht unterstützten TX-Leistungswert sendet. Wir müssen sicherstellen, dass der GS nur dann TX-Leistungswerte an UDP-Gateways sendet, wenn diese in der Liste der unterstützten TX-Leistungen enthalten sind.

Gibt es aktuelle Updates oder Erkenntnisse dazu?

Können Sie bitte einen Bericht zu https://status.thethings.network/ hinzufügen? Vielen Dank!

https://status.thethings.network/ ist für Netzwerkvorfälle gedacht. Das ist nicht der richtige Ort dafür. Wir werden ein neues Update veröffentlichen, bei dem der Server vor dem Senden nach unterstützter Sendeleistung sucht.

Hallo Kirshna,

Können Sie etwas genauer sagen, wann dieses Update veröffentlicht wird? Es warten viele Leute auf dieses Update.

Übrigens, was meinst du mit "wird vor dem Senden nach unterstützter Sendeleistung suchen"? Stellt der Server sicher, dass die Sendeleistung "Standard" ist, oder verwirft er das Paket?

Danke für Ihre Hilfe

https://status.thethings.network/ ist für Netzwerkvorfälle gedacht.

Nur um auszudrücken, dass ich das für sehr starr halte. Dies ist für einige ein Betriebsproblem, oder? Zumindest für einige Benutzer fallen Geräte auf SF12 ab, weil sie keine ADR-Downlinks empfangen, und andere sehen plötzlich, dass OTAA fehlschlägt. Ohne Zugriff auf ein Gateway-Protokoll wissen sie nichts über die Ursache, zumal die Dinge bis vor kurzem einwandfrei funktionierten und etwas für das Routing des V2-Verkehrs geändert wurde. (Oder so ähnlich; es gibt auch keine klare Mitteilung über diese Änderungen.)

@avbentem : Dies würde nicht als betriebliches Problem eingestuft, da es sich auf das Softwareverhalten und nicht auf Konnektivität / Durchsatz / Verfügbarkeit usw. bezieht. Ich verstehe jedoch, dass dies wichtig ist, um behoben zu werden. Sie können in den kommenden Tagen mit einer Lösung rechnen.
PS: Du hast vollkommen recht. Diese Änderung wurde nicht richtig kommuniziert.

Diese Änderung wurde nicht richtig kommuniziert.

Nebenbei: Es ist nie zu spät, um das zumindest zu beheben? Mir ist völlig unklar, was sich wann geändert hat und ob die Leute beim Debuggen von Problemen auf V2 oder V3 schauen sollten, @KrishnaIyer und @htdvisser.

Ich begrüße beispielsweise einen Forumsbeitrag oder etwas auf https://www.thethingsnetwork.org/updates über diese Änderung und zukünftige Änderungen. Vielen Dank!

Wir haben gerade einen Patch bereitgestellt, der das Verhalten rückgängig machen soll. Ich werde auf ein Feedback warten, bevor ich es schließe.

Danke Krishna!
Können Sie uns einige Details geben, was behoben wurde? Niemandem die Schuld zu geben, nur weil dies uns helfen würde, die Probleme mit unseren Gateways und Paketweiterleitern besser zu verstehen und sicherzustellen, dass das beobachtete Verhalten durch diese Änderung verursacht wurde.

Die Änderung war im Grunde folgende:

Stellen Sie sicher, dass der GS nur dann Sendeleistungswerte an UDP-Gateways sendet, wenn diese in der Liste der unterstützten Sendeleistungen aufgeführt sind

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

Zusätzlich zu dieser Änderung stellten wir fest, dass die Umwandlung der Sendeleistung in Downlinks, die von v2-Systemen empfangen wurden, nicht korrekt durchgeführt wurde, was zu einer Differenz von 3 dBm führte (11 hätte 14 sein müssen, 17 hätte 20 sein sollen und 24 hätte sein sollen 27). Dies wurde ebenfalls behoben.

Vielen Dank für die Details, "_24 hätte 27_ sein sollen" ist genau das, was unsere Probleme verursacht hat. Wenn wir dieses Detail kennen, müssen wir das GW vor Ort nicht weiter debuggen.

Ich konnte das Problem auf meiner Seite nicht mehr reproduzieren. Danke für das Update!

Danke, @htdvisser und @KrishnaIyer. Da dies irgendwie mit der Verbindung von V2 und V3 zusammenhängt: Können Sie bitte irgendwo dokumentieren, wie die Dinge heutzutage für das Community-Netzwerk verbunden sind?

Anscheinend wird, wie auf der Konferenz Ende Januar 2020 kurz angekündigt, der Verkehr von Gateways, die in V2 eingerichtet wurden, über V3 geleitet? Vielleicht habe ich etwas verpasst, aber mir ist wirklich sehr, sehr unklar, welche Komponenten von V2 noch verwendet werden und was jetzt an V3 delegiert wird. Es ist auch unklar, wann die Änderungen vorgenommen wurden.

(Wie: Das Community-Netzwerk verwendet immer noch die V2 TTN-Konsole, und das funktioniert einwandfrei. Ich gehe auch davon aus, dass ADR immer noch von V2 verarbeitet wird, da https://github.com/TheThingsNetwork/ttn/issues/767 immer noch gemeldet wird OTAA-Geräte, die vor Oktober 2019 beigetreten sind. Da das oben genannte Problem jedoch in V3 behoben wurde, wird auch in V3 etwas unternommen. Wenn Sie wissen, wann sich Änderungen ergeben, kann dies beim zukünftigen Debuggen hilfreich sein.)

@dermatthias

Wir müssen das GW vor Ort nicht weiter debuggen

Beachten Sie, dass es möglicherweise immer noch eine gute Idee ist, auch die Seite des Gateways zu reparieren, um einen Fallback-Mechanismus für zukünftige Änderungen oder für die zukünftige Verwendung von V3 zu implementieren. Ich bin nicht sicher ; Einige Kommentare von Slack finden Sie unter https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14

Ich kann nicht sehen, wie dies das Problem behoben hat, wenn jemand (zum Beispiel) eine 5-dBi-Antenne auf seinem Gateway hat. Wenn sie die Antennenverstärkung in der Konfigurationsdatei als 0 dBi belassen, überschreiten sie die maximale zulässige Sendeleistung. Wenn sie die Konfigurationsdatei auf 5 dBi ändern, wird das Paket in bestimmten Fällen vom Gateway abgelehnt.

Antwort an @avbentem :

Da unsere Community-Netzwerkcluster alle unterschiedlich aussehen und sich die Dinge ständig ändern, würde es uns zu viel Zeit kosten, einen aktuellen Überblick darüber zu erhalten, wie die Dinge in den einzelnen Regionen miteinander verbunden sind.

In der Abbildung unten sehen Sie, wie Gateways eine Verbindung zu einem v2-Netzwerk herstellen können. Die alte Situation (gelb) wird langsam in die neue Situation (grün) migriert. Dazu leiten wir zunächst einen kleinen Prozentsatz des Datenverkehrs für ein bestimmtes Gateway-Protokoll durch die neuen Komponenten und erhöhen diesen Prozentsatz langsam. Gleiches gilt für die anderen Gateway-Protokolle.

Wie @johanstokking während seiner Präsentation auf der Konferenz erwähnte, stellen viele Community-Netzwerk-Gateways bereits eine Verbindung über einen v3-Gateway-Server her, und im Laufe der Zeit verbinden wir langsam mehr Gateways über v3-Gateway-Server.

Abgesehen von diesen Gateway-Servern werden im gesamten öffentlichen Community-Netzwerk weiterhin v2-Komponenten ausgeführt.

Antwort auf @ tonysmith55 :

Das hat nicht. Es ändert nur das Verhalten zurück zu dem, was es vorher war. Ja, es ist (und wird immer möglich), dass Gateways die maximale zulässige Sendeleistung überschreiten, wenn diese Gatways von ihren Eigentümern nicht korrekt konfiguriert wurden.

Ich hoffe das beantwortet deine Fragen. Da wir hier etwas vom Thema abweichen und bestätigt wurde, dass dieses Problem behoben ist, werde ich das Problem jetzt schließen.