Zusammenfassung

  • Im untersuchten Sagan-Code genügt für is_success eine Antwort mit einem als wahr ausgewerteten RTT-Wert ohne Paketfehler am letzten gelieferten Hop. Ein Vergleich mit der Zieladresse gehört nicht zu dieser Bedingung.
  • Das ist keine versteckte Gleichsetzung durch die Bibliothek: destination_ip_responded und last_hop_responded stehen als eigenständige Felder bereit. Das Risiko entsteht, wenn ein nachgelagerter Nutzer aus einem einzelnen Feld eine weitergehende Behauptung ableitet.
  • last_median_rtt kann den Median eines früheren antwortenden Hops enthalten, obwohl der letzte Hop schweigt. Auch die verkürzte Hop-Ausgabe löscht dabei nicht die aufbewahrten Rohdaten.
  • 21 bestehende Traceroute-Tests und fünf erfundene Eingaben wurden lokal am festgehaltenen Originalcode geprüft. Das belegt ausgewählte Parserbedingungen, nicht einen Ausfall im Internet oder die Verfügbarkeit einer Anwendung.

Drei Antworten auf verschiedene Fragen

Das Wort „erfolgreich“ klingt nach einem abgeschlossenen Weg. In einem Messparser kann es eine erheblich schmalere Bedeutung haben. Der letzte gelieferte Abschnitt einer Traceroute-Auswertung enthält eine Antwort; ein RTT-Wert ist vorhanden; der betreffende Paketdatensatz trägt keinen Fehler. Daraus folgt zunächst etwas über diesen Abschnitt und diesen Datensatz. Ob die Antwort von der Adresse stammt, zu der die Messung unterwegs war, ist eine andere Frage.

Sagan, die offene Python-Bibliothek zur Auswertung von RIPE Atlas-Ergebnissen, macht diese Trennung sichtbar. Im hier untersuchten Stand setzt die Methode set_is_success das Erfolgsfeld, wenn am letzten gelieferten Hop mindestens ein Paket einen als wahr ausgewerteten RTT-Wert hat und packet.is_error nicht gesetzt ist. Eine Prüfung auf Übereinstimmung zwischen Antwortadresse und Zieladresse findet an dieser Stelle nicht statt. Die getrennte Methode set_destination_ip_responded stellt genau diesen Adressvergleich für Pakete des letzten Hops an. set_last_hop_responded prüft wiederum den RTT-Wert dieses Hops, ohne die zusätzliche Fehlerbedingung des Erfolgsfelds. Der festgehaltene Traceroute-Code ist deshalb aussagekräftiger als eine intuitive Übersetzung des Feldnamens.

Der Code-Stand ist mit dem Commit 45d01f754896ad648e5b306c4209153bab774af9 vom 3. Juni 2026 fixiert. Das ist eine überprüfbare Quellenentscheidung, keine Behauptung, dass jeder installierte Sagan-Client oder die aktuelle Paketveröffentlichung diesem Stand entspricht. Ebenso wenig folgt daraus, dass ein bestimmter Nutzer die Felder falsch verwendet. Für einen solchen Vorwurf fehlt hier ein belegter Verbraucher. Die Untersuchung betrifft die nachweisbare Grenze einer Aussage, nicht die Unterstellung eines verbreiteten Fehlers.

Ein künstliches Beispiel zeigt diese Grenze ohne eine aktive Messung. Die Zieladresse lautet 198.51.100.10. Der einzige gelieferte Hop enthält eine fehlerfreie Antwort von 192.0.2.1 mit zehn Millisekunden RTT. Am Originalcode ergeben sich is_success=True und last_hop_responded=True, während destination_ip_responded=False bleibt. Der Parser widerspricht sich nicht. Er beantwortet drei verschiedene Fragen. Erst die Überschrift „Ziel erreichbar“ über dem ersten Wert würde eine Behauptung ergänzen, die dieser Wert allein nicht trägt.

Die Bibliothek liefert die Gegenprobe bereits mit

Die stärkste Entlastung für Sagan steht unmittelbar neben der fraglichen Bedingung. Die alternative Information ist vorhanden. Die Typendokumentation beschreibt die eigenständigen Eigenschaften; die bestehenden Traceroute-Tests und die öffentliche Implementierung lassen ihre Verwendung prüfen. Die Projektbeschreibung verortet das Werkzeug als Parser für Messergebnisse. Es ist keine allgemeine Bescheinigung über einen Dienst.

Eine zweite erfundene Eingabe liefert die gewöhnliche Übereinstimmung: Derselbe RTT-Wert stammt nun von der Zieladresse und enthält keinen Paketfehler. Alle drei Felder werden wahr. Diese positive Gegenprobe ist wichtig. Die erste Eingabe demonstriert nicht, dass Erfolg und Zielantwort nie zusammenfallen. Sie zeigt, dass ihre Übereinstimmung aus den konkreten Daten entstehen muss und nicht aus dem Namen eines Felds vorausgesetzt werden darf.

Ein weiterer lokaler Fall kombiniert eine Antwort der Zieladresse mit zehn Millisekunden RTT und einem als p gelieferten Fehler. Die Auswertung ordnet diesen als „Port unreachable“ ein. destination_ip_responded und last_hop_responded sind wahr, is_success ist falsch. Damit wird auch die umgekehrte Verkürzung unhaltbar: Ein falsches Erfolgsfeld bedeutet nicht zwangsläufig, dass kein Datensatz von der Zieladresse vorhanden ist. Die Fehlerbedingung gehört zur Bedeutung des ausgewählten Felds.

Diese Gegenproben sollten die Debatte von einer bloßen Namenskritik wegführen. Eine öffentliche Bibliothek darf mehrere fachliche Prädikate anbieten. Ein Bericht muss dann offenlegen, welches er benutzt. Ohne diese Angabe ist „Erfolgsquote“ keine genügend bestimmte Kennzahl. Ihr Zähler könnte fehlerfreie letzte Hop-Antworten zählen, Zieladressantworten zählen oder erfolgreiche Anwendungsaufrufe behaupten. Das sind keine austauschbaren Mengen.

Zehn Millisekunden, aber nicht bis zum Ziel

Die RTT-Eigenschaft setzt eine zweite Grenze. Sagan bildet für einen Hop einen Median aus berücksichtigten Paketwerten. Die betrachtete Auswahl enthält nicht verspätete Pakete mit einem als wahr ausgewerteten RTT-Wert. Für last_median_rtt wird die gelieferte Hop-Liste rückwärts durchsucht; der erste dabei gefundene als wahr ausgewertete Hop-Median wird übernommen. Diese Auswahl ist kein zusätzlicher Abgleich mit der Zieladresse und keine eigenständige Rekonstruktion des tatsächlichen Paketwegs.

In der dritten erfundenen Eingabe enthält der erste Hop fünf Millisekunden, der zweite zehn Millisekunden und der letzte nur eine ausbleibende Antwort mit x: *. Alle drei Antwort- beziehungsweise Erfolgsfelder bleiben falsch. last_median_rtt beträgt trotzdem zehn Millisekunden. Der Wert stammt aus dem zweiten Hop. Er ist als ausgewählte RTT-Information nicht dadurch falsch, dass der letzte Hop schweigt. Falsch wäre die nachträgliche Beschriftung als gemessene Laufzeit zur Zieladresse.

Die Unterscheidung wird dringlicher, wenn eine Anzeige nur wenige Eigenschaften übernimmt. Ein Wert kann sauber berechnet und doch falsch benannt werden. Eine Zeitreihe könnte über längere Zeit Medianwerte früherer antwortender Hops enthalten und anschließend Werte des tatsächlich antwortenden Ziels. Ohne den Herkunftswechsel zu markieren, erschiene eine durchgängige Reihe „Latenz zum Ziel“. Der Parsercode allein belegt nicht, dass eine solche Anzeige existiert. Er zeigt, welche Information eine Anzeige bewahren müsste, damit ihre Aussage überprüfbar bleibt.

Aus dieser begrenzten Beobachtung lässt sich auch keine vollständige Mathematik aller denkbaren Eingaben ableiten. Die untersuchte Bedingung verwendet die Wahrheitsauswertung von Werten; sie ist nicht gleichbedeutend mit einer hier nachgewiesenen Prüfung aller Nullwerte, Zahlenformate, verspäteten Antworten oder fehlerhaften Eingaben. Die fünf Fälle wurden ausgewählt, um verschiedene Prädikate zu trennen. Sie zertifizieren nicht den gesamten zulässigen Eingaberaum.

Weniger angezeigte Hops sind nicht weniger Rohdaten

Sagan kann mit parse_all_hops=False eine verkürzte Hop-Darstellung bereitstellen. Im fünften lokalen Fall wird dieselbe Eingabe mit dem schweigenden dritten Hop auf diese Weise verarbeitet. Die gespeicherte Hop-Liste enthält dann nur den letzten Hop; die Gesamtzahl der Hops bleibt drei, und last_median_rtt bleibt zehn Millisekunden. Der früher gewonnene Wert kann also neben einer Darstellung stehen, die den antwortenden zweiten Hop nicht mehr als eigenes Hop-Objekt zeigt.

Die Folgerung darf hier nicht größer werden als der Befund. Die Basisklasse bewahrt raw_data. Im geprüften Fall bleibt die volle ursprüngliche Eingabe erhalten. „Verkürzte Hop-Ausgabe“ heißt daher nicht „gelöschte Messquelle“. Wer einen kompakten Ergebnisausschnitt veröffentlicht, sollte gleichwohl zwischen dem Ausschnitt und dem Nachweis unterscheiden, der seine Interpretation ermöglicht. Die Rohdaten helfen nur, wenn die Verbindung zu ihnen erhalten bleibt.

Auch die Rolle einer Adresse muss aus ihrem jeweiligen Kontext kommen. Die allgemeine Dokumentation des RIPE Atlas-Ergebnisformats unterscheidet das oberste Feld from, das der Messbackend ergänzt, vom Feld src, das von der Probe beziehungsweise ihrem Socket stammt. Beide können sich legitim unterscheiden. Diese allgemeine Erläuterung ist keine Spezifikation der hier betrachteten Traceroute-Hop-Felder. Der Vergleich der Paketantwort mit dem Ziel wird aus dem Traceroute-Code belegt. Gleiche Zeichenfolgen als Feldnamen begründen noch keine gleiche Rolle auf jeder Ebene.

Eine Antwort bleibt ein eingegrenztes Ereignis

Traceroute arbeitet gerade mit Antworten, die nicht zwingend vom Ziel kommen. RFC 792 beschreibt unter anderem ICMP „Time Exceeded“ nach Ablauf der Lebensdauer eines Pakets. Eine solche Mitteilung kann von einem Zwischenknoten stammen; der Standard formuliert Möglichkeiten der Benachrichtigung, keine Garantie für jede erwartete Antwort. Ein schweigender Hop liefert deshalb zunächst einen fehlenden Beobachtungspunkt in diesem Ergebnis, nicht automatisch eine fertige Diagnose des gesamten Netzes.

Ebenso wenig ersetzt die Antwort eines Zwischenknotens eine Anwendungsprüfung. Die hier untersuchten synthetischen Adressen sind Dokumentationsadressen. Es wurden keine Pakete an sie gesendet, keine Dienste aufgerufen und keine Absender authentifiziert. Die lokale Prüfung lud die festgehaltenen Originalklassen und führte 21 bestehende Traceroute-Tests sowie fünf erfundene Fälle aus; alle Prüfungen endeten ohne Fehler. Netzwerkzugriffe waren ausgeschlossen. Das ist ein enger Reproduktionsnachweis ausgewählter Auswertungen, kein Atlas-Flottenexperiment.

RFC 2330 bietet die passendere Disziplin für die spätere Kennzahl: Einzelmessung, Stichprobe und Statistik müssen unterschieden werden; die Art des untersuchten Verkehrs gehört zur Definition. Eine sauber benannte lokale Eigenschaft ist ein Anfang. Erst Messpopulation, Zeitfenster, Verkehrsart und Aggregationsregel machen daraus eine belastbare vergleichende Aussage. Wer von einem Paketfeld direkt zu einem allgemeinen Verfügbarkeitsversprechen springt, überspringt diese Arbeit.

Quellen

Die Codeaussagen beziehen sich auf die oben verlinkten, commitgebundenen Dateien von Sagan: Traceroute-Klassen, Basisklasse, Typendokumentation, bestehende Traceroute-Tests und Projektbeschreibung. Hinzu kommen die allgemeine RIPE Atlas-Ergebnisformat-Dokumentation sowie RFC 792 und RFC 2330. Die fünf Beispiele sind ausdrücklich erfundene lokale Eingaben. Keiner dieser Nachweise belegt die Fehlverwendung durch einen benannten Nutzer, einen aktuellen Netzausfall, die Verbreitung einer bestimmten Installation oder eine neue Zusage von RIPE NCC.