Skip to main content
Warum O2
Warenkorb
 Service

Hi. Seit Monaten “plagt” mich ein Problem, dass IPv6 Verbindungen zu manchen Adressen nicht, bzw nur nach mehrmaligem Probieren hergestellt werden können. Das ganze kommt erst jetzt in meinem Urlaub richtig zum tragen. 😅

So sind z.b. 50% der Versuche hin zu ‘mirror.osbeck.com ohne Erfolg (hier ein Test mittels curl)

LANG=C curl -I -v mirror.osbeck.com
* Host mirror.osbeck.com:80 was resolved.
* IPv6: 2606:4700:20::6819:5f05, 2606:4700:20::ac43:6136, 2606:4700:20::6819:5e05
* IPv4: 104.25.95.5, 172.67.97.54, 104.25.94.5
*   Trying  2606:4700:20::6819:5f05]:80...
* Connected to mirror.osbeck.com () port 80
> HEAD / HTTP/1.1
> Host: mirror.osbeck.com
> User-Agent: curl/8.10.0
> Accept: */*
> 
* Request completely sent off
* Recv failure: Connection reset by peer
* closing connection #0
curl: (56) Recv failure: Connection reset by peer

Noch viel häufiger ist es hin zu *.gnome.org, wo ich kaum mal eine Verbindung durch bekomme, was jedoch ein Projekt ist mit dem ich zusammen arbeite (oder gerne würde, ist bei der Verbindung schlecht möglich)

LANG=C curl -I -v gnome.org
* Host gnome.org:80 was resolved.
* IPv6: 2a04:4e42:600::347, 2a04:4e42:200::347, 2a04:4e42::347, 2a04:4e42:400::347
* IPv4: 151.101.1.91, 151.101.65.91, 151.101.129.91, 151.101.193.91
*   Trying /2a04:4e42:600::347]:80...
* Connected to gnome.org () port 80
> HEAD / HTTP/1.1
> Host: gnome.org
> User-Agent: curl/8.10.0
> Accept: */*
> 
* Request completely sent off
* Recv failure: Connection reset by peer
* closing connection #0
curl: (56) Recv failure: Connection reset by peer

gitlab

LANG=C curl -I -v gitlab.org
* Host gitlab.org:80 was resolved.
* IPv6: 2a06:98c1:3120::3, 2a06:98c1:3121::3
* IPv4: 188.114.97.3, 188.114.96.3
*   Trying /2a06:98c1:3120::3]:80...
* Connected to gitlab.org (2a06:98c1:3120::3) port 80
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: gitlab.org
> User-Agent: curl/8.10.1
> Accept: */*
> 
* Request completely sent off
* Recv failure: Connection reset by peer
* closing connection #0
curl: (56) Recv failure: Connection reset by peer

Ich habe eine ‘FRITZ!Box 7530 AX’ und diese über die Monate mehrmals neu gestartet, neue Firmware. Das gab keinen (auch nicht temporären) Erfolg. Das Problem besteht nur über IPv6 und auch nicht bei jeder Adresse aber doch bei sehr vielen die ich verwende.

 

Leider bin ich ratlos was ich noch machen kann. Es besteht sowohl auf meinen 3 Arch Linux System, als auch auf den 2 Windows (Wobei ich Windows weniger für git-related Dinge benutze und darum eher selten diese Adressen aufrufe.)

Hmmm… also die Ziele die du hier auflistest kann ich problemlos aufrufen, zumindest über mein Browser, kann also das Problem nicht nachstellen.

Aber dein Problem klingt ähnlich/passend zu dem Thread:

Zumindest ein paar der angegebene Ziele lösen IPv6 Adressen auf, die laut ipinfo.io bei Cloudflare sind.

@almightyloaf Dein Browser hat Methoden das zu umgehen, selbst wenn das auftritt. Das sind einmal der Rückfall auf IPv4 und aber auch einfach neu probieren eines Verbindungsaufbaus. Daher ist der Browser weniger ein Problem. Es fällt eher auf mit git, oder aber Einzelverbindungen mittels curl wie oben gezeigt. eine hohe Prozentanzahl nicht durch geht.

Das wirkt jetzt eventuell nicht tragisch, aber wenn du damit arbeiten musst und bei deiner Abfrage über den Versionsstand das hier sieht:

Summary
 ✓ Up-to-date: 18
 x Failure: 39
 ! Out-of-date: 9

Wobei die Failures eben besagte Verbindungsprobleme sind, dann ist damit nicht zu arbeiten.

@almightyloaf Dein Browser hat Methoden das zu umgehen, selbst wenn das auftritt. Das sind einmal der Rückfall auf IPv4 und aber auch einfach neu probieren eines Verbindungsaufbaus. Daher ist der Browser weniger ein Problem.

Das ist durchaus richtig.

Das wirkt jetzt eventuell nicht tragisch, aber wenn du damit arbeiten musst t...]

Egal ob man damit arbeiten muss, will oder auch nicht, IPv6 sollte funktionieren, ich bin da bei dir.

Hast du dir den anderen Thread angesehen, ist es das gleiche Problem? Dann würde ich empfehlen dich dort (auch) zu melden, damit sich o2 das ansehen kann.

Oder sehe ich etwas falsch und die zwei Themen sind andere Welten?

@almightyloaf Bin am lesen. Danke für den Link :)

Hast du mal geschaut, ob du wirklich IPv6 von o2 bekommst?

 

Und nicht versehentlich über 6to4?

@almightyloaf Dein Browser hat Methoden das zu umgehen, selbst wenn das auftritt. Das sind einmal der Rückfall auf IPv4 und aber auch einfach neu probieren eines Verbindungsaufbaus. Daher ist der Browser weniger ein Problem. Es fällt eher auf mit git, oder aber Einzelverbindungen mittels curl wie oben gezeigt. eine hohe Prozentanzahl nicht durch geht.

Bin vermutlich von dem gleichen Problem geplagt.  Bezüglich “Browser hat Methoden das zu umgehen”: in diesem speziellen Fall greifen die üblichen Browser-internen Fallbackmethoden nicht.

Die IPv6 Verbindung scheitert nämlich erst relativ spät, an einem von der Gegenseite zurückgesendeten RST paket (siehe z.B. curl-Fehlermeldung curl: (56) Recv failure: Connection reset by peer).

Das ist nicht die Art von Fehler, wo der Browser einfach einen Fallback auf IPv4 macht, oder das ganze neu versucht. Die TCP Verbindung kommt initial ja zustande, und wird erst, nachdem bereits ein paar Bytes Daten ausgetauscht wurden, von der Gegenseite wieder geschlossen (in diesem Thread gibt’s ein paar detailliertere Analysen zu wahrscheinlich dem gleichen Problem). Das RST Paket hat auch als Absenderadresse die IP-Adresse des Servers. Aus Browser-Sicht ist das kein Verbindungsproblem, sondern ein expliziter Wunsch des Webservers, der sagt “ich kann nicht, lass mich in Ruhe”, da macht der Browser dann keinen zweiten Versuch.

Gut möglich, dass das RST Paket von einer  Middlebox im O2 oder cloudflare-Netz kommt, und gar nicht vom Webserver selbst gesendet wurde (d.h. die Midddlebox hat da eine fremde Source-IP benutzt und den Webserver impersoniert).  Das kann der Browser aber nicht wissen.  Falls das von einer Middlebox kommt, dann heißt sowas offenbar "forged TCP reset".  Üblicherweise von “network security systems” eingesetzt um z.B. automatisch DoS Angriffe abzuwehren.

 

Ich habe mal je URL (mirror.osbeck.com, gnome.org, gitlab.org) 10 Anfragen über cURL gesendet, dürfte bei 50% Fehlerquote ausreichend viele versuche sein.

Jedoch ist das Problem “hier” nicht nachstellbar, es wird sich bei allen Versuchen erfolgreich verbunden, über IPv6. “Hier” ist nördlicheres BaWü.

Muss also regional sein. Zufällig in der “nähe” Berlins? Das war ja beim anderen Thread eher auch die Richtung.

Zufällig in der “nähe” Berlins?

Südliches Sachsen-Anhalt. Also nicht direkt Nähe, aber eventuell nahe genug. Danke fürs rein schauen!

Suedliches Niedersachsen, meist keine Probleme. Wenn Probleme dann wegen Problemen mit der IPv6 Praefix-Delgation von O2 die seit einigen Monaten immer mal wieder aufmuckt… aber das betrifft dann die gesamte IPv6 Konnektivitaet und hat nichts mit unerwarteten RSTs zu tun.

Liebe Gemeinde,

vielen Dank für den Beitrag. Ich habe das gleiche Problem und war mir nicht sicher, ob es an meiner Installation oder an meinem Provider liegt.

Ich habe einige Tests gemacht:
- Ich habe versucht, meinen Mobilfunkanbieter zu verwenden und habe keine Probleme beim Zugriff auf Websites.
- Ich habe IPv6 an meinem Router deaktiviert und das Problem ist verschwunden.

Es handelt sich also eindeutig um ein Problem mit dem IPv6-Protokoll von O2.

LG
Rust
 

Ich habe einige Tests gemacht:
- Ich habe versucht, meinen Mobilfunkanbieter zu verwenden und habe keine Probleme beim Zugriff auf Websites.
- Ich habe IPv6 an meinem Router deaktiviert und das Problem ist verschwunden.

Es handelt sich also eindeutig um ein Problem mit dem IPv6-Protokoll von O2.

Wenn es sich auch um Webseiten die über Anycast erreicht werden, und das Problem eben auch genau das ist, was hier besprochen wird (ich denke erstmal ja, wobei es ja dann drauf an kommt welche Seiten gemeint sind, du hast “nur” “einige Tests” ohne näheren Angaben gemacht) würde ich dir empfehlen dich auch beim unten genannten Thread mit anzuschliessen um den Impact sichtbarer zu machen.

Wobei der Anbieter an der Stelle auch nicht unbedingt “Schuld” sein muss, wie es dort auch beschrieben ist (und natürlich sofern die Aussage stimmt).

Guten Morgen @almightyloaf, @amureki & @fabiscafe,

ich bin in der Thematik wirklich nicht gut. Ihr unterstützt & helft euch sehr gut gegenseitig 💙

Gibt es da schon Neuigkeiten bei euch?

Liebe Grüße

Kathi 🍁

Deine Antwort


Allgemeine Nutzungsbedingungen der O₂ Community
© Telefónica Germany GmbH & Co. OHG Telefónica