Gelöst
Connection Timeouts nach BNG Umstellung
vor 6 Jahren
Guten Abend zusammen,
vor 2-3 Wochen wurde mein MagentaZuhause mit MagentaTV Tarif auf einen BNG Anschluss umgestellt. Seitdem habe ich massive Probleme beim surfen im Internet. Das äußert sich darin, dass einige Seiten nicht komplett geladen werden (Werbung, Bilder, ... fehlen teilweise), oder überhaupt nicht. Eine Website konnte ich ausfindig machen, die zuverlässig nicht funktionier: https://iacepc.com/. Über meinen Telekom Mobilfunk Tarif ist sie aber aufrufbar. Verrückterweise ist die Seite auch direkt von meinem Router aus erreichbar:
root@router:~# curl -v https://iacepc.com/ * Trying 116.206.106.203... * TCP_NODELAY set * Connected to iacepc.com (116.206.106.203) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=iacepc.com * start date: Jun 11 08:05:35 2019 GMT * expire date: Sep 9 08:05:35 2019 GMT * subjectAltName: host "iacepc.com" matched cert's "iacepc.com" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x54dea8) > GET / HTTP/1.1 > Host: iacepc.com > User-Agent: curl/7.52.1 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 301 < date: Thu, 01 Aug 2019 19:51:18 GMT < server: Apache/2.4.39 (cPanel) OpenSSL/1.0.2r mod_bwlimited/1.4 Phusion_Passenger/5.3.7 < x-powered-by: PHP/5.6.40 < location: https://www.iacepc.com/ < vary: User-Agent < content-length: 0 < content-type: text/html; charset=UTF-8 < * Curl_http_done: called premature == 0 * Connection #0 to host iacepc.com left intact
Und das meldet curl von meinem Notebook aus:
root@notebook:~$ curl -v --http1.1 https://iacepc.com/ * Trying 116.206.106.203... * TCP_NODELAY set * Connected to iacepc.com (116.206.106.203) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * Operation timed out after 300567 milliseconds with 0 out of 0 bytes received * Curl_http_done: called premature == 1 * stopped the pause stream! * Closing connection 0 curl: (28) Operation timed out after 300567 milliseconds with 0 out of 0 bytes received
Mein Router ist ein Banana Pi R2 mit Debian 9.9 und Kernel 4.14.67. Am eth0 (WAN) hängt das Glasfasermodem der Telekom. Die Einwahl erfolgt mit VLAN7. iptables verwalte ich mit ferm (http://ferm.foo-projects.org/), meine Forward Chain sah - zu Testzwecken - so aus:
Chain FORWARD (policy ACCEPT 2605 packets, 3520K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
11 2372 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHEDAber auch damit war oben genannte Seite nicht erreichbar.
Die Probleme scheinen sich auch sporadisch auf das IPTV auszuwirken. Gelegentlich bleibt das Bild hängen, fängt sich dann aber nach ein paar Sekunden wieder oder kann durch einen Snederwechsel wieder zum laufen gebracht werden. In seltenen Fällen zeigt das Display des Receivers im Standby Betrieb auch keine Uhrzeit mehr an, der Fernseher bleibt dann auch schwarz (nach dem Einschalten des Receiver ). Da hilft dann nur noch ein Reset.
Hat noch jemand einen heißen Tip für mich? Danke für eure Unterstützung!
Beste Grüße,
Daniel
1172
26
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 6 Jahren
Aber ich lasse mich gern eines besseren belehren.
Vor BNG brauchte es VLAN 7 und VLAN 8 für das Entertain. Hast du VLAN 8 mittlerweile aus der Einwahl entfernt?
Das der Anschluss ansonsten funktioniert, hast du ja selbst demonstriert.
2
Antwort
von
vor 6 Jahren
Guten Morgen,
ich weiss ehrlich gesagt gar nicht mehr, wie meine PPPoE Config vor 2 Wochen noch aussah. Aber ich meine, da stand zur Einwahl seit eh und jeh VLAN 7 drinnen ("plugin rp-pppoe.so wan.7"). VLAN 8 wurde doch nur für IPTV benötigt, war also in der igmpproxy Config (mittlerweile steht ppp0 als Upstream Interface drinnen).
Gruß,
Daniel
Antwort
von
vor 6 Jahren
Es könnte sein, dass die TV Aussetzer darauf beruhen.
Ebenso ist die Last für den Router höher, durch die fehlende Trennung von "Internet" und "TV" - also VLAN 7 und 8.
Daher wäre auch ein CPU Problem denkbar. Aber ich stecke nicht tief genug in der Materie rund um die Banane drin, um das beurteilen zu können.
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
Warum rufst du nach der Umstellung mit anderen Paramtern auf?
6
Antwort
von
vor 6 Jahren
Ok!
da du schreibst, dass die Seite vom Router aus aufrufbar ist, kann es nicht am Anschluss liegen.
ich würde mal die anderen Paramter prüfen, z.B, MTU oder MSS.
Ich hatte so was mal mit ipv6 als die MTU
Ansonsten mal ifconfig -a vom WAN und LAN INTERface posten
Antwort
von
vor 6 Jahren
Hallo Stefan,
ich vermute auch, dass es am Router liegt und dass der Grund mit der BNG Umstellung zu tun hat.
Hier die Interfaces:
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1492 inet 79.254.1.87 netmask 255.255.255.255 destination 62.155.247.121 ppp txqueuelen 3 (Point-to-Point Protocol) RX packets 5953 bytes 4905018 (4.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4451 bytes 1004009 (980.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::4463:88ff:fecf:7a62 prefixlen 64 scopeid 0x20<link> ether 46:63:88:cf:7a:62 txqueuelen 1000 (Ethernet) RX packets 12719660 bytes 16043108871 (14.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2228896 bytes 544173396 (518.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wan.7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::4463:88ff:fecf:7a62 prefixlen 64 scopeid 0x20<link> ether 46:63:88:cf:7a:62 txqueuelen 1000 (Ethernet) RX packets 12719951 bytes 15992537004 (14.8 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2228994 bytes 535315414 (510.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.0.252 netmask 255.255.255.0 broadcast 172.16.0.255 inet6 fe80::f0c3:12ff:fe9a:6c90 prefixlen 64 scopeid 0x20<link> ether f2:c3:12:9a:6c:90 txqueuelen 1000 (Ethernet) RX packets 5365677 bytes 1002162770 (955.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6469910 bytes 4960329084 (4.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Danke für deine Unterstützung!
Antwort
von
vor 6 Jahren
Sieht soweit gut aus, mir fällt nur auf, dass es kein ipv6 konfiguriert ist - Absicht ?
kannst du mal eine packet capture auf dem Wan und laninterface mitlaufen lassen.
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
willkommen in der Community.
Gerne prüfe ich deinen Anschluss auf eine mögliche Funktionseinschränkung.
Dazu bitte einmal deine Daten in deinem Profil hinterlegen. Das klappt am besten über den Link in meiner Signatur. Bitte gib' anschließend kurz Bescheid, wenn die Daten hinterlegt sind, damit ich ich zeitnah bei dir melden kann.
Beste Grüße
Malte M.
5
Antwort
von
vor 6 Jahren
Hallo @Stefan,
hier der Dump vom Router:
Antwort
von
vor 6 Jahren
Wenn sich curl auf lan0 bindet, fehlt angeblich die Route:
Die Routing Table dazu:
Und dazu noch meine ppp Config:
Update: Die Option --interface sorgt dafür, dass der Request auch über das entsprechende Interface geschickt wird. Ich bin davon ausgegangen, dass sich nur darauf gebunden wird. Der Output von curl kann also aus diesem post ignoriert werden.
Antwort
von
vor 6 Jahren
Die rote Kommunikation fehlt, an der Route stellte es m.E nicht liegen - generell gibt es ja eine Verbindung vom Client zum Server.
ich vermute es gibt irgendeine Option die gesetzt ist, man aber nicht im tcpdump sieht.
dazu müsste man aber das komplette Paket der Länge 517 z.B.
Nebst Daten sehen. Sowohl vom Router aus als auch vom Client .
hast du die Möglichkeit mal eine Fritzbox o.ä. dranzuhängen, damit wir definitiv wissen, dass es der Router ist
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
leider habe ich dich telefonisch bisher nicht erreicht. Wann passt dir ein Telefonat, damit ich mir deinen Anschluss einmal genauer anschauen kann?
Beste Grüße
Malte M.
3
Antwort
von
vor 6 Jahren
Guten Abend zusammen,
bitte entschuldigt die verspätete Antwort.
@Stefan Mit einer Fritzbox 7390 gibt es keine Probleme, liegt also definitiv am Router
Soweit ich das auch sehe, betreffen die Einschränkungen auch nur den SSL Traffic. Ich habe dummerweise schon alles wieder zurückgebaut. Morgen werde ich noch mal die FB anschließen und meinen Router als Client dran hängen, somit die Einwahl vom Router auf die FB verschieben und dann mal schauen, ob die Probleme immernoch auftreten.
@Malte M. Ich bin morgen wieder ganztägig erreichbar. Nächste Woche sollte aber auch noch passen
Beste Grüße,
Daniel
Antwort
von
vor 6 Jahren
@d-graf-dresden
ist keine Lösung, aber mach doch mal die Firewall für 30 Sekunden komplett aus.
Ich vermute, dass es mit irgendwelchen TCP Options zusammenhängt
Antwort
von
vor 6 Jahren
Hallo,
auch mit deaktivierter Firewall, bzw. mit NAT, gab es keine Besserung. Nachdem ich die FB das PPPoE hab machen lassen, hat der Router keinerlei Verbindungen ins Internet zugelassen. Ich wollte über kurz oder lang den Router ersetzen, was ich jetzt vorgezogen habe. Mir wird das mit dem Gerät langsam zu bunt. Evtl. probier ich es später noch mal...
@Malte M. Die Probleme liegen definitiv an meinem Router. Brauchst heute nich anzurufen, ein neuer Router ist unterwegs.
Vielen Dank und beste Grüße,
Daniel
Uneingeloggter Nutzer
Antwort
von
vor 6 Jahren
@d-graf-dresden,
ich bin morgen ab 19 Uhr im Büro und melde mich ab dieser Zeit bei dir. Einen angenehmen Abend.
Beste Grüße
Malte M.
0
vor 6 Jahren
vielen Dank für die Zwischeninfo. Ich werde es Malte so ausrichten.
Halte uns gerne auf dem Laufenden.
Beste Grüße
Julia U.
3
Antwort
von
vor 5 Jahren
Falls sich noch jemand mit diesem Problem hierher verirrt. Es ist ein MTU/MSS Problem. Das Verhalten tritt auf, wenn die MSS beim Verbindungsaufbau nicht den PPPoE Header berücksichtigt. Bei PPPoE muss man in den Firewall-Regeln die MSS setzen, z.B. per --clamp-mss-to-pmtu.
Gruß
Axel
Antwort
von
vor 5 Jahren
hatte ich schon im Beitrag 9 vermutet.
MTU muss 1492 sein und MSS bei Verwendung von IPv4 und IPv6 nicht höher als 1452
Antwort
von
vor 5 Jahren
Ja, wollte ja auch nur bestätigen. Bei mir war die MSS korrigierende Regel durch ein Update rausgeflogen und das Fehlerbild ist sehr verwirrend. Aber nach Korrektur ist alles wieder gut.
Gruß
Axel
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 5 Jahren
Falls sich noch jemand mit diesem Problem hierher verirrt. Es ist ein MTU/MSS Problem. Das Verhalten tritt auf, wenn die MSS beim Verbindungsaufbau nicht den PPPoE Header berücksichtigt. Bei PPPoE muss man in den Firewall-Regeln die MSS setzen, z.B. per --clamp-mss-to-pmtu.
Gruß
Axel
0
Uneingeloggter Nutzer
Frage
von