Komisches Verhalten / paket loss / falsches routing?

someoneElse666

Lt. Junior Grade
Registriert
Aug. 2018
Beiträge
303
Hallo, ich hab eine Workstation, einen Laptop, einen Gaming PC und einen HTPC.
Alle funktionieren 1a, ausser der Gaming PC. Ich spiele PoE2 und verliere öfter mal die Verbindung.
Was auch ganz schräg ist, wenn ich google.de anpinge von meinem Gaming PC und das vergleiche mit dem Router, was der ausspuckt, sind das andere IPs 0o
Nicht immer, aber manchmal. Also dachte ich an ein DNS-Problem. Und Tatsache, ich habe irgendwann mal aus Verzweiflung 9.9.9.9 als DNS-Server eingetragen. Weil weiterhin Probleme bestanden, hab ich nun alles korrigiert, alles kommt via DHCP und eigentlich sollte das gehen... aber... tut nicht. Ich verlier immer wieder die Verbindung.
Vorhin hab ich mir gedacht, ich lass mal ein tracert auf google.de und schau was raus kommt, wo es denn so hakt, und ich fand es doch sehr spezill:

C:\Users\oli>tracert google.de

Routenverfolgung zu google.de [142.250.203.99]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms openwrt [192.168.1.1]
2 <1 ms <1 ms <1 ms 750sgl1.fiber7.init7.net [85.195.252.1]
3 1 ms 1 ms 1 ms r1stg7.core.init7.net [141.195.82.190]
4 1 ms 1 ms 1 ms r1stg2.core.init7.net [141.195.82.186]
5 2 ms 2 ms 2 ms r1wil2.core.init7.net [141.195.83.130]
6 2 ms 2 ms 2 ms r1win11.core.init7.net [5.180.135.88]
7 3 ms 2 ms 2 ms r1win12.core.init7.net [5.180.135.87]
8 3 ms 3 ms 3 ms r1zrh6.core.init7.net [5.180.135.52]
9 3 ms 3 ms 3 ms r1glb1.core.init7.net [82.197.168.223]
10 3 ms 3 ms 3 ms pni-google.init7.net [77.109.135.214]
11 * * * Zeitüberschreitung der Anforderung.
12 2 ms 2 ms 2 ms 142.251.70.187
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 ^C
Wenn ich mir das jetzt anschaue auf meinem Router, wo alles 1a funktioniert:
traceroute to google.de (142.250.203.99), 20 hops max, 46 byte packets
1 85.195.252.1 0.528 ms
2 141.195.82.190 1.212 ms
3 141.195.82.186 1.307 ms
4 141.195.83.130 1.909 ms
5 5.180.135.88 2.101 ms
6 5.180.135.87 2.346 ms
7 5.180.135.52 2.589 ms
8 82.197.168.223 2.668 ms
9 77.109.135.214 2.589 ms
10 *
11 172.253.50.2 3.384 ms
12 142.250.203.99 2.664 ms
Irgendwer eine Idee was da schief läuft?
Der einzige Unterschied zwischen Gaming-PC und allen anderen ist, dass der Gaming-PC via Wifi online geht.
Das kann doch nicht sein, dass das Routing von meinem ISP ein anderes ist, abhängig ob ich via Wifi ins Netz geh oder per Kabel 0o
 
Das sind die gleichen Hops (dies sich durchaus aendern koennen) nur das bei einem DNS Namen gezeigt werden. @someoneElse666
 
  • Gefällt mir
Reaktionen: JumpingCat und azereus
Was genau soll Dir der tracert nun als Resultat liefern bzw. was erhofft Du Dir als Rückschlüsse?
Und vorallem:
  • wo ist falsches Routing?
  • wo soll da Packet Loss sein?
 
  • Gefällt mir
Reaktionen: BFF und azereus
Ab 10) nicht mehr, da unterscheidet es sich und dann timed es aus, aber auf Seite des ISP (init7).
prian schrieb:
Was genau soll Dir der tracert nun als Resultat liefern
zu sehen wo es "hängen" bleibt

prian schrieb:
was erhofft Du Dir als Rückschlüsse?
Weitere Infos, an was es liegen könnte. Weil scheinbar liegt es ja nicht an mir. Das Verrückte an der Sache ist aber, wenn ich das Kabel an den Gaming-PC stecke, läufts einwandfrei. Kabel an Gaming-PC ist keine Lösung für mich. Auch der Laptop (Debian Trixie) hat keinerlei Probleme wenn der via WLan verbindet (gleiche Entfernung)
 
Dein Router wird quasi tracert -d machen. Sprich ohne namensauflösung. Kannst du ja mal von deinem Client versuchen. Das Ergebnis könnte dann wie in deinem Router aussehen.
 
  • Gefällt mir
Reaktionen: azereus und BFF
@someoneElse666
Die "Hängenbleiber" sind timeouts von einem Server zum nächsten Server, Du verfolgst hier eine gewählte Route und nicht die Pakete und deren Laufzeit. Die angegebene Zeit hat es einfach gedauert, darauf haben weder Du noch Dein Provider einen Einfluss so lange es nicht deren Netz ist.

Die Route ist seitens Deines Providers immer eigentlich gleich (ggf. kann per Lastverteilung auch mal eine andere Route genommen werden), jedenfalls ist egal ob intern LAN, WLAN oder Buschtrommeln genutzt werden, dem Provider ist das egal.

So sieht mein tracert z.B. aus (Dt. Telekom, Glasfaser):
Routenverfolgung zu google.de [142.250.181.227]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms fritz.box [192.168.1.1]
2 2 ms 2 ms 2 ms p3e9bf2ad.dip0.t-ipconnect.de [62.155.242.173]
3 4 ms 4 ms 4 ms m-ef1-i.M.DE.NET.DTAG.DE [62.153.181.70]
4 3 ms 3 ms 3 ms 72.14.194.156
5 4 ms 4 ms 4 ms 192.178.106.7
6 4 ms 4 ms 4 ms 192.178.106.14
7 5 ms 5 ms 4 ms 172.253.70.103
8 12 ms 11 ms 12 ms 142.250.235.28
9 19 ms 10 ms 10 ms 209.85.252.215
10 10 ms 10 ms 9 ms 192.178.109.217
11 10 ms 9 ms 10 ms 142.250.229.59
12 13 ms 13 ms 12 ms fra16s56-in-f3.1e100.net [142.250.181.227]

Ablaufverfolgung beendet.

Wenn Du mittels -w timeout die Zeit hochsetzt, dann kann u.U. diese Timeouts vermieden werden.
 
someoneElse666 schrieb:
zu sehen wo es "hängen" bleibt

Hier. Zwischen Bern und dem Uebergabepunkt zum Google-Universum.

1743948841467.png


Und wie bereits getippt. Hops koennen sich aendern wegen dynamischem Routing/Loadbalancing/etc. Und ein Hops muss nicht auf Ping anworten.
 
Du siehst die gleichen Hops bei beiden bis 9/10 was der Übergabepunkt zwischen deinem Provider init 7 und Google ist. (77.109.135.214 ist der PNI zur Google Cloud).
Hast du auf deinem OpenWRT eine public IP oder ein Netz?
Oder hast du ein providerseitiges NAT?
Interessant wäre jetzt eben, ob du in beiden Fällen (vom Rechner und vom Router) mit der gleichen Public IP rausgehst. Gibt es nur das 192.168.1.0 er LAN Netz auf deinem Router?
 
  • Gefällt mir
Reaktionen: prian und BFF
Seiten mit Load Balancing und CDN anzupingen bringt mal garnix.
Da kann es schon sein, dass du bei Anfrage 1 eine andere ZielIP bekommst als bei Anfrage 2.

Die beantworten dann auf DNS Ebene schon mit anderen IPs einfach um Regionen/Lasten zu verteilen.

Aber auch dein erster Tracert zeigt keine Probleme.
 
someoneElse666 schrieb:
Weil scheinbar liegt es ja nicht an mir. Das Verrückte an der Sache ist aber, wenn ich das Kabel an den Gaming-PC stecke, läufts einwandfrei.
Dein Spiel oder bloß dein trace? Nur weil dir ein Hop nicht antwortet oder nur langsam ist das noch lange kein Problem.
PoE hat schon ewig je nach Region immer mal wieder Probleme. Je nach Anbieter auch mal mehr, Telekom ist da z.B. absolut grottig, ggf. dein Provider da ähnlich. Da müsstest du aber aber dann PoE Server anpingen.
Ich spiel seit ewigkeiten mit Paris als Gateway, das läuft im Schnitt etwas besser als Frankfurt oder anderes Zeug in der nähe.
 
Ein anderer DNS hilft gar nichts.


Wenn dein Provider ein schlechtes Routing/Packet Loss hat, dann könnte dir ein (eigenes) VPN helfen. Oder du wechselst den Provider.

btw init7 ist mir persönlich auch schon mit Packet Loss in deren Netzwerken aufgefallen. Da kann man wahrscheinlich nichts machen. Wahrscheinlich bricht dann auch ein VPN zusammen wenn das Paket Loss hat.

Mit zum Beispiel winmtr könntest du das für längere Zeit messen wie stark der Paket Loss im Schnitt ist. Wenn du Docker hast, dann kannst du so was mit zum Beispiel https://oss.oetiker.ch/smokeping/ genauer untersuchen.

Aus Erfahrung: Das interessiert deinen Internetanbieter genau Null.
 
Wiesi21 schrieb:
Gibt es nur das 192.168.1.0 er LAN Netz auf deinem Router?
Ja. Alle Radios werden auf 192.168.1.x via DHCP versorgt. Die LAN-Geräte ebenso. Alles in der gleichen Firewall-Zone.
prian schrieb:
wo soll da Packet Loss sein?
Er leitet nicht weiter, darum muss ich den Prozess mit Ctrl+c abbrechen. Selbst wenn ich den timeout hochschraube.

Betroffen ist nicht nur das Spiel sondern auch Webseiten. Wenn ich bei so einer "Störung" einen Ping auf youtube.com ausführe, kommt direkt time out. Für mehrere Minuten. Danach gehts "plötzlich" wieder.
Ich habe aber keinerlei Probleme(!) wenn ich via Kabel online gehe. Null. Also verstehe ich nicht, wie irgendwas ausserhalb von meinem Router wissen soll, ob ich via Lan oder Wlan online bin. Noch verrückter ist, wenn ich den Laptop nebenbei laufen lasse mit dauer-ping auf youtube.com und dann diese Störungen an dem Gaming-PC habe, hat der Laptop 0 Probleme. Der Gaming pc kann dann aber nicht mehr pingen, da kommen die timeouts.
Ich habe eine semi-statische IP, die wechselt alle paar Jahre mal.

Wenn das tracert keine Probleme hat, dann sieht das absolut anders aus. Nämlich so:

C:\Users\oli>tracert google.de

Routenverfolgung zu google.de [142.250.203.99]
über maximal 30 Hops:

1 1 ms <1 ms <1 ms openwrt [192.168.1.1]
2 1 ms <1 ms <1 ms 750sgl1.fiber7.init7.net [85.195.252.1]
3 2 ms 1 ms 1 ms r1stg7.core.init7.net [141.195.82.190]
4 1 ms 1 ms 1 ms r1stg2.core.init7.net [141.195.82.186]
5 2 ms 2 ms 2 ms r1wil2.core.init7.net [141.195.83.130]
6 3 ms 2 ms 2 ms r1win11.core.init7.net [5.180.135.88]
7 3 ms 2 ms 2 ms r1win12.core.init7.net [5.180.135.87]
8 5 ms 3 ms 2 ms r1zrh6.core.init7.net [5.180.135.52]
9 4 ms * * r1glb1.core.init7.net [82.197.168.223]
10 3 ms 3 ms 3 ms pni-google.init7.net [77.109.135.214]
11 4 ms 3 ms 3 ms 172.253.50.233
12 3 ms 3 ms 2 ms 142.251.70.187
13 4 ms 2 ms 3 ms zrh04s16-in-f3.1e100.net [142.250.203.99]

Ablaufverfolgung beendet.
Ergänzung ()

Tulol schrieb:
Warum ausgerechnet?
Weil der in der Mitte im Zimmer steht und ich aus div. Gründen kein Kabel dauerhaft auf dem Boden liegen lassen kann.
 
someoneElse666 schrieb:
Noch verrückter ist, wenn ich den Laptop nebenbei laufen lasse mit dauer-ping auf youtube.com und dann diese Störungen an dem Gaming-PC habe, hat der Laptop 0 Probleme.

Eventuell eine extrem bescheidene WLAN Verbindung zusaetzlich.
Was Du mal machen kannst ist, den Netzwerkstack des PC vollstaendig zurueck zu setzen mit dem TCP Optimizer.
 
Würde es auch mal mit Netzwerk zurücksetzen probieren und schauen ob die Treiber aktuell sind.
Was fürn Chipsatz (Wifi/Lan) kommt da zum Einsatz ?
 
Ich hab keine Ahnung von Windows und Netzwerk-Tools, eigentlich bin ich Linuxer :>
Morgen sollte die Hardware für den neuen PC kommen, inkl. gescheiter Wifi-Karte.
Werd mal nach dem TCP Optimizer googlen und testen

Ich verwende so einen komischen USB-Wlan-Adapter, Comcast oderso heissen die. Toll ist das sicher nicht, ich erreich auch nur einen Bruchteil von dem, den ich eigentlich haben sollte (ca. 300mbit, habe eine symm. 10gbit Leitung). Zum Zocken hats immer gerreicht, drum hab ich da nie rumgemeckert. Aber mit den Störungen ist das echt ... Rotz. Der Router ist ein Banana Pi R4, da werkelt irgend eine MT-Karte drin. Kurz gegoogled, auf dem Router sollte das ein MT7995AV sein. Windows spuckt mir beim Wifi Adapter das hier aus: COMFAST WiFi6/6E USB Wireless adapter - im UI. lsusb/lspci kennt Windows scheinbar nicht und ich hab echt wenig Plan davon. Hab ihn gefunden: https://de.aliexpress.com/item/1005004709640350.html - CF952-AX
 
Zuletzt bearbeitet:
@someoneElse666
Du setzt also offensichtlichen Netzwerk-Rotz ein und beschäftigst uns mit dem ganzen Mist auch noch?
Nimm ein LAN-Kabel und Du bist jegliche Strörungseinflüsse los die WLAN haben kann, und das sind viele.

Du hast auch in #4 (von Dir) doch auch explizit geschrieben dass es mit LAN am PC nicht auftritt und es m.E. klar sein müsste, dass entweder das WLAN etwas wackelig ist bei Dir (Du schreibst ja nichts dazu, sondern stellst einfach eine Wolke in den Raum in dem WLAN beteitligt ist) oder die verwendete Hardware am PC im optimalen Fall Mist, vermutlich aber eher Schei** ist.

Ich bin hier jedenfalls RAUS!
 
  • Gefällt mir
Reaktionen: BFF, JumpingCat und redjack1000
Also die USB WLAN Adapter kannst du unter Linux/BSD wirklich weitgehend vergessen. Wenn du soetwas betreiben willst/musst nimm einen mini PC mit x86 CPU plus intel Wifi Adapter - da rennen Open WRT/OPNSense und Konsorten problemlos. Mit ARM und gerade Mediatek Wifi Chipsätzen unter Linux ist Client Betrieb schon problematisch (wenn man loss/latency kritische Dinge damit macht) und AP Betrieb sicher nicht problemlos möglich.
Selbst LAN Router Betrieb würde ich weitestgehend nur mit Intel Ethernet Chipsätzen als langfristig unproblematisch einstufen.
 
Wiesi21 schrieb:
Also die USB WLAN Adapter kannst du unter Linux/BSD wirklich weitgehend vergessen.
Ja ich weis, aber wie gesagt, das erklärt nicht wieso tracert erst lange nach meinem Router sagt, die Hops seien nicht erreichbar/timeouten. Weil bis zum Router hab ich auch im Störfall eine ausreichend gute Verbindung. Der eine tracert war im Störfall.
 
Zurück
Oben