Hallo zusammen!
Jetzt wirds netzwerktechnisch.
TL;DR: Die FB 7490 (FritzOS 6.60) schickt ICMP-Pakete mit TTL 0 nach draußen, die sie mit "TTL Exceeded" beantworten müßte.
Habe gestern den Internetanbieter gewechselt und damit auf eine FB 7490 (FritzOS 6.60) an VDSL 50 MBit umgestellt. Vorher hatte ich eine 7272 mit zuletzt FritzOS 6.50 an ADSL2+ 10 MBit.
Der im folgenden beschriebene Effekt ist mir früher nie aufgefallen (und als Netzwerktechniker mache ich recht viel mit diesen Dingen), daher tippe ich auf einen Fehler in der 7490 6.60.
Bemerkt habe ich es in WinMTR, wo bei Traces als erster Hop (zusätzlich zum 2. Hop) nicht die IP der Fritzbox, sondern auch die des ISP-Gateways erschien, also das was nur in den 2. Hop gehört.
Nach etwas Experimentieren stellt es sich offenbar so dar: Für ca. 4 Sekunden, nachdem die FB ICMP-Pakete nach außen geleitet hat, schickt sie Pakete, die nicht für sie bestimmt sind, die aber TTL 1 haben, anstatt sie selbst mit "TTL exceeded" zu beantworten, trotzdem nach außen ans Gateway.
Beispiel:
Beim ersten Trace erscheint korrekterweise die FB-IP 10.0.0.25 als erster Hop. Beim zweiten Trace wurde das Paket für den 1. Hop nach draußen geschickt und vom Gateway beantwortet. Zwischen diesen beiden Traces habe ich 2 Sekunden gewartet. Warte ich >4 Sekunden, tritt der Fehlereffekt nicht auf.
Überprüft wurde dies mit Wireshark. TTL Exceeded-Antworten auf ICMP-Pakete enthalten jeweils eine Kopie des Requests. In der Antwort vom Gateway auf die Hop-1-Nachricht steht eine TTL von 0 in der Requestkopie, was nicht sein darf. Die FB hat also ein Paket mit TTL 0 nach draußen geschickt.
Interessant dabei: Lasse ich in der FB einen Packet Capture auf irgendeinem Interface mitlaufen, tritt dieser Effekt nicht auf und die FB beantwortet immer den 1. Hop!
Kann dies jemand nachvollziehen und/oder etwas damit anfangen?
Jetzt wirds netzwerktechnisch.
TL;DR: Die FB 7490 (FritzOS 6.60) schickt ICMP-Pakete mit TTL 0 nach draußen, die sie mit "TTL Exceeded" beantworten müßte.
Habe gestern den Internetanbieter gewechselt und damit auf eine FB 7490 (FritzOS 6.60) an VDSL 50 MBit umgestellt. Vorher hatte ich eine 7272 mit zuletzt FritzOS 6.50 an ADSL2+ 10 MBit.
Der im folgenden beschriebene Effekt ist mir früher nie aufgefallen (und als Netzwerktechniker mache ich recht viel mit diesen Dingen), daher tippe ich auf einen Fehler in der 7490 6.60.
Bemerkt habe ich es in WinMTR, wo bei Traces als erster Hop (zusätzlich zum 2. Hop) nicht die IP der Fritzbox, sondern auch die des ISP-Gateways erschien, also das was nur in den 2. Hop gehört.
Nach etwas Experimentieren stellt es sich offenbar so dar: Für ca. 4 Sekunden, nachdem die FB ICMP-Pakete nach außen geleitet hat, schickt sie Pakete, die nicht für sie bestimmt sind, die aber TTL 1 haben, anstatt sie selbst mit "TTL exceeded" zu beantworten, trotzdem nach außen ans Gateway.
Beispiel:
Code:
C:\Users\Frank>tracert -d google.de
Tracing route to google.de [216.58.205.227]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.0.0.25
2 19 ms 18 ms 19 ms 217.76.102.242
3 21 ms 35 ms 21 ms 217.76.99.113
4 21 ms 22 ms 22 ms 80.81.192.108
5 21 ms 22 ms 21 ms 64.233.174.255
6 21 ms 21 ms 21 ms 216.239.48.45
7 21 ms 21 ms 21 ms 216.58.205.227
Trace complete.
C:\Users\Frank>tracert -d google.de
Tracing route to google.de [216.58.205.227]
over a maximum of 30 hops:
1 18 ms 18 ms 19 ms 217.76.102.242
2 18 ms 18 ms 18 ms 217.76.102.242
3 21 ms 21 ms 21 ms 217.76.99.113
4 21 ms 21 ms 21 ms 80.81.192.108
5 21 ms 22 ms 21 ms 64.233.174.255
6 21 ms 21 ms 21 ms 216.239.48.45
7 21 ms 21 ms 21 ms 216.58.205.227
Trace complete.
Beim ersten Trace erscheint korrekterweise die FB-IP 10.0.0.25 als erster Hop. Beim zweiten Trace wurde das Paket für den 1. Hop nach draußen geschickt und vom Gateway beantwortet. Zwischen diesen beiden Traces habe ich 2 Sekunden gewartet. Warte ich >4 Sekunden, tritt der Fehlereffekt nicht auf.
Überprüft wurde dies mit Wireshark. TTL Exceeded-Antworten auf ICMP-Pakete enthalten jeweils eine Kopie des Requests. In der Antwort vom Gateway auf die Hop-1-Nachricht steht eine TTL von 0 in der Requestkopie, was nicht sein darf. Die FB hat also ein Paket mit TTL 0 nach draußen geschickt.
Interessant dabei: Lasse ich in der FB einen Packet Capture auf irgendeinem Interface mitlaufen, tritt dieser Effekt nicht auf und die FB beantwortet immer den 1. Hop!
Kann dies jemand nachvollziehen und/oder etwas damit anfangen?
Zuletzt bearbeitet: