Unitymedia Fritzbox 6490: Seiten laden nicht immer richtig

[Andreas1969]

[ironie]
Der Abend ist gerettet
[/ironie]
Im Ernst, Danke erstmal, irgendjemand muss das doch loesen koennen? Oder kann ich mit der Diagnose fristlos kuendigen?

Fristlos kündigen kannst Du wohl mit der Diagnose nicht.
Hatte mich ein halbes Jahr mit dieser Scheiss.. rumgeärgert, UM Hotline, Technikabteilung, AVM usw...
Letztendlich hab ich aufgegeben und bin auf die Providerbox zurück. Seitdem läuft der Anschluß wieder.

 

[aydind]

[ironie]
Der Abend ist gerettet
[/ironie]
Im Ernst, Danke erstmal, irgendjemand muss das doch loesen koennen? Oder kann ich mit der Diagnose fristlos kuendigen?

Fristlos kündigen kannst Du wohl mit der Diagnose nicht.
Hatte mich ein halbes Jahr mit dieser [zensiert].. rumgeärgert, UM Hotline, Technikabteilung, AVM usw...
Letztendlich hab ich aufgegeben und bin auf die Providerbox zurück. Seitdem läuft der Anschluß wieder.

Ok, dann kann ich mit meinen 3-4 Wochen rumaergern also gluecklich schaetzen.
Ich probiers morgen zwar mit der Hotline, aber hab schon mal ein normales DECT Telefon bestellt und
werde dann wohl auch zurueck auf die Connectbox. Kuendigen tu ich auf jeden Fall schon mal. Habe in
den 6-7 Monaten mehr Aerger gehabt als in 6-7 Jahren normales DSL davor. :/

DANKE an alle, die geholfen haben. Ich melde mich dann, wenns Updates geben sollte.

 

[Andreas1969]

Vermutlich wird der Ärger, wenn Du auf die ConnectBox zurückwechselst noch größer.
Internet läuft zwar dann wieder, aber die Telefonie wird dann nicht mehr funktionieren, da UM die Daten hierfür nicht in die ConnectBox einträgt, Du kannst sie bei der ConnectBox ja nicht selbst eintragen. Dafür stehen die SIP Creditials aber weiterhin im Kundencenter.
Wenn Du ein SIP Telefon hast, kannst Du sie ja dort eintragen. Hast Du keins, ha'ste schlechte Karten.

 

[Andreas1969]

Wenn ich jetzt richtig liege, was ich mittlerweile glaube, wird es demnächst noch viel mehr Leute treffen und zwar nach folgendem Schema:
1. KUNDE hatte vor dem Wechsel auf eigene Fritzbox den WifiSpot aktiviert
2. Wechsel auf eigene Fritzbox
3. FW Update der Fritzbox auf OS 6.85
4. Die Probleme treten seit dem Update auf 6.85 auf

 

[aydind]

Vermutlich wird der Ärger, wenn Du auf die ConnectBox zurückwechselst noch größer.
Internet läuft zwar dann wieder, aber die Telefonie wird dann nicht mehr funktionieren, da UM die Daten hierfür nicht in die ConnectBox einträgt, Du kannst sie bei der ConnectBox ja nicht selbst eintragen. Dafür stehen die SIP Creditials aber weiterhin im Kundencenter.
Wenn Du ein SIP Telefon hast, kannst Du sie ja dort eintragen. Hast Du keins, ha'ste schlechte Karten.

Mmh, aber du bist ja auch zurueckgewechsel, oder nutzt du ein SIP Telefon?
Auf jeden Fall guter Hinweis, werd ich der Hotline sagen, und ehrlich gesagt, wenn sie es nicht machen,
hab ich einen guten Grund, evtl. Stunk zu machen, und irgendwelche Fristen zu setzen, denn die Einstellungen
in der Connectbox sollten ja dann nicht mehr meine Verantwortung sein.
Naja, schauen wir mal, was die Support-Mitarbeiter dazu sagen, der letzte war auf jeden Fall recht nett.

 

[Andreas1969]

Mmh, aber du bist ja auch zurueckgewechsel, oder nutzt du ein SIP Telefon?

Ja, ich bin zurückgewechselt, aber auf eine 6490, da ich Telefon Komfort Kunde bin.
Hinter der 6490 betreibe ich eine 7580, wo auch die SIP Creditials eingetragen sind.
Und ich habe auch mal versucht, die SIP Creditials in der 6490 einzutragen, das hatte auch kurzfristig funktioniert, nur waren die über Nacht wieder aus der Providerbox verschwunden. :wand:

 

[Andreas1969]

Mmh, aber du bist ja auch zurueckgewechsel, oder nutzt du ein SIP Telefon?

Ja, ich bin zurückgewechselt, aber auf eine 6490, da ich Telefon Komfort Kunde bin.
Hinter der 6490 betreibe ich eine 7580, wo auch die SIP Creditials eingetragen sind.
Und ich habe auch mal versucht, die SIP Creditials in der 6490 einzutragen, das hatte auch kurzfristig funktioniert, nur waren die über Nacht wieder aus der Providerbox verschwunden. :wand:

PS: Was machst Du jetzt mit der 6490 :kratz:
Die müsstest Du eigentlich Unitymedia wegen Unfähigkeit in Rechnung stellen :streber:

 

[tq1199]

Die Fritzbox gibt mir hier nichts aus:

<i>
</i>$ host -t A dns 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
dns.fritz.box has no A record

Wie ist die Ausgabe von:

<i>
</i>host -t AAAA dns 192.168.1.1

?

Evtl. verwendet deine FritzBox, als vom ISP zugewiesene DNS-Server, _nur_ v6-DNS-Server. Denn über IPv6 und die v6-DNS-Server kann ja auch v4-Namensauflösung gemacht werden. Z. B.:

<i>
</i>:~ $ dig -6 a heise.de +short @2620:0:ccd::2
193.99.144.80

EDIT:

Lt. diesem Thread https://forum.ubuntuusers.de/topic/ddclient-mit-dynv6-einrichten/3/ hat der TE auch eine _eigene_ FB6490 mit der FW Fritz-OS 06.85 bei Unitymedia. Mit:

<i>
</i>host -t A dns <IP-Adresse-FB>

<i>
</i>host -t AAAA dns <IP-Adresse-FB>

werden bei ihm sowohl die v4- als auch die v6-DNS-Server der FB, gezeigt.

 

[Andreas1969]

Naja, schauen wir mal, was die Support-Mitarbeiter dazu sagen, der letzte war auf jeden Fall recht nett.

Die verstehen nur "Bahnhof" Das wird nichts bringen.

 

[aydind]

Naja, schauen wir mal, was die Support-Mitarbeiter dazu sagen, der letzte war auf jeden Fall recht nett.

Die verstehen nur "Bahnhof" Das wird nichts bringen.

Du hast 100% recht, aber probieren muss ichs. Das wirkt dann im fiesen Kuendigungsschreiben (das dann auch
niemanden interessieren wird) echter, wenn ich noch negative Supporterfahrungen anfuehren kann.

 

[aydind]

Wie ist die Ausgabe von:

<i>
</i>host -t AAAA dns 192.168.1.1

?

Evtl. verwendet deine FritzBox, als vom ISP zugewiesene DNS-Server, _nur_ v6-DNS-Server. Denn über IPv6 und die v6-DNS-Server kann ja auch v4-Namensauflösung gemacht werden. Z. B.:

<i>
</i>:~ $ dig -6 a heise.de +short @2620:0:ccd::2
193.99.144.80

EDIT:

Lt. diesem Thread https://forum.ubuntuusers.de/topic/ddclient-mit-dynv6-einrichten/3/ hat der TE auch eine _eigene_ FB6490 mit der FW Fritz-OS 06.85 bei Unitymedia. Mit:

<i>
</i>host -t A dns <IP-Adresse-FB>

<i>
</i>host -t AAAA dns <IP-Adresse-FB>

werden bei ihm sowohl die v4- als auch die v6-DNS-Server der FB, gezeigt.

Bei mir nicht:

<i>
</i>aydin@red:~/mp3$ host -t A dns 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
dns has no A record
aydin@red:~/mp3$ host -t AAAA dns 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
dns has IPv6 address 2a02:908:2:a::1
dns has IPv6 address 2a02:908:2:b::1

hab jetzt alles auf automaitsch Beziehen zurueckgestellt in der Box.
Wenn ich IPv4 DNS Server manuell eintrage, aendert sich an der Aussage oben nichts..

 

[tq1199]

Bei mir nicht:

<i>
</i>aydin@red:~/mp3$ host -t A dns 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
dns has no A record
aydin@red:~/mp3$ host -t AAAA dns 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
dns has IPv6 address 2a02:908:2:a::1
dns has IPv6 address 2a02:908:2:b::1

hab jetzt alles auf automaitsch Beziehen zurueckgestellt in der Box.
Wenn ich IPv4 DNS Server manuell eintrage, aendert sich an der Aussage oben nichts..

Evtl. von deiner FB6490 auch eine support-Datei erstellen und dort nachschauen, ob diese Datei, vom ISP zugewiesene v4-DNS-Server beinhaltet.

Evtl. geht bei deiner FB die v4-Namensauflösung nur über diese v6-DNS-Server:

<i>
</i>dns has IPv6 address 2a02:908:2:a::1
dns has IPv6 address 2a02:908:2:b::1

was zu den Problemen führen kann.

Versuch mal:

<i>
</i>dig -6 a heise.de +short @2a02:908:2:a::1
dig -6 a heise.de +short @2a02:908:2:b::1
dig +tcp -6 a heise.de +short @2a02:908:2:b::1
nc6 -zv -6 2a02:908:2:a::1 53

auf deinem Ubuntu-PC.

 

[tq1199]

Hier ein weiteres Beispiel, dass UM Probleme mit dem DNS-Traffic hat.

Heute morgen geht hier mit meiner FB, die Telefonie nicht (... wegen DNS?). Z. B.:

<i>
</i>19.11.17 09:38:32	Internettelefonie mit 0711######@hiq4a-sbc3a.kabelbw-mta.de über hiq4a-sbc3a.kabelbw-mta.de war nicht erfolgreich. Ursache: Internal Server Error (500) [3 Meldungen seit 19.11.17 09:35:25]

Die Namensauflösung am UM-Anschluss:

<i>
</i>:~$ host -t A hiq4a-sbc3a.kabelbw-mta.de
Host hiq4a-sbc3a.kabelbw-mta.de not found: 3(NXDOMAIN)

<i>
</i>:~$ host -t A hiq4a-sbc3a.kabelbw-mta.de 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
Host hiq4a-sbc3a.kabelbw-mta.de not found: 3(NXDOMAIN)

Die Namensauflösung am Telekom-Anschluss:

<i>
</i># nslookup hiq4a-sbc3a.kabelbw-mta.de
Server: 217.0.43.145
Address 1: 217.0.43.145 ul-nxr-a01.isp.t-ipnet.de
Name: hiq4a-sbc3a.kabelbw-mta.de
Address 1: 62.138.238.45
Address 2: 62.138.239.45

<i>
</i># nslookup hiq4a-sbc3a.kabelbw-mta.de 8.8.8.8
Server: 8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com
Name: hiq4a-sbc3a.kabelbw-mta.de
Address 1: 62.138.239.45
Address 2: 62.138.238.45

Lt. whois gehören die IP-Adressen:

<i>
</i>...
address: Plusserver
address: Welserstrasse 14
address: 51149 Koeln
address: Germany
phone: +49 2203 1045 0
...

 

[addicted]

Die 81.210.176.62 scheint ein System in Bochum zu sein. Hängt laut einem traceroute direkt am Backbone, das ist etwas merkwürdig. Der RDNS sieht aber aus wie eine Kunden-IP.

Hast Du mal ein traceroute von Dir nach irgendwo ausserhalb des UM-Netzes?

 

[tq1199]

Die 81.210.176.62 scheint ein System in Bochum zu sein. Hängt laut einem traceroute direkt am Backbone, das ist etwas merkwürdig. Der RDNS sieht aber aus wie eine Kunden-IP.

Hast Du mal ein traceroute von Dir nach irgendwo ausserhalb des UM-Netzes?

Hat er doch schon einige gemacht. Das ist sein gateway. Siehe seine Beiträge auf Seite 2. Z. B.:

<i>
</i>HOST: red Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 1 2.3 2.3 2.3 2.3 0.0 2.|-- 81.210.176.62 0.0% 1 61.6 61.6 61.6 61.6 0.0 3.|-- 81.210.176.61 0.0% 1 37.8 37.8 37.8 37.8 0.0 4.|-- 84.116.132.178 0.0% 1 25.8 25.8 25.8 25.8 0.0 5.|-- 213.46.177.42 0.0% 1 22.3 22.3 22.3 22.3 0.0 6.|-- 108.170.251.129 0.0% 1 24.6 24.6 24.6 24.6 0.0 7.|-- 209.85.248.157 0.0% 1 31.3 31.3 31.3 31.3 0.0 8.|-- 8.8.8.8 0.0% 1 34.4 34.4 34.4 34.4 0.0

 

[addicted]

Uh, hatte ich übersehen. Vielen Dank.

Dann läuft er da scheinbar wirklich in eine Policy-Beschränkung. Hätte ich nicht gedacht. Ich kann irgendwie auch nicht glauben, dass das wirklich so sein soll :/.

 

[tq1199]

HSTS wird für de.yahoo.com gesendet.

Ja, aber nur bei DS-lite (... und IPv6 statt IPv4, auch nur bei DS-lite) und nicht bei DS.

 

[addicted]

Auf v4 und v6:

<i>
</i>user@vm ~ $ touch .wget-hsts && chmod -w .wget-hsts
user@vm ~ $ wget -S -O/dev/null -6 de.yahoo.com 2>&1 | grep Strict-Transport Strict-Transport-Security: max-age=2592000
user@vm ~ $ wget -S -O/dev/null -4 de.yahoo.com 2>&1 | grep Strict-Transport Strict-Transport-Security: max-age=2592000

 

[tq1199]

Auf v4 und v6:

<i>
</i>user@vm ~ $ touch .wget-hsts && chmod -w .wget-hsts
user@vm ~ $ wget -S -O/dev/null -6 de.yahoo.com 2>&1 | grep Strict-Transport Strict-Transport-Security: max-age=2592000
user@vm ~ $ wget -S -O/dev/null -4 de.yahoo.com 2>&1 | grep Strict-Transport Strict-Transport-Security: max-age=2592000

Es geht ja nicht darum, was man mit dem Client (hier wget) bzw. lokal "erzwingen" kann, sondern darum was der Server in Abhängigkeit vom Internetanschluss (natives IPv4/DS-lite/DS) bzgl. HSTS(/v6/v4) macht.

 

[addicted]

HSTS beeinflusst nur den Client. Der Server sendet den Header auf v4 und v6.

Was genau meinst Du denn jetzt? Schreib doch vielleicht mal mehr als nur einen Satz, damit ich verstehe worum es Dir geht und wir das Thema in 2-3 Beiträgen abschließen können.

 

[tq1199]

HSTS beeinflusst nur den Client. Der Server sendet den Header auf v4 und v6.

Genau das meine ich, nur _den_ Client. D. h. der "normale" Client (... der das in d. R. gar nicht mitbekommt) an einem _DS-lite-Anschluss_ hat erstmal gar keinen Einfluss darauf, was der Server betr. HSTS bzw. betr. v4 und v6 macht. Er muss das "nehmen" was er vom Server bekommt.
Die wenigsten werden ein wget mit "-4" starten.

Schreib doch vielleicht mal mehr als nur einen Satz, damit ich verstehe worum es Dir geht ...

Naja, Du hast ja in deinem vorletzten Beitrag, nicht einmal _einen_ Satz geschrieben. Ich wusste ja auch nicht so genau was Du mit deinem vorletzten Beitrag meinst.

 

[addicted]

Du hast natürlich recht, meine Antworten waren auch knapp.

Ich bin noch immer nicht sicher, worauf Du hinaus willst, daher versuche ich mal zu rekapitulieren:

Das war aber auch ein schlechtes Beispiel, denn mit/wegen deiner for-Schleife hat der "HSTS policy"-Schutzmechanismus zugeschlagen und auf den Port 443 (HTTPS) verschoben/verwiesen, der aber nur mit der IPv6-Adresse und nicht mit der IPv4-Adresse, erreichbar ist:

<i>
</i>:~$ nc -zv 77.238.184.150 80
Connection to 77.238.184.150 80 port [tcp/http] succeeded!

<i>
</i>Starting Nmap 6.40 ( http://nmap.org ) at 2017-11-18 15:22 CET
Nmap scan report for w2.src.vip.ir2.yahoo.com (77.238.184.150)
Host is up (0.037s latency).
PORT STATE SERVICE
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 0.85 seconds

<i>
</i>:~ $ nc6 -zv -6 2a00:1288:110:2::3007 443
nc6: media-router-fp1.prod.media.vip.ir2.yahoo.com (2a00:1288:110:2::3007) 443 [https] open

Du zeigst in diesem Beitrag angeblich, dass die HSTS-Policy einen Einfluss hatte, weil unter der IP-Adresse 77.238.184.150 der Port 443 nicht offen ist.
Weil der Port auf der IP-Adresse 2a00:1288:110:2::3007 offen ist, siehst Du eine irgendwie geartete Verschiebung auf IPv6.

Ich wiederspreche Dir:

www.yahoo.de und de.yahoo.com sind unterschiedlichen Adressen. HSTS wird für de.yahoo.com gesendet.

Ich ging davon aus, dass Dir bewusst wird, wo der Fehler ist:
Der erste HTTP-Request (Port 80) geht zu www.yahoo.de
- dieser hat kein HSTS (was bei HTTP auch keinen Sinn ergäbe)
- dieser ist nur per v4 erreichbar (77.238.184.150)
- dieser leitet weiter zu de.yahoo.com
Erst der zweite Request zu de.yahoo.com ist jedoch derjenige, auf den es ankommt:
- er wird über HTTPS aufgerufen und die Antwort enthält einen HSTS-Header
- der Host ist über v4 und v6 verfügbar, aber nicht unter 77.238.184.150

HSTS hat daher nichts mit der IP-Adresse 77.238.184.150 zu tun. Deshalb ist es unerheblich, ob dort Port 443 offen ist.
Es ist aber relevant, dass die abgeweisene Verbindung auf v4 erfolgt, diesen Aspekt hast Du richtig erkannt, auch wenn das nichts mit HSTS zu tun hatte.
Der Test hätte idealerweise mit der URL https://de.yahoo.com für v4 und v6 getrennt wiederholt werden müssen.

Jetzt hab ich meiner Meinung nach alles ausführlich erklärt. Normalerweise spare ich mir das, wenn ich annehme, dass mein Gegenüber genug Fachwissen hat, um meine Antwort auch ohne die längere Erläuterung zu verstehen. Davon gehe ich z.B. aus, wenn jemand -wie Du z.B.- regelmäßig Linux-Tools wie nc oder nmap verwendet.

 

[tq1199]

Du zeigst in diesem Beitrag angeblich, dass die HSTS-Policy einen Einfluss hatte, weil unter der IP-Adresse 77.238.184.150 der Port 443 nicht offen ist.

Nein, darum geht es mir nicht, denn das wechseln von der IP-Adresse 77.238.184.150 zu http://de.yahoo.com erfolgt in allen Fällen (DS-lite, DS, IPv4) mit einem "301 Moved Permanently"-Hinweis.

Mir geht es um das Verhalten nach dieser Umleitung, mit dem "301 Moved Permanently"-Hinweis.

Bei DS-lite ist HSTS anscheinend erforderlich, während bei DS und nativem IPv4 das nicht erforderlich ist. Es wird für den Wechsel vom Port 80 auf den Port 443, auch mit einem "301 Moved Permanently"-Hinweis gemacht.

Beim DS-lite wird zusätzlich nicht mehr IPv4 für die Datenübertragung verwendet, sondern IPv6. Bei DS bleibt es beim IPv4 für die Datenübertragung, obwohl IPv6 auch vorhanden wäre bzw. vorhanden ist.

 

[addicted]

Beim DS-lite wird zusätzlich nicht mehr IPv4 für die Datenübertragung verwendet, sondern IPv6. Bei DS bleibt es beim IPv4 für die Datenübertragung, obwohl IPv6 auch vorhanden wäre bzw. vorhanden ist.

Woran siehst Du das? Ich bin den Thread nochmal durchgegangen, kann aber keinen Beitrag finden, aus dem ich das erkennen kann.

Interessant fand ich aber das hier, was ich auch schonmal überlesen habe:

<i>
</i>:~ $ nc6 -zv -6 2a00:1288:110:2::3007 443
nc6: media-router-fp1.prod.media.vip.ir2.yahoo.com (2a00:1288:110:2::3007) 443 [https] open

Das wiederum macht in meiner sleep 1 Schleife gar keine Probleme.
Connection succeeded immer...

Vorher hatter er nc für v4 versucht und dabei in der Schleife einige "fehlende Routen".
Dass es mit v6 durchgehend geht und mit v4 nicht, lässt für mich nur den Schluss zu, dass es ein Limit am AFTR (oder einem zugehörigen Router) gibt.

 

[tq1199]

Beim DS-lite wird zusätzlich nicht mehr IPv4 für die Datenübertragung verwendet, sondern IPv6. Bei DS bleibt es beim IPv4 für die Datenübertragung, obwohl IPv6 auch vorhanden wäre bzw. vorhanden ist.

Woran siehst Du das?

Hier z. B., "Resolving de.yahoo.com (de.yahoo.com)... 188.125.80.144, 2a00:1288:110:2::3007" und weiter mit "Connecting to de.yahoo.com (de.yahoo.com)|188.125.80.144|:443... connected.":

<i>
</i>--2017-11-20 12:05:13-- http://www.yahoo.de/
Resolving www.yahoo.de (www.yahoo.de)... 77.238.184.150
Connecting to www.yahoo.de (www.yahoo.de)|77.238.184.150|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://de.yahoo.com/ [following]
--2017-11-20 12:05:13-- http://de.yahoo.com/
Resolving de.yahoo.com (de.yahoo.com)... 188.125.80.144, 2a00:1288:110:2::3007
Connecting to de.yahoo.com (de.yahoo.com)|188.125.80.144|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://de.yahoo.com/ [following]
--2017-11-20 12:05:13-- https://de.yahoo.com/
Connecting to de.yahoo.com (de.yahoo.com)|188.125.80.144|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: '/dev/null'