Solved
Connection Timeouts nach BNG Umstellung
6 years ago
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,ESTABLISHED
Aber 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
This could help you too
You might also be interested in
Request purchasing advice
Fill out our online contact form quickly and easily so that we can advise you personally in a timely manner.
View offers
Informieren Sie sich über unsere aktuellen Internet-Angebote.
6 years ago
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
Answer
from
6 years ago
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
Answer
from
6 years ago
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.
Unlogged in user
Answer
from
6 years ago
Warum rufst du nach der Umstellung mit anderen Paramtern auf?
6
Answer
from
6 years ago
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
Answer
from
6 years ago
Hallo Stefan,
ich vermute auch, dass es am Router liegt und dass der Grund mit der BNG Umstellung zu tun hat.
Hier die Interfaces:
Danke für deine Unterstützung!
Answer
from
6 years ago
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.
Unlogged in user
Answer
from
6 years ago
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
Answer
from
6 years ago
Hallo @Stefan,
hier der Dump vom Router:
Answer
from
6 years ago
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.
Answer
from
6 years ago
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
Unlogged in user
Answer
from
6 years ago
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
Answer
from
6 years ago
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
Answer
from
6 years ago
@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
Answer
from
6 years ago
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
Unlogged in user
Answer
from
6 years ago
@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
6 years ago
vielen Dank für die Zwischeninfo. Ich werde es Malte so ausrichten.
Halte uns gerne auf dem Laufenden.
Beste Grüße
Julia U.
3
Answer
from
5 years ago
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
Answer
from
5 years ago
hatte ich schon im Beitrag 9 vermutet.
MTU muss 1492 sein und MSS bei Verwendung von IPv4 und IPv6 nicht höher als 1452
Answer
from
5 years ago
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
Unlogged in user
Answer
from
Accepted Solution
accepted by
5 years ago
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
Unlogged in user
Ask
from