Lorawan-stack: Grundlegende Stationsintegration: Die Race-Bedingung bei der erneuten Verbindungsbehandlung führt zu einem dauerhaften Ausfall der Uplink-Weiterleitung

Mit dem letzten Update wurde das Timeout anscheinend von 60 s auf 600 s geändert. Das zugrunde liegende Problem bleibt jedoch bestehen und kann mit den obigen Schritten zuverlässig reproduziert werden.

Ich werde versuchen, dies zu simulieren und die Proxy-Einstellungen zu optimieren, um festzustellen, wo das Problem liegt. Es muss jedoch beachtet werden, dass dies nur einen Prozentsatz der Gateways zu beeinflussen scheint.
In der folgenden Grafik entspricht die ansteigende Flanke der Spitze in Statusmeldungen dem 600s-Leerlauffenster. Jedes Mal, wenn das Gateway erneut eine Verbindung herstellt, protokollieren wir eine einzelne Statusmeldung (die diese Spitze berücksichtigt). Wenn Sie jedoch den Verkehr sehen, ist der Rückgang gering, aber nicht drastisch genug, um auf ein Problem mit allen Gateways hinzuweisen:

Hallo Krishna, das Problem hängt nicht mit serverseitigen Verbindungsabbrüchen zusammen, sondern mit der Art und Weise, wie der Server unreine clientseitige Verbindungsabbrüche mit sofortigen erneuten Verbindungen behandelt. Das Problem betrifft alle auf Basisstationen basierenden Gateways und kann mit den obigen Anweisungen zuverlässig reproduziert werden.

Das Fehlermuster ist wie folgt:

• Das Gerät beendet die Verbindung unsauber (Aus- und Wiedereinschalten, Hard-Reset, WiFi-Drop, TTIG-Stecker / Plugin usw.)
• Das Gerät stellt sofort wieder eine Verbindung her
• Für 600s nach dem Trennen (diese Nummer war früher 60s) werden die weitergeleiteten Pakete im LNS angezeigt
• Nach 600 s und darüber hinaus nach dem Trennen werden die weitergeleiteten Pakete NICHT im LNS angezeigt

Durch Erhöhen des Zeitlimits von 60 auf 600 Sekunden wurde das Problem schwerwiegender: Bei 60s musste der Benutzer, der sein TTIG aussteckt, nur 60 Sekunden warten, bevor er es wieder einsteckte, um nicht auf das Problem zu stoßen. Dies kann häufig genug geschehen sein, insbesondere wenn ein Werksreset durchgeführt wird. Jetzt mit 600s wird ein größerer Prozentsatz auf das Problem stoßen, was auch beobachtet werden kann.

Würde es weh tun, diese Zeitüberschreitung vollständig zu deaktivieren? Die Basisstation hält TCP standardmäßig am Leben (https://github.com/lorabasics/basicstation/blob/c29b8502f8c715daecec6666835da6e981dc820a/src/sys.c#L637). Reicht das nicht aus, um die Lebendigkeit der Verbindung zu überprüfen?

Für mich sieht es auch nach dem Fehler habbens aus, wenn der Provider Ihre Internetverbindung abbricht und Sie beim erneuten Verbinden eine neue IP erhalten :(
Momentan funktioniert mein TTIG-Gateway jeden Tag nicht mehr. Wenn ich in den Protokollen meiner App zeige, ist der letzte Wert, den ich erhalten habe, kurz, bevor die Verbindung getrennt und dann wieder verbunden wurde.
Um das Gateway wieder zum Laufen zu bringen, muss ich es ausstecken, etwas warten und dann wieder einstecken.

Dieses Verhalten tritt jedoch erst seit dem 29.01 auf, bevor dies nie ein Problem war.

@JackGruber Können Sie bestätigen, dass Sie in den ersten 600 Sekunden nach dem Trennen der Internetverbindung auch Uplinks erhalten können? (Um genau zu sein: 600 Sekunden abzüglich der Zeit, die das Modem und das Gateway benötigen, um wieder vollständig verbunden zu sein.)

Oder wenn Sie in diesen 600 Sekunden keine Uplinks sehen: Wie oft senden Ihre Geräte? (Mit anderen Worten: Würden Sie in diesen 600 Sekunden einige Uplinks erwarten?)

Das Gerät, das ich überwache, sendet alle 5 Minuten.

02:42 RX-Rahmen
02:47 RX Frame
02:53 RX Frame
02.56 Reconnect
02:58 RX Frame
keine Frames
07:30 TTIG ausstecken / wieder einstecken
07:36 RX Frame

Wenn man 600 Sekunden nach der 2:56-Wiederverbindung berücksichtigt, kann man nach dem 2:58-Uplink auch einen 3:03-Uplink erwarten (der immer noch vor 2:56 plus 600 Sekunden = 3:06 liegt). Aber vielleicht wird das 600-Sekunden-Timeout nach dem 2:53-Uplink zurückgesetzt (anstatt nach einer späteren Keep-Alive- / Statusmeldung), wodurch TTN fälschlicherweise den Kontext / Status löscht, wenn der 3:03-Uplink empfangen werden soll. (Und natürlich werden Uplinks möglicherweise auch aus anderen Gründen nicht empfangen.)

Außerdem scheint alles in Ordnung zu sein, wenn der TTIG um 7:30 neu gestartet wird und 600 Sekunden später keine Probleme mehr auftreten. Dies scheint die ( großartige ) Analyse von @beitler zu bestätigen, die davon ausgeht, dass TTN fälschlicherweise einen gemeinsamen Kontext / Status bei

Heute habe ich mir die Zeiten genauer angesehen
Ich habe auch eine Protokolldatei von der TTIG angehängt.
Leider nicht ab dem Zeitpunkt der ISP-Wiederverbindung.
Wenn gewünscht, erstelle ich ein Langzeitprotokoll, so dass auch die Wiederverbindung enthalten ist
TTIG.log

Zeitplan (UTC + 1)
02:46 RX-Nachrichten
02:51 RX-Nachrichten
02:56 RX-Nachrichten
02:58 RX-Nachrichten
02:58 ISP stellt die Verbindung wieder her
03:01 RX-Nachrichten
03:03 RX-Nachrichten
03:06 RX-Nachrichten
Es wurden keine Nachrichten mehr empfangen

TTN-Konsole
Status: nicht verbunden
Zuletzt gesehen: 2/11/2020 03:05:04

06:46 Short Un- / Replug TTIG (10 Sekunden lang kein Strom)

TTN-Konsole
Status: verbunden
Zuletzt gesehen: 2/11/2020 06:47:12

06:48 Empfangsnachrichten
....

Ich habe einen Fehler in meiner Firewall-Regel gefunden und die primäre CUPS-Verbindung (rjs.sm.tc) war nicht zulässig, nur die CUPS-Sicherung (mh.sm.tc).

Vielen Dank für Ihre Meldung. Wir haben das Problem identifiziert und beheben es. Dieses Problem befindet sich in unserer proprietären Codebasis, wird jedoch hier geschlossen.

Hat sich seit +/- 18 Uhr heute Nachmittag etwas im Backend geändert?
Es ist jetzt so gut wie unmöglich, das TTN Indoor Gateway länger als 10 Minuten zu betreiben, während es meines Wissens seit Monaten einwandfrei funktioniert hat.
Durch Ändern der IP-Adresse über den DHCP-Server wird zwar eine 10-minütige Verbindung zum TTN-Netzwerk hergestellt, diese geht jedoch wieder verloren. (Replug funktioniert auch für 10 Minuten)

@ TD-er, hast du es länger als 10 Minuten (600 Sekunden) vom Stromnetz getrennt gelassen?

Wie oben erläutert, ist dies seit der Änderung am 6. Februar erforderlich. Vor dem 7. Februar musste man es 60 Sekunden lang vom Stromnetz trennen. Es ist mir unklar, ob der heutige zusammengeführte Fix auch bereitgestellt wurde.

Nein, nicht so lange ausgesteckt.
Wenn der Netzstecker gezogen wurde, wurde er nur einige Sekunden lang vom Stromnetz getrennt.
Mit der DHCP-Änderung der IP-Adresse wurde das Gerät sogar nie aus- und wieder eingeschaltet. Es erhielt lediglich eine neue IP vom DHCP-Server und stellte so seine Netzwerkverbindung wieder her. Dadurch funktionierte es fast genau 10 Minuten lang, bis es wieder nicht verfügbar war.

Ich werde es jetzt für eine Weile ausstecken und dann sehen, was passiert, nachdem ich es wieder eingesteckt habe.

Hatte es für ungefähr 25 Minuten ausgeschaltet und jetzt für ungefähr 15 Minuten angeschlossen und es funktioniert immer noch :) Mal sehen, ob es morgen früh noch läuft.

Wir veröffentlichen heute Version 3.5.3 mit dem Fix und können diesen wahrscheinlich auf den Servern bereitstellen, auf denen TTIG eine Verbindung herstellt. Hoffentlich wird das sehr bald gelöst.

Hoffen wir, dass es noch nicht bereitgestellt wurde, da mein Indoor-Gateway jetzt bereits seit ca. 3 Stunden wieder offline ist.

Wir haben dieses Problem nach der Bereitstellung der neuesten Fixes nicht gehört. Bitte öffnen Sie es erneut, wenn Sie es erneut beobachten.