Seite 2 von 2

Re: AFTR-Relay leitet keinen Verkehr weiter

Verfasst: 4. Sep 2024 22:13
von jeduardo
Nur zur Info: Das Dokument von Willy.Tel ist von Januar 2021.
Das ist eine interessante Erkenntnis, aber dennoch kann ich mit Sicherheit sagen, dass ich nie eine Ankündigung dazu erhalten habe. Auch andere in der Diskussion haben erwähnt, dass sie von der Änderung überrascht wurden. Meiner Meinung nach liegt es in der Verantwortung des Anbieters, eine so weitreichende Änderung klar zu kommunizieren – selbst wenn sie vor Jahren damit begonnen haben und den Rollout nur schrittweise durchgeführt haben.

Zusätzlich, da ich gezwungen bin, meine Verbindung jede Nacht zurückzusetzen, andernfalls wird sie von deren Seite zurückgesetzt, habe ich tägliche Verbindungsprotokolle. Bis Montagmorgen, als sie ihr DS-Lite-Relay abgeschaltet haben, habe ich nie eine öffentliche IPv4-Adresse erhalten. Doch ab diesem Zeitpunkt, oder vielleicht erst ab Dienstag, begann ich, während der PPPoE-Verbindung eine sehr willkommene öffentliche IPv4 zu bekommen. Zuvor endete die Verbindung immer mit der Meldung „IPCP: timeout sending Config-Requests“ und ohne IPv4.

Code: Alles auswählen

Sep 02 10:11:03 apu systemd[1]: Started ppp@provider.service - PPP connection for provider.
Sep 02 10:11:03 apu pppd[1362]: Plugin rp-pppoe.so loaded.
Sep 02 10:11:03 apu pppd[1362]: Plugin rp-pppoe.so loaded.
Sep 02 10:11:05 apu pppd[1362]: pppd 2.4.9 started by root, uid 0
Sep 02 10:11:08 apu pppd[1362]: PPP session is 22785
Sep 02 10:11:08 apu pppd[1362]: Connected to 04:6c:9d:54:bc:13 via interface enp1s0
Sep 02 10:11:08 apu pppd[1362]: Using interface ppp0
Sep 02 10:11:08 apu pppd[1362]: Connect: ppp0 <--> enp1s0
Sep 02 10:11:14 apu pppd[1362]: Remote message: Welcome to wilhelm.tel Direct-Termination-Service
Sep 02 10:11:14 apu pppd[1362]: PAP authentication succeeded
Sep 02 10:11:14 apu pppd[1362]: peer from calling number 04:6C:9D:54:BC:13 authorized
Sep 02 10:11:14 apu pppd[1362]: local  LL address fe80::31c6:96c6:0ffa:8b31
Sep 02 10:11:14 apu pppd[1362]: remote LL address fe80::066c:9dff:fe54:bc13
Sep 02 10:11:44 apu pppd[1362]: IPCP: timeout sending Config-Requests
Trotz allem bin ich froh, dass sie diese Änderung vorgenommen haben. Ich habe gerade den Kernel meines Routers auf die neueste Debian-Version 6.1.0 aktualisiert, und nachdem ich ein paar MSS-Clamping-Regeln in die Firewall eingefügt habe, läuft alles perfekt.