Der 10 Jahre alte Steam-Fehler „No user logon“

• Der alte No user logon-Disconnect aus Counter-Strike lässt sich auch in CS2 reproduzieren; wenn man direkt nach dem Spielstart zu schnell einem Server beitritt, startet die Steam-ID-Verifizierung möglicherweise nicht
• Der Kern des Problems ist, dass die levelload-Schleife beim Start von CS2.exe vor Abschluss der Steam3-Verifizierung vorzeitig beendet wird und der Server die Verbindung dann mit einer nicht verifizierten Steam-ID verarbeitet
• In Esportal-Logs wurde bei normalen Nutzern STEAM USERID validated erst etwa 1 Minute 20 Sekunden nach dem Verbinden protokolliert; bei fehlgeschlagenen Nutzern kam es nach 2 bis 3 Minuten zu STEAMAUTH failure code 8 und einem Disconnect mit NETWORK_DISCONNECT_STEAM_LOGON
• Eine Neuinstallation des Spiels, Dateiprüfung, Neustart von Steam, Neustart des PCs oder das Deaktivieren von WLAN beheben die eigentliche Ursache nicht; man sollte zuerst CS2 starten und dann im Hauptmenü 5 bis 10 Sekunden warten
• Esportal hat am 10. Januar 2024 das Verhalten korrigiert, bei dem steam://connect/<IP>:<Port> ausgeführt wurde, bevor CS2.exe vollständig initialisiert war; danach fiel der Anteil entsprechender Tickets auf 0 %

---

Das lange wiederkehrende No user logon-Phänomen

• Der No user logon-Disconnect in Counter-Strike ist als Problem bekannt, das während des Spiels zufällig auftritt, und wurde von 2008 bis 2023 wiederholt in verschiedenen Foren und im offiziellen Valve-Supportforum gemeldet
• No user logon und das in manchen Beiträgen auftauchende No steam logon könnten technisch unterschiedliche Bezeichnungen für dieselbe Grundursache sein
• Im Internet weit verbreitete Lösungen beheben die eigentliche Ursache nicht
  • Spiel neu installieren
  • Spieldateien prüfen
  • Steam neu starten
  • Computer neu starten
  • WLAN deaktivieren
• CS2 ersetzte am 27. September 2023 CS:GO, sodass normale Nutzer CS:GO nicht mehr spielen konnten
• Im HackerOne-Bug-Bounty-Umfang von Valve war cs2.exe nicht enthalten, und auch Meldungen zum CS2 Limited Test waren als außerhalb des Umfangs markiert

Plötzlich stark zunehmende Meldungen bei Esportal

• Esportal hatte dieses Problem schon früher in CS:GO; die erste protokollierte Instanz war am 2019-11-15 19:15:32 CET, die letzte CS:GO-Instanz am 2023-09-26 21:38:01 CET, also am Tag vor der Ablösung durch CS2
• Zu Beginn von CS2 schien das Problem verschwunden zu sein, doch in der ersten Januarwoche 2024 nahmen die Nutzermeldungen zu
  • 2024-01-03: 6 % der täglichen Tickets
  • 2024-01-05~06: 18 %
  • 2024-01-07: 23 %
  • 2024-01-08: 10 %
  • 2024-01-09: 9 %
• Die Meldungen häuften sich vor allem zwischen 13 und 17 Uhr CET, was in Washington 04 bis 08 Uhr entspricht
• Früher waren die Meldungen gleichmäßig über den Tag verteilt, doch das neu beobachtete Problem konzentrierte sich auf bestimmte Zeitfenster
• Auch Spieler außerhalb von Esportal hatten dasselbe Problem, es war also kein plattformspezifisches Problem

Symptome: verzögerte Steam-Verifizierung und verschwundene Skins

• Der beobachtete No user logon-Fehler trat 2 bis 3 Minuten nach dem Verbinden des Spielers mit dem Gameserver auf, und dieses Zeitintervall war recht konstant
• Ein Kollege sagte: „Ein paar Minuten nach dem Einstieg ins Spiel werden in CS2 keine Skins angezeigt“, und auch Spieler außerhalb von Esportal meldeten fehlende Skins
• Da Skins mit dem Besitz einer Steam-ID verknüpft sind, ist es wahrscheinlich, dass der Spieler bis zur Anzeige seiner persönlichen Skins nicht korrekt über Steam authentifiziert war
• In Logs normaler Nutzer wurde STEAM USERID validated etwa 1 Minute 20 Sekunden nach dem Verbinden protokolliert

16:39:55: "Alice<1><>" connected
16:41:14: "Alice<1><>" STEAM USERID validated
17:17:32: "Alice<1><CT>" disconnected (reason "NETWORK_DISCONNECT_DISCONNECT_BY_USER")

• In älteren Logs vor dem 3. Januar 2024 war die Steam-Verifizierung bereits 2 bis 3 Sekunden nach dem Verbinden abgeschlossen
• Während der Nachtstunden in Washington ließ sich das Problem direkt reproduzieren, tagsüber in Washington dagegen nicht

NETWORK_DISCONNECT_STEAM_LOGON und failure code 8

• In Logs fehlgeschlagener Nutzer wurde direkt vor dem Disconnect mit NETWORK_DISCONNECT_STEAM_LOGON STEAMAUTH: Client Bob received failure code 8 protokolliert

16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")

• NETWORK_DISCONNECT_STEAM_LOGON ist vermutlich die interne Kennung für die dem Nutzer angezeigte Meldung No user logon
• Dazu wurde in libengine2.so die Zeichenkette STEAMAUTH: Client %s received failure code %d gesucht und mit sv_steamauth.cpp aus dem geleakten CS:GO-Quellcode sowie Ergebnissen aus Reverse Engineering verglichen
• Die relevante Funktion in CS2 trennt den Client je nach eAuthSessionResponse-Wert
  • 1: k_EAuthSessionResponseUserNotConnectedToSteam
  • 7: k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed
  • 8: k_EAuthSessionResponseAuthTicketInvalid
• failure code 8 scheint k_EAuthSessionResponseAuthTicketInvalid zu entsprechen, das bei fehlgeschlagener Steam3-Verifizierung erscheint

Ablauf der Steam3-Verifizierung

• Der Spielclient CS2.exe übermittelt beim Verbinden mit einem Gameserver seine Steam-ID
• Der Gameserver fragt daraufhin beim Steam3-Server nach, ob diese Steam-ID gültig ist und ob das Spiel im Besitz des Nutzers ist
• Während auf die Verifizierungsantwort gewartet wird, kann der Spieler auf dem Server weiterspielen, aber persönliche Skins werden möglicherweise nicht angezeigt
• Wenn der Steam3-Server mit „yes“ antwortet, vertraut der Gameserver dieser Information und kann persönliche Daten wie Skins anwenden
• Wenn der Steam3-Server mit „no“ antwortet, trennt der Gameserver den Client mit NETWORK_DISCONNECT_STEAM_LOGON
• Während der Nachtstunden in Washington, wenn die Steam3-Antworten langsam waren, dauerte es bis zum Abschluss der Verifizierung etwa 1 Minute 20 Sekunden

Vertrauensprüfung von CS2.exe und Steam-Client

• Dass eine Steam-ID gültig ist, beweist noch nicht, dass die betreffende CS2.exe-Instanz zum Spiel des auf derselben Maschine eingeloggten Steam-Kontos gehört
• CS2.exe muss sich mit Steam.exe auf derselben Maschine verbinden und bestätigen lassen, dass die gesendete Steam-ID mit dem aktuell eingeloggten Steam-Konto übereinstimmt
• Wenn Steam.exe diese Übereinstimmung bestätigt, speichert der Steam3-Server vorübergehend, dass diese Steam-ID für CS2 gültig ist
• Von den möglichen Gründen, warum Steam3 mit „no“ antworten kann, bleiben als realistische Ursache für das tatsächliche Problem im Wesentlichen zwei übrig
  • Die CS2.exe-Instanz ist nicht vertrauenswürdig
  • Der Steam3-Server kennt die Steam-ID-Informationen zu dieser CS2.exe-Instanz noch nicht

Hinweise auf der Client-Seite: NETWORK_DISCONNECT_LOOPSHUTDOWN

• In fehlgeschlagenen Logs erscheint vor NETWORK_DISCONNECT_STEAM_LOGON zuerst NETWORK_DISCONNECT_LOOPSHUTDOWN

16:40:03: "Bob<6><>" connected
16:40:08: "Bob<6><Unassigned>" disconnected (reason "NETWORK_DISCONNECT_LOOPSHUTDOWN")
16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")

• Nach NETWORK_DISCONNECT_LOOPSHUTDOWN versucht das Spiel 5 Sekunden später automatisch erneut, die Verbindung herzustellen
• Dieser erste Disconnect wurde nicht vom Gameserver, sondern von CS2.exe selbst ausgelöst
• Die eigentliche Ursache lag damit nicht auf dem Gameserver, sondern im Spielclient

Die levelload-Schleife von Source 2 und die Initialisierungsreihenfolge

• Die Source-2-Engine führt jeweils nur eine aktive Schleife aus; diese wiederholt Hintergrundaufgaben und verarbeitet Nutzereingaben, bis ein bestimmtes Ziel erreicht ist
• Die Schleife, die nach dem Start von CS2.exe zuletzt läuft, ist die game-Schleife, die für die eigentliche Menüinteraktion und das Gameplay zuständig ist
• In der Konsolenausgabe wird direkt vor dem Wechsel in die game-Schleife der Steam-Auth-Status als OK angezeigt

[SteamNetSockets] AuthStatus (steamid:<redacted>):  OK  (OK)
[Client] CL:  CLoopModeLevelLoad::MaybeSwitchToGameLoop switching to "game" loopmode with addons ()
[EngineServiceManager] SwitchToLoop game requested:  id [1] addons []

• levelload ist die Initialisierungsschleife, die beim Start von CS2 läuft, und lädt offenbar frühe Oberflächen wie Intro-Video und Hauptmenü, auch wenn noch keine echte Map geladen wird
• Zu den letzten Aufgaben von levelload gehört es, aus CS2.exe heraus über Steam.exe die Steam3-Verifizierung zu starten

Die direkte Ursache des Bugs

• CS2 gilt erst dann als vollständig initialisiert, wenn die levelload-Schleife erfolgreich abgeschlossen wurde
• Wenn die levelload-Initialisierung vorzeitig endet, startet die Steam3-Verifizierung nicht
• Die CS2.exe-Instanz befindet sich dann in einem defekten Zustand und lässt sich nicht wiederherstellen, bis CS2 erneut gestartet wird
• Der Ablauf des Bugs ist wie folgt
  • CS2.exe startet
  • Die levelload-Schleife startet
  • levelload endet vorzeitig, bevor die Steam3-Verifizierung beginnt
  • Die game-Schleife verbindet sich mit einer nicht verifizierten Steam-ID zum Gameserver
  • Der Gameserver fragt bei Steam3 nach
  • Nach maximal etwa 2 Minuten 50 Sekunden kommt eine Fehlantwort zurück und die Verbindung wird mit No user logon getrennt
• Dieser Text behandelt das Problem anhand von CS2-Beispielen und Bezeichnungen, aber ein entsprechender Bug existiert auch in CS:GO und Counter-Strike: Source, nur mit anderen technischen Namen und Mechanismen

Verbindungsarten, die den Bug auslösen

• Das Problem ist eine Race Condition abhängig davon, wie CS2 gestartet wird
• Am sichersten lässt sich der Bug auslösen, wenn man direkt einem Gameserver beitritt, während CS2 noch nicht läuft
• Zu den riskanten Verbindungsarten gehören
  • Verbindung zu einem Server über einen externen Serverbrowser, wenn CS2 nicht läuft oder gerade erst gestartet wurde
  • Verbindung zu einem Freund über die Steam-Freundesliste, wenn CS2 nicht läuft oder gerade erst gestartet wurde
  • Direkte externe Verbindung über das Steam-Browserprotokoll wie steam://connect/127.0.0.1:27015
• Führt man diese Aktionen aus, bevor CS2 vollständig initialisiert ist, steigt die Wahrscheinlichkeit deutlich
• Der Ursachenanteil wird bildlich zusammengefasst als „90 % Art des Startens von Counter-Strike, 3 % Rechnergeschwindigkeit, 3 % Benutzerreaktion, 3 % Mondphase, 1 % tatsächliches Problem mit Nutzereinstellungen“

Die tatsächliche Lösung

• Was man nicht tun sollte
  • Spiel neu installieren
  • Spieldateien prüfen
  • Steam neu starten
  • Computer neu starten
  • WLAN deaktivieren
  • Von außerhalb einem Gameserver beitreten, bevor CS2 gestartet ist
• Stattdessen sollte man zuerst CS2 starten und dann ausreichend warten, bevor man einem Gameserver beitritt
• Als Richtwert gilt: warten, bis die Spielkonsole verfügbar ist, oder nach Erscheinen des Intro-Videos 5 bis 10 Sekunden warten
• Zur sicheren Prüfung kann man nach dem Start von CS2 in der Spielkonsole status eingeben und die folgende Zeile prüfen

[EngineServiceManager] @ Current  :  game

Ergebnis der Esportal-Korrektur

• Dass der fehlgeschlagene Nutzer Bob 9 Minuten nach dem ersten Versuch erfolgreich verifiziert wurde, lag daran, dass er CS2 neu gestartet hatte und der Bug dabei zufällig nicht erneut auftrat
• Sobald eine Steam-ID einmal verifiziert wurde, tritt in derselben Spielinstanz später kein Fehler mehr auf, solange der Steam-Client nicht geschlossen wird
• Bis zum 10. Januar 2024 ließ Esportal den Matchmaking-Server per steam://connect/<IP>:<Port> verbinden, sobald der CS2.exe-Prozess erschien, also noch vor vollständiger Initialisierung
• Nachdem dieses Verhalten korrigiert und an alle Esportal-Spieler ausgerollt wurde, stoppten die entsprechenden Nutzertickets
• Der Anteil von No user logon an den täglichen Tickets war am 2024-01-07 auf 23 % gestiegen, fiel aber vom 2024-01-10 bis 2024-01-12 auf 0 %

[GN⁺]

Hacker-News-Kommentare

• Der Ablauf im Diagramm entspricht eher dem, was Steam Session Tickets nennt, und ist in der Praxis etwas subtiler.
  Der Game-Client fordert beim Steam-Server ein Session Ticket an und übergibt dem Game-Server dann ein Ticket, das beweist, dass er eine bestimmte Steam ID ist.
  Anschließend muss der Game-Server das Ticket online über Steams Web API prüfen, um zu verifizieren, dass es nicht mehrfach verwendet oder manipuliert wurde.
  Es klingt so, als ob der CS2-Client eine verzögerte Antwort beim Abrufen des Session Tickets nicht korrekt behandelt.
  Der Ablauf ist hier ausführlich beschrieben: https://partner.steamgames.com/doc/features/auth#3
  Wenn es so funktionieren würde wie im Diagramm des Artikels, wäre das ziemlich bedenklich, weil ein Angreifer mit der Steam ID des Opfers um den Serverbeitritt konkurrieren könnte.

  • Stimmt, es sind sehr wahrscheinlich im Wesentlichen Session Tickets, und im Artikel scheint dieser Teil nicht klar dargestellt zu sein.
    Das Problem scheint darin zu liegen, dass das Spiel abgebrochen wird, bevor es tatsächlich ein Session Ticket erstellt, oder während es auf die langsame Antwort des Steam-Servers wartet, und sich dann ohne Ticket mit dem Game-Server verbindet.
  • Stimmt, technisch gesehen ist dieser Ablauf korrekt, und ich hielt ihn für die Problembeschreibung nicht besonders wichtig, aber ich hätte ihn klarer erwähnen sollen.

• Der Artikel ist hervorragend, aber der Nachverfolgungsprozess und die Schlussfolgerung greifen nicht ganz ineinander.
  Einerseits heißt es „Wie Counter-Strike startet: 90 % Verantwortung“, andererseits lässt sich schwer gleichzeitig behaupten, dass Spieler weltweit dasselbe Problem auch außerhalb von Esportal hatten und dass es auf die nächtliche Wartung in Washington zurückzuführen sei.
  Wenn die Verantwortung zu 90 % bei der Startweise läge, wäre das Problem nicht auf Wartungszeiträume verteilt gewesen.
  Der Kern scheint in den Aussagen zu liegen: „Die Steam-ID-Prüfung beginnt direkt bevor der Game Loop startet“ und „Wenn die levelload-Initialisierung nicht abgeschlossen ist, startet die Steam3-Prüfung nicht, weil sie der letzte Schritt ist.“
  Wenn also die steam3-Server während der Wartungszeit sehr langsam werden, verlängert sich dieser Vorgang, und in der Zwischenzeit steigt die Wahrscheinlichkeit, dass man das Spiel startet und den Loop unterbricht.
  Deshalb stimmt „Wie Counter-Strike startet“ zwar auch, aber eine Formulierung wie „Mondphase: 3 % Verantwortung“ verweist praktisch auf das Wartungsfenster und wirkt daher etwas daneben.
  Der Rat sollte am besten auch enthalten: „Zwischen 13 und 17 Uhr CET ist Valves Wartungsfenster, wartet also ein paar Minuten länger.“
  Jedenfalls hatte ich dieses Problem selbst, und die Lösung „warte ein wenig, bis das Laden abgeschlossen ist“ ist die bisher praktischste und plausibelste, die ich gehört habe.

  • In den Details der Erklärung oder Schlussfolgerung gibt es Lücken, aber ich bin auch nicht sicher, ob diese Interpretation vollständig stimmt.
    Bei CS:GO trat dasselbe Problem unabhängig vom Wartungsfenster auf, während es bei CS2 nur während des Wartungsfensters beobachtet wurde.
    Am Ende könnten CS:GO und CS2 unterschiedliche Fehlerarten gehabt haben, aber da CS:GO durch CS2 ersetzt wurde, lässt sich das nicht mehr beweisen.

• Vor langer Zeit, als es Steam noch nicht gab, habe ich einmal ein Tool gebaut, das eine Liste aktiver Spieler und Punktestände anzeigte, damit man sehen konnte, auf welchem Server ein Freund spielt, und direkt beitreten konnte.
  Beim Entwickeln dieses Tools habe ich versehentlich ein fehlerhaftes Paket an den Server geschickt, auf dem ich getestet habe, und der Server ging offline.
  Ich habe den in Delphi geschriebenen Quellcode noch; wenn zehn Jahre alte Bugs noch vorhanden sind, frage ich mich, ob das heute immer noch Server abschießen könnte.

  • Kannst du es mal ausprobieren? :D

• Der eigentliche Bug ist, dass eine abgeschlossene Authentifizierung keine zwingende Voraussetzung für den Start eines Nicht-LAN-Multiplayers ist.

  • Oder auch, dass der Ablauf zur Prüfung von Session Tickets von der Verbindung zwischen Game-Server und Valves Authentifizierungsserver abhängt. Dieser Auth-Server scheint gelegentlich sehr langsam zu sein.
    Eine schnellere und robustere Variante könnte sein, dass der Steam-Client von Valve ein signiertes Token mit einer Gültigkeit von einigen Stunden erhält und speichert und dieses Token bei jeder Verbindung mit einem Game-Server mitschickt.
    Der Game-Server könnte es dann lokal mit einem öffentlichen Zertifikat prüfen, das von Valve ausgegeben und zusammen mit den Serverinhalten verteilt wird.

• Einige Absätze fühlen sich an, als würde man „Hüte auf Hüte stapeln“.
  Auf bereits memeartige Absätze wird noch mehr Sarkasmus gepackt, wodurch ein Element, das subtil besser funktioniert, übertrieben wirkt.
  Wie andere schon gesagt haben: Es wäre besser, schneller zum Kern zu kommen.

• Sehr unterhaltsam gelesen. Ich frage mich, ob man auf dieselbe Weise untersuchen könnte, warum der Game-Client plötzlich crasht.
  Außerdem frage ich mich, ob die Integritätsprüfung der ausführbaren Dateien auch während der Ausführung läuft und ob bei einem Fehlschlag einer dieser Prüfungen während des Betriebs eine andere Verbindungsabbruchmeldung erscheint.
  Das wirkt, als könnte es sich ähnlich lohnen wie der Artikel zur Analyse der viel zu langen Ladezeiten von GTA V: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

  • Ich frage mich, welche plötzlichen Crashes gemeint sind.
    Crashes lassen sich theoretisch untersuchen, aber Valve speichert Crash-Reports nicht auf der Festplatte, sondern schickt sie an den Server.
    Wenn man sie nicht live mit angehängtem Debugger erwischt, ist die Analyse schwieriger; wegen VAC ist das heikel, aber nicht unmöglich. Man kann VAC deaktivieren.

• Es wirkt rücksichtsvoll, dass am Anfang des Artikels eine Zusammenfassung für Leute steht, die über eine Suche zur Problemlösung gekommen sind.
  Direkt danach steht aber, was man nicht tun soll, während die tatsächlich mögliche Maßnahme in einem einzigen Satz mitten in einem kilometerlangen Artikel versteckt ist.
  Es wäre besser, den Workaround in die Zusammenfassung aufzunehmen.

  • Fast wie ein grausamer Scherz. Zusammenfassung: Macht das hier nicht, lest stattdessen den ganzen Artikel!
  • „Kilometerlanger Artikel“ entspricht in metrischen Einheiten etwa 25-mal Page Down, in Freedom Units ungefähr STRG+F.
  • Stimmt, ich habe es mit einer besseren Zusammenfassung aktualisiert.

• Ich sage das nur, weil mir der Schreibstil nach Strunk and White im Kopf festhängt; ignorier es gern.
  Falls Feedback gewünscht ist, würde ich empfehlen, den Text viel direkter und knapper hart zu redigieren.
  Man kann lange Texte schreiben, aber nach ein paar Minuten haben sich Zusatz-Erklärungen und Anekdoten angesammelt, und ich habe den roten Faden ziemlich schnell verloren.
  Wenn dann noch ein Inception-Referenzbild dazukommt, wirkt es stärker wie eine Sammlung unzusammenhängender Inhalte als wie ein erklärender Artikel.
  Überleg dir, was du sagen willst, sag es, und geh dann noch einmal zurück und prüfe, ob du wirklich nur das gesagt hast.
  Der Rest ist eher Tippübung als Schreiben. Wenn du drei oder vier Dinge zu sagen hast, sag einfach nur diese.

• Der Artikel war großartig, aber ein paar Fragen bleiben.
  Wird levelloadloop nur beim Start des Spiels ausgeführt und nicht beim Serverbeitritt und beim Laden von Maps?
  Wenn das Problem darin besteht, dass der Loop endet, bevor der Steam-Authentifizierungsprozess startet, warum ist dann die durch Wartung verursachte Verlangsamung relevant?

  • 1 stimmt, es läuft nur beim Spielstart.
    Der Name dieses Loops scheint mit Singleplayer-Spielen wie Portal zusammenzuhängen, und in solchen Spielen wechselt man Level ohne Unterbrechung, daher ist dieser Name dort viel natürlicher.
    Bei 2 stimmt, dass die Erklärung eine Lücke hat, und ich kenne die Antwort nicht.
    Allerdings ist sicher, dass diese Methode das Problem behebt. Die Details der Schlussfolgerung sind wahrscheinlich unvollständig, aber im Moment sehe ich keinen Bedarf, noch tiefer zu graben.

• In Valves Bug-Bounty-Formulierung steht, dass „die Steam-Plattform und aktuelle von Valve entwickelte und veröffentlichte Spiele“ enthalten sind.
  Außerdem heißt es, dass neue CS:GO-Berichte seit dem 14. Juni 2023, 10:00 Uhr PDT, außerhalb des Geltungsbereichs liegen, und dass Berichte zum CS2 Limited Test derzeit ebenfalls außerhalb des Geltungsbereichs liegen.
  Valve ist zwar tatsächlich schwach bei Sicherheit, aber wenn man die gesamte HackerOne-Beschreibung weit auslegt, würde ich es persönlich als im Scope ansehen.
  Da sie den „Scope“-Tab nicht aktualisiert haben, um csgo.exe auszuschließen, heißt das, dass man sich nicht allein auf diesen Tab verlassen kann.
  Trotzdem sollte Valve diesen Teil bitte aktualisieren.

  • Da Valve nicht einmal auf eine einfache Anfrage antwortet, ob das im Scope ist, lässt sich das nicht wissen.
    Der Schlussfolgerung stimme ich aber zu, und sie ergibt Sinn.