10.04.2022, aktualisiert am 12.04.2022

9314

Traceroute - Bedeutung von "Sternchen"

Guten Morgen!

Ich habe eine Verständnisfrage:
Mein Macbook nutzt den iPhone Hotspot (Vodafone) für den Internetzugriff.

Wenn ich am Macbook einen traceroute alternate.de durchführe, bekomme ich folgendes Ergebnis (Ausschnitt):

Traceroute zeigt mir ja die "Hops" an von mir bis zum Ziel, korrekt?
Warum kommen so viele * * * bis dann mal wieder ein Ergebnis geliefert wird?
Bedeuetet dies für mich, das 2 - 8 schon ein Hop ist, aber nur nicht antwortet, oder wie ist dies zu verstehen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2464224299

Url: https://administrator.de/forum/traceroute-bedeutung-von-sternchen-2464224299.html

Ausgedruckt am: 23.04.2025 um 17:04 Uhr

16 Kommentare

Neuester Kommentar

Moin,

Zitat von @145971:
Mein Macbook nutzt den iPhone Hotspot (Vodafone) für den Internetzugriff.
[...]
Warum kommen so viele * * * bis dann mal wieder ein Ergebnis geliefert wird?
Bedeuetet dies für mich, das 2 - 8 schon ein Hop ist, aber nur nicht antwortet, oder wie ist dies zu verstehen?

Das liegt an der Verbindung über den Hotspot/Mobiles Internet.
Die Antwort von den Zwischen-Hops gelangt nicht zu Deinem MacBook/Endgerät. Der 1. Hop ist Dein iPhone.

Vergleiche mal mit einem Festnetz-Anschluss.

Gruß

cykes

@cykes
Bist du sicher, dass es am mobilen Datennetz liegt?
Warum kommen die Nicht-ICMPs denn dann an?

Ich gehe eher davon aus, dass die Zwischengeschalteten Router die ICMP-Pakete (Ping-Pakete) schlicht nicht beantworten, egal, ob man über Kabel/ DSL oder Mobilfunk kommt.

Gruß
em-pie

Hi em-pie,

ich habe mal testweise einen tracert über meinen Telekom VDSL-Anschluss zu alternate.de gemacht, und da war nur der 6. Hop unbeantwortet.

>tracert alternate.de

Routenverfolgung zu alternate.de [172.65.240.30]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  <anon.intern> [192.168.x.x]
  2     2 ms     1 ms     1 ms  <anon2.intern> [192.168.y.y]
  3     9 ms     9 ms     9 ms  <anonymisiert>.t-ipconnect.de [62.a.b.c]
  4    13 ms    13 ms    13 ms  <anonymisiert>.dip0.t-ipconnect.de [217.d.e.f]
  5    19 ms    26 ms    19 ms  80.156.162.178
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7    20 ms    23 ms    20 ms  195.219.148.122
  8    30 ms    32 ms    19 ms  172.70.248.3
  9    19 ms    19 ms    19 ms  172.65.240.30

Ablaufverfolgung beendet.

Dürfte wohl hauptsächlich am CGN über die Mobilverbindung liegen.

Gruß

cykes

Hallo,

die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, die Ping-Anfragen von Internetdetektiven zu beantworten

Ich habe bei einem ISP gearbeitet, der ICMP ebenfalls konsequent geblockt hat. Zumal es Angriffsszenarien gibt, die genau darauf aufbauen. Stichwort „Ping of death“

Gruß,
Jörg

Moin,

Die Sternchen bedeuten nur, daß da ein timeout war, d.h. innerhalb des erwarteten Zeitfensters keine Antwort kam. Das kann viele Ursachen haben.

Der Router des ISP/Carrier antwortet generell nicht an "fremde" Systeme.
Der Router oder irgendein System auf dem Weg verzögert die Antworten.
Irgendwelche Providerfirewalls filtern die Antworten raus um keine "internen" Informationen herauszugeben
Der Provider benutzt intern ggf. RFC1918-Adressen, die dann den Weg nach "draußen" nicht finden (dürfen).
usw.

Im Endergebnis führt alles dazu, das traceroute keine (rechtzeitige) Antwort von dem jeweiligen Hop entsprechenden System bekommt und es deswegen ein Sternchen hinmalt.

lks

P.S. Gerade mal Gegenprobe über meinen LTE-Router gemacht, über das o2/E-Plus Netz bekomme ich Antworten von den Zwischenhops

Und über Vodafone Kabel Business in der Firma ebenfalls Zwischenhops.

Dürfte m.E. am Vodafone Mobilnetz liegen

Und weitere Erkenntnis: Auch über LTE im Telekom Netz direkt auf'm Smartphone keine Zwischenhops nur das Ziel antwortet nach 14 Hops.

Also würde ich es auf das Telefon im Mobilnetz schieben

Zitat von @117471:

Hallo,

die Aufgabe eines Routers ist, Datenpakete weiterzuleiten und nicht, die Ping-Anfragen von Internetdetektiven zu beantworten

Der soll auch bei traceroute nicht auf ICMP-Echo-Reqests antworten, sondern ein ICMP-Paket an den Absender generieren, wenn bei einem Paket die TLL (Hop-Count) bei Null ist. Da dieses Feld von jedem Router um 1 reduziert wird, bekommt man im Optimalfall von jedem Router mitgeteilt, wenn das Paket verworfen wird, weil die TTL 0 nicht. Daher schickt traceroute immer mit steigender TTL, so findet man alle Hops bis das Zielsystem auf das eigentliche Paket antwortet (z.B. beim echo-reqest mit dem echo-reply oder bei UDP mit Port unreachable).
Das ist unter anderem die Aufgabe eines Routers. Mehr dazu findet sich hier: https://datatracker.ietf.org/doc/html/rfc792

Ich habe bei einem ISP gearbeitet, der ICMP ebenfalls konsequent geblockt hat. Zumal es Angriffsszenarien gibt, die genau darauf aufbauen. Stichwort „Ping of death“

Ist ne ganz tolle Sache mit dem Sperren von ICMP. Da läuft nämlich Path MTU discovery drüber und wenn man dann die ICMP-Pakete blockiert funktioniert diese nicht mehr, manchmal klappt eine Kommunikation nicht mehr und es gibt Timeouts. Der Absender bekommt das sonst über ICMP mitgeteilt und kann die Paketgröße verringern.

Gibt es denn heute noch Systeme, die dafür anfällig sind?
Meines Wissens wurden die Bugs da alle gefixt.

Zitat von @117471:
Ich habe bei einem ISP gearbeitet, der ICMP ebenfalls konsequent geblockt hat. Zumal es Angriffsszenarien gibt, die genau darauf aufbauen. Stichwort „Ping of death“

Mal am Rande: Der "Ping of death" war ein Angriffsszenario, was mit JEDEM Paket möglich war, nicht nur ICMP-Echo. Mit letzterem war es nur viel einfacher möglich, weil der "ping"-Befehl unter Windows seinerzeit die fehlerhaften Pakete direkt generieren konnte und somit prinzipiell jeder die verwundbaren Systeme einfach mit Bordmitteln abschießen konnte. Klar, kannste Ping filtern um das zu "verhindern". Aber dann schickt mein Ich aus der Vergangenheit eben präparierte TCP- oder UDP-Pakete und schießt dein System darüber ab.

Naja, und wer ICMP pauschal dropped hat ICMP nicht verstanden

Warum man als MacBook Benutzer diesen Thread nun gerade in die "Microsoft" Rubrik stellt versteht wohl auch nur der TO selber. Aber egal...

Das MacBook nutzt im Default kein ICMP beim Traceroute sondern UDP Datagramme ! Sollte man als MacBook Benutzer aber auch wissen und kann man mit einem einfachen tcpdump auf dem Macbook selber verifizieren.

MacBook~ % sudo tcpdump -v host 8.8.8.8
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
16:38:05.407145 IP (tos 0x0, ttl 1, id 42144, offset 0, flags [none], proto UDP (17), length 52)
    192.168.1.178.42143 > dns.google.33435: UDP, length 24
16:38:05.417708 IP (tos 0x0, ttl 1, id 42145, offset 0, flags [none], proto UDP (17), length 52)
    192.168.1.178.42143 > dns.google.33436: UDP, length 24 

Mit "-I" Parameter im Traceroute Kommando:

MacBook~ % sudo tcpdump -v host 8.8.8.8
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
16:41:17.319360 IP (tos 0x0, ttl 1, id 42164, offset 0, flags [none], proto ICMP (1), length 72)
    192.168.1.178 > dns.google: ICMP echo request, id 42163, seq 1, length 52
16:41:17.328435 IP (tos 0x0, ttl 1, id 42165, offset 0, flags [none], proto ICMP (1), length 72)
    192.168.1.178 > dns.google: ICMP echo request, id 42163, seq 2, length 52 

Zudem haben viele Routerhops keine DNS Namen dann ist es hilfreich die DNS Auflösung auszuschalten was dann die Anzahl der Sternchen manchmal minimiert.
Auf dem MacBook dann: traceroute -n <Ziel>
Oder wenn man ICMP verwenden möchte: traceroute -n -I <Ziel> (großes i)

Hallo,

Zitat von @LordGurke:

Naja, und wer ICMP pauschal dropped hat ICMP nicht verstanden

Immerhin haben wir AOL, Compuserve und Co. abgelöst. So ganz erfolglos scheint das also nicht gewesen zu sein. Wobei ich sagen muss, dass ich mit der Technik nichts zu tun hatte. Ich hab' nur die Kunden abgewimmelt, die mit Fragen diesbezüglich genervt haben

Gruß,
Jörg

Zitat von @117471:

Hallo,

Zitat von @LordGurke:

Naja, und wer ICMP pauschal dropped hat ICMP nicht verstanden

Immerhin haben wir AOL, Compuserve und Co. abgelöst.

Also Teufel mit Beelzebub ausgetrieben. AOL und Compuserve wußten eh nie, was Internet ist und wie das funktioniert. Und der "Nachfolger" auch nicht.

lks

PS: Auch wenn die Baby-Bells irgendwann großer als der ursprünglich zerschlagene Konzern wurden, heißt das noch lange nicht, das sie Ahnung von der Technik hatten.