‎Connection Timeouts nach BNG Umstellung

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

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,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

vor 6 Jahren
Ich behaupte jetzt mal, dein Setup ist deutlich zu kompliziert für dieses Forum ^^
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
Geht mir erstmal nur darum, dass VLAN8 aus deiner Config völlig verschwindet.
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?

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 0

Danke 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

Hallo @d-graf-dresden,

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.

Antwort

von

vor 6 Jahren

Guten Abend zusammen,

@Stefan: Hier die tcpdump Mitschnitte:

# tcpdump -npi lan0 host 116.206.106.203 and port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lan0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:02:29.897953 IP 172.16.0.248.42728 > 116.206.106.203.443: Flags [S], seq 811072872, win 29200, options [mss 1460,sackOK,TS val 2541893405 ecr 0,nop,wscale 7], length 0
19:02:30.214893 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [S.], seq 3842757795, ack 811072873, win 28960, options [mss 1436,sackOK,TS val 2966500625 ecr 2541893405,nop,wscale 7], length 0
19:02:30.215212 IP 172.16.0.248.42728 > 116.206.106.203.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 2541893722 ecr 2966500625], length 0
19:02:30.218030 IP 172.16.0.248.42728 > 116.206.106.203.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 2541893725 ecr 2966500625], length 517
19:02:30.535298 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [.], ack 518, win 235, options [nop,nop,TS val 2966500945 ecr 2541893725], length 0
19:02:30.539208 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [P.], seq 2897:3022, ack 518, win 235, options [nop,nop,TS val 2966500949 ecr 2541893725], length 125
19:02:30.539490 IP 172.16.0.248.42728 > 116.206.106.203.443: Flags [.], ack 1, win 237, options [nop,nop,TS val 2541894046 ecr 2966500945,nop,nop,sack 1 {2897:3022}], length 0
19:03:31.553507 IP 172.16.0.248.42728 > 116.206.106.203.443: Flags [.], ack 1, win 237, options [nop,nop,TS val 2541955059 ecr 2966500945,nop,nop,sack 1 {2897:3022}], length 0
19:03:31.875522 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [.], ack 518, win 235, options [nop,nop,TS val 2966562284 ecr 2541894046], length 0

# tcpdump -npi ppp0 host 116.206.106.203 and port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:02:29.898090 IP 84.146.26.49.42728 > 116.206.106.203.443: Flags [S], seq 811072872, win 29200, options [mss 1460,sackOK,TS val 2541893405 ecr 0,nop,wscale 7], length 0
19:02:30.214810 IP 116.206.106.203.443 > 84.146.26.49.42728: Flags [S.], seq 3842757795, ack 811072873, win 28960, options [mss 1436,sackOK,TS val 2966500625 ecr 2541893405,nop,wscale 7], length 0
19:02:30.215278 IP 84.146.26.49.42728 > 116.206.106.203.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 2541893722 ecr 2966500625], length 0
19:02:30.218088 IP 84.146.26.49.42728 > 116.206.106.203.443: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 2541893725 ecr 2966500625], length 517
19:02:30.535217 IP 116.206.106.203.443 > 84.146.26.49.42728: Flags [.], ack 518, win 235, options [nop,nop,TS val 2966500945 ecr 2541893725], length 0
19:02:30.539150 IP 116.206.106.203.443 > 84.146.26.49.42728: Flags [P.], seq 2897:3022, ack 518, win 235, options [nop,nop,TS val 2966500949 ecr 2541893725], length 125
19:02:30.539545 IP 84.146.26.49.42728 > 116.206.106.203.443: Flags [.], ack 1, win 237, options [nop,nop,TS val 2541894046 ecr 2966500945,nop,nop,sack 1 {2897:3022}], length 0
19:03:31.553603 IP 84.146.26.49.42728 > 116.206.106.203.443: Flags [.], ack 1, win 237, options [nop,nop,TS val 2541955059 ecr 2966500945,nop,nop,sack 1 {2897:3022}], length 0
19:03:31.875449 IP 116.206.106.203.443 > 84.146.26.49.42728: Flags [.], ack 518, win 235, options [nop,nop,TS val 2966562284 ecr 2541894046], length 0

@Malte M.: Meine Daten habe ich soeben im Profil hinterlegt.

Antwort

von

vor 6 Jahren

Irgendwie fehlt hier was im Dump

Die Daten zwischen SEQ 519 und 2896 sieht man nicht

19:02:30.535298 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [.], ack 518, win 235, options [nop,nop,TS val 2966500945 ecr 2541893725], length 0
19:02:30.539208 IP 116.206.106.203.443 > 172.16.0.248.42728: Flags [P.], seq 2897:3022, ack 518, win 235, options [nop,nop,TS val 2966500949 ecr 2541893725], length 125

Man sieht noch die ack 518 und dann kommt ein Paket mit seq 2897 statt 519

kannst du den tcpdump nochmal laufen lassen und die Seite vom Router aufrufen -

pppoe Interface langt !

du sagt ja, das geht!

Uneingeloggter Nutzer

Antwort

von

vor 6 Jahren
@d-graf-dresden,

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
Hallo @d-graf-dresden,

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