Fritzbox hinter Vodafone-Kabelrouter (Bridge Mode) - automatisch neu verbinden nach Lease-Ablauf?

[iqjet]

Sicherlich, ein HW Defekt ist nicht auszuschließen. Solange man die Konfiguration vom TO nicht kennt bzw. der TO sie nicht prüfen will, kann man nur spekulieren. Leider finde ich die Quelle nicht mehr, meine aber gelesen zu haben das man erst nach Ablauf der Widerspruchsfrist von 2 Wochen den Bridge Mode auf der VF Seite einstellen kann wg. WLAN. WLAN ist im Bridge Mode nicht mehr Verfügbar. Aber ne Linux Eieruhr ist auch was nettes.
Der TO hat den Anschluss seit 3 Wochen

Edit

Ich habe (dank des Hinweises von @PeterPawn) die Gelegenheit wahrgenommen und bestellt. Aber nicht um daraus Eieruhren zu basteln oder Modem/Router damit zu schalten, sondern für ganz andere Zwecke (u.a. für eine Zirkulationspumpe, zur elektrischen Verbrauchsmessung oder auch für die Ansteuerung eines Herrnhuter Stern). Für eine Eieruhr gibt es sicherlich geeignetere Geräte.

Das ist auch ein sinnvoller Anwendungsfall


Ich bin ja eher der Meinung (trotz defekten Displays meiner Glaskugel), das verwendete DOCSIS-Modem legt unregelmäßig Reboots hin. Vielleicht ja aufgrund eines Defektes. Für einen evtl. "Konfigfehler des TO" ist imo eher ein Psychotherapeut zuständig...

Tja, bei der Glaskugel geb ich dir Recht. Dem TO belastbare Infos zu entlocken ist nicht einfach, da sollte man den o.g.Spezialisten fragen
Soweit mir bekannt macht die FB 7390 bei ca. 8000 States die Grätsche.
Edit

Wie viele NAT-Sessions kann mein Router gleichzeitig aufbauen :: network lab

Anzahl aktiver Verbindungen durch DSL-Router testen :: network lab - Fehlersuche, Netzwerkanalyse, Tools

www.nwlab.net

ganz unten

Edit 2
DHCP Mitschnitt nach Reboot der pfSense (igb0 = WAN)

Nov 14 10:26:47    dhcp6c    98964    /var/etc/dhcp6c_wan.conf:3 IA_PD (0) is not defined
Nov 14 10:26:47    dhcp6c    98964    skip opening control port
Nov 14 10:26:47    dhcp6c    98964    failed initialize control message authentication
Nov 14 10:26:47    dhcp6c    98964    failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Nov 14 10:26:41    dhclient    10156    bound to 188.192.x.x -- renewal in 2052 seconds.
Nov 14 10:26:41    dhclient    14891    Creating resolv.conf
Nov 14 10:26:41    dhclient    14856    Adding new routes to interface: igb0
Nov 14 10:26:41    dhclient    14615    New Routers (igb0): 188.192.x.254
Nov 14 10:26:41    dhclient    14487    New Broadcast Address (igb0): 188.192.x.255
Nov 14 10:26:41    dhclient    14281    New Subnet Mask (igb0): 255.255.255.0
Nov 14 10:26:41    dhclient    14043    New IP Address (igb0): 188.192.x.x
Nov 14 10:26:41    dhclient    13701    ifconfig igb0 inet 188.192.x.x netmask 255.255.255.0 broadcast 188.192.x.255
Nov 14 10:26:41    dhclient    13611    Starting add_new_address()
Nov 14 10:26:41    dhclient    13187    REBOOT
Nov 14 10:26:41    dhclient    10156    DHCPACK from 83.169.184.130  ---> Vodafone
Nov 14 10:26:41    dhclient    10156    DHCPREQUEST on igb0 to 255.255.255.255 port 67
Nov 14 10:26:41    dhclient    11997    PREINIT

Die Kombination pfSense / FB läuft bei mir seit Jahren.

 

[telefonicus]

Meine Config:

(1) Sagemcom Fast 5460 am Breitband-Koaxialkabel von Vodafone

(2) Fritz!Box Fon WLAN 7390 über 30m LAN-Kabel mit (1) verbunden

Der Sagemcom Fast 5460 - Router ist im BRIDGE MODE, auch wenn manche das nicht für möglich halten.

Er re-bootet nicht sondern macht einfach gar nichts mehr, jedenfalls lässt er nichts durch und ist auch nicht erreichbar. Es sei denn, jemand verrät mir ein geheimes Türchen. http://192.168.100.1 ist es jedenfalls nicht.

Re-booten muss ich ihn dann selbst, per Schalter oder Steckdose, oder demnächst per "Eieruhr".

Ich habe jetzt einen Switch zwischen Fast 5460 und 7390. Will nachher mal meinen PC per Lankabel daran anschließen und nochmal checken, ob auf der http://192.168.100.1 nicht doch was geht.

 

[stoney]

Die verschlüsselte Variante als httpS://192.168.100.1 wurde bereits getestet?

 

[PeterPawn]

ob auf der http://192.168.100.1 nicht doch was geht.

HTTP ist nicht zwingend an dieser Stelle (diese "Schnittstelle" nennt sich CMCI - Cable Modem to CPE Interface), aber SNMP sollte in jedem Falle funktionieren: https://community.cablelabs.com/wik...nload?id=b564d22a-ee5e-4ce1-a1c7-cc27f541dbd4 - Chapter 9 und die 192.168.100.1 muß jedes (standardkonforme) Gerät auch unterstützen, egal in welcher Konfiguration bzw. in welchen Betriebszustand sich das CM gerade befindet (außer natürlich, es hat gar keinen Strom ).

Anders als bei DSL mit PPPoE, wird bei DOCSIS-Modems auch "pures" Ethernet zwischen Router und Modem gesprochen ... damit braucht man (im Gegensatz zu den meisten DSL-Anschlüssen in Deutschland) auch nicht unbedingt eine zweite virtuelle Verbindung (ohne PPP-Kapselung der Daten), um mit dem Modem direkt zu kommunizieren.

Solange die FRITZ!Box also Pakete für diese IP-Adresse auch tatsächlich über den WAN-Anschluß schickt (ich habe auch schon Spezialisten gesehen, die dann dachten, sie müßten jetzt in der FRITZ!Box das Netz 192.168.100.0/24 als LAN konfigurieren, was natürlich DER Kardinalfehler ist, den man an dieser Stelle machen kann), sollte das CM auf dieser Adresse auch reagieren (am einfachsten kann man ja erst mal einen ARP-Request machen) und die Antworten (egal, welche Absenderadresse die Pakete haben) auch auf dem eingehenden Interface wieder aussenden (also sie niemals nicht zum RF-Interface und damit zum CMTS weiterreichen).

 

[iqjet]

Scheinbar normal.

Geräte

forum.vodafone.de

Mein Arris Modem ist auch nicht erreichbar. Wenn man sucht findet man viele Einträge für diese Verhalten.

Edit
Hatte mal vor einem FW Update funktioniert.
Hast bei der FB folgende Einstellung für Zugangsdaten versucht?

Internetanbieter Weitere Internetanbieter
Anderer Internetanbieter
Internet Zugang als "Anschluss an externes Modem oder Router"
Betriebsart “Internetverbindung selbst aufbauen"

 

[telefonicus]

 

[iqjet]

Den Post verstehe ich nicht. Ist doch der gleiche Screenshot wie aus #4.
Wenn du selbst nichts unternehmen möchtest, dann lasse vom Vodafone Support deine Modemwerte prüfen und ggf. den Router tauschen.
Alle deine Settings sind deiner Meinung nach ok und somit nicht diskussionswürdig.
Ergo läuft alles.

Somit kann man dir nur eine Eieruhr empfehlen.

 

[sonyKatze]

Daher verstehe ich hier (zumindest bei diesem Fehlerbild) auch nicht so ganz, was der Paketmitschnitt an Informationen erbringen soll ...

Die MAC (bzw. Hersteller) des DHCP-Servers. Nicht mehr und nicht weniger. Selbst wenn die Erneuerung der Lease nicht klappt, sollte eine neue Lease (und gegebenenfalls eine neue IP-Adresse) ausgehandelt werden. Ganz automatisch. Daher ist hier irgendwas arg krumm. Außer nochmal wirklich 100%ig die Konfiguration checken und danach wild Geräte tauschen, habe ich aktuell keine Idee. Irgendwer sonst?

 

[PeterPawn]

Die MAC (bzw. Hersteller) des DHCP-Servers. Nicht mehr und nicht weniger.

Und die braucht man wofür? Und wenn die irgendeine relevante Info darstellen sollte (warum?), findet man die dann wo genau in dem Mitschnitt? Bei DHCPv4 wohlgemerkt ... und davon reden wir hier ja die ganze Zeit.

Oder anders gefragt: Warum sollte da in den DHCP-Antwort-Paketen eine andere MAC-Adresse als Absender auf L2 stehen, als die des CMTS? Das ist hier ein Kabel-Anschluß ... die gesamte L2-Kommunikation läuft zwischen CMTS und CM bzw. CMTS und Router, wenn das CM als Bridge L2-transparent ist (die Möglichkeit der zusätzlichen Filterung bei DOCSIS-Geräten (s. MULPI, Chapter 9.1) lassen wir jetzt mal außen vor, die ändert ja am Inhalt nichts und blockiert nur ggf. bestimmte Pakete).

Das alles auch noch unter der (meist aber falschen) Annahme, daß zwischen CMTS und DHCP-Server kein weiterer Relay-Agent sitzt oder das CMTS gar selbst als Bridge arbeitet (was meist auch nicht der Fall ist, schon wg. der Trennung der Broadcast-Domains) ... bei mir (Vodafone Cable) ist das jedenfalls definitiv kein "lokaler DHCP-Server", der Relay-Agent hat die IP-Adresse 83.169.170.114 und der DHCP-Server selbst hat die IP-Adresse 83.169.184.2 und liegt weit jenseits der BC-Domain, die am CMTS endet (wie man an den ARP-Requests sehen kann, die für andere IP-Adressen im (Kabel-)Segment sichtbar sind).

Nur was bringt die Kenntnis dieser ganzen Daten am Ende im Kontext des hier zu lösenden Problems?

Wie das mit dem Ablauf des T1- und T2-Timers beim DHCPv4 jeweils laufen sollte, habe ich oben schon beschrieben - was soll da an der Konfiguration bitte nicht stimmen (die willst Du ja noch einmal "100%ig checken" lassen), wenn die Zuweisung von IPv4-Adressen nach einem Neustart funktioniert und - angesichts der berichteten Zeiträume, bis der Fehler dann auftritt - auch bei den ersten anstehenden Verlängerungen?

Vodafone verwendet (bei mir jedenfalls, wobei ich die Prognose wage, daß das für alle KDG-Anschlüsse dasselbe ist, weil die Server zentral stehen) eine Lease-Time von 5400 Sekunden - also 90 Minuten, aka 1,5 Stunden.

Das heißt dann, daß spätestens nach 90 Minuten der erste Fehler auftreten müßte, wenn tatsächlich das Verlängern generell nicht funktioniert - und obendrein auch das Akquirieren einer neuen IPv4-Adresse (nach T2-Ablauf) ebenso fehlschlägt. Wobei man den Adresswechsel bei einer neuen IPv4-Adresse wieder im Eventlog sehen würde, wenn man mal annimmt, daß da nicht nach 7/8 der Zeit (denn Vodafone übermittelt keine abweichenden Werte für T1 und T2, es gelten also die Werte aus dem Standard) wieder dieselbe Adresse ausgegeben wird.

So eine "Fehlersuche", zu der man jemanden auffordert, muß ja schon irgendeinen Sinn ergeben ... was für eine Rolle die MAC-Adresse des DHCP-Servers bei Vodafone (bzw. der ehemaligen KDG) dafür spielen soll, leuchtet mir immer noch nicht ein - das ist die denkbar schlechteste Begründung für den Vorschlag eines Packet-Dumps samt Auswertung.

 

[iqjet]

Daher ist hier irgendwas arg krumm. Außer nochmal wirklich 100%ig die Konfiguration checken und danach wild Geräte tauschen, habe ich aktuell keine Idee. Irgendwer sonst?

Die Konfiguration ist über alle Zweifel erhaben.

Der TO hat bereits die Eieruhr gepimpt. Unter den gegebenen Umständen sicherlich eine weitsichtige Entscheidung.

 

[sonyKatze]

Und die [MAC] braucht man wofür?

Es ging darum, dass die Vermutung im Raum stand, dass das Modem eben nicht im Bridge-Modus ist.

 

[PeterPawn]

dass die Vermutung im Raum stand

Wie hat dann die FRITZ!Box hinter dem Modem die öffentliche IP-Adresse bekommen, die sie in #4 erhalten hatte?

Wieso sollte eigentlich die FRITZ!Box vom Router selbst keine IP-Adresse erhalten (ist dann halt keine öffentliche - aber würde ebenso nicht zu den Fehlernachrichten aus #12 führen, wo das Lease-Timeout erreicht wurde, ohne daß zuvor ein anderer DHCP-Server geantwortet hätte auf ein DISCOVER/REQ), wenn der als Router arbeitet (also der eRouter als eSAFE (embedded Service/Application Functional Entity) aktiviert ist für IPv4 und/oder IPv6) und sein eigenes LAN aufspannt?

Auch das war in #4 bereits zu beobachten ... und auch dafür gibt es eine (logische und plausible) Erklärung, nämlich daß der (eigentlich fälschlicherweise, aber solche kleineren Probleme in einer Firmware sind Alltag) beim Start erst mal LAN-seitig schon als Router loslegt (das ist seine Werkskonfiguration) und erst danach (entweder weil er im Rahmen der eCM-Initialisierung dann den letzten Zustand des esafeErouterInitModeControl-Objekts wiederherstellt oder weil er vom Provider im Config-File per TLV 202.1 entsprechend angewiesen wurde - die möglichen Zustände sind im Anhang C der eRouter-Spezifikation ausführlich dokumentiert) den eRouter deaktiviert.

Wenn hingegen die Vermutung "im Raum stehen" sollte, daß der DHCP-Server im FAST5460 nicht aktiviert ist UND das Teil im Router-Modus ist, was soll dann der Paketmitschnitt bringen bzw. wie soll der dann die Adresse eines DHCP-Servers (obendrein noch die MAC-Adresse - woher die kommen soll, ist ja immer noch unklar oder sollte #31 das irgendwie erklären?) aufzeigen, wenn der gar nicht antwortet? Sorry ... das ist alles nicht wirklich schlüssig, was hier so "im Raum stehen" soll. Es ist weder logisch, noch wahrscheinlich, wenn man die geschilderten Symptome berücksichtigt.

Die Konfiguration ist über alle Zweifel erhaben.

Hinsichtlich der Frage, ob da der Bridge-Mode (bei Vodafone) aktiviert ist oder nicht, hast Du mit dieser Feststellung absolut recht - selbst wenn das ggf. sarkastisch gemeint sein sollte ... jedenfalls dann, wenn man keinen validen Grund hat zu vermuten, daß der Fragesteller diese Konfiguration seit dem Schreiben von #4 geändert hätte.

Von (technisch begründeten) Argumenten, die Deine Thesen stützen würden, daß der Sagemcom-Router von VF NICHT auf Bridge-Mode gestellt wird (das ist ja nichts anderes, als daß der "eRouter" auf "Disabled" gesetzt wird: https://community.cablelabs.com/wik...nload?id=4844d788-9e5e-4670-88db-9b3f95f6f1b5 - Chapter 6 zum Nachlesen:

When the eRouter is 'Disabled', the eRouter MUST NOT enable either IPv4 or IPv6 services or route IP between the Customer-Facing Interfaces and Operator-Facing Interfaces. When the eRouter is 'Disabled', it transparently bridges all traffic directly between its Customer-Facing Interfaces and its Operator-Facing Interface. When configured in this way, it will appear as if there is no eRouter present. The CM bridges all traffic (regardless of IP protocol version) to the CPE ports that would have been behind the eRouter had it been enabled. When configured as 'Disabled', the eRouter specification becomes irrelevant – the interfaces become part of the cable modem. All behavior will occur according to the DOCSIS specifications.

), habe ich jedenfalls bisher nichts gelesen.

Wenn Du mir dann erklären kannst, wie die FRITZ!Box die öffentliche IPv4-Adresse aus #4 erhalten hat, wenn das Sagemcom-Gerät NICHT im Brigde-Mode war, reden wir gerne weiter - für mich gibt es dafür keine andere Erklärung als eine korrekte Konfiguration seitens VF und solange der Fragesteller daran nichts geändert hat (wovon er nichts geschrieben hat), gibt es keinen Anlaß, an dieser Stelle irgendwelche Probleme zu suchen. Wobei auch Du herzlich eingeladen bist, die Frage nach den DHCP-Server des FAST5460 zu beantworten: Warum kriegt die FRITZ!Box dann nicht von dem eine IPv4-Adresse, wenn er doch - nach Deiner Ansicht - im Router-Mode arbeiten könnte?

Deine Antwort an @telefonicus:

Deinen 2ten Post habe ich aufmerksam gelesen,

... glaube ich eigentlich nicht mehr so richtig, denn an:

Danach war er aber wieder im Bridge Mode. [...]
30.10.19 18:02:00 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 77.20.231.41, DNS-Server: 88.134.228.161 und 88.134.228.225, Gateway: 77.20.231.254

hättest Du dann eigentlich auch vorbeikommen müssen - DAS ist eine Eventlog-Message einer FRITZ!Box UND die enthält eine öffentliche IP-Adresse. Die kann die Box nur dann selbst erhalten, wenn der eRouter deaktiviert ist.

Und wie Du ständig auf "Eieruhr" kommst, erschließt sich mir nun gar nicht ... die kenne ich tatsächlich nur als "Timer" oder als "Mono-Flop" oder auch als "Kurzzeitwecker", wo dann - ausgehend von der gewünschten Kochzeit - rückwärts "gezählt" wird (auch bei den analogen Modellen, bei denen Kristalle durch eine Verengung dank Newton nach unten rieseln), bis die Zeit abgelaufen ist. Inwiefern sollte das jetzt eine Analogie zu einer "Schaltuhr" sein, die zu einer vorprogrammierten Uhrzeit einen Verbraucher ein- und/oder ausschaltet? Wenn's hinkt, ist's selten ein sinnvoller Vergleich.

 

[sonyKatze]

… wenn der gar nicht antwortet? …

Mhm. Es geht darum, wer der DHCP-Server ist, der die IP-Adresse zuweist, wenn alles klappt.

Also ich fasse nochmal zusammen: Bis jetzt kam niemand vorbei mit einer neuen Idee außer die Hardware zu tauschen. Sehe ich das richtig?

 

[iqjet]

Hallo,
Ich habe seit ca. 3 Wochen einen Kabelanschluss. In einem Kabeldeutschland-Forum hat vor ein paar Jahren jemand geschrieben:

Post#1 vom 1.11

Keiner weis wann Er/Sie/D den Bridge Mode und durch wen aktiviert hat. Soweit mir bekannt ist der Bridge Mode erst nach 14 Tagen aktivierbar. (Homespot)

Bridge Mode/Homespot

Guten Tag, ich hoffe man kann mir hier weiterhelfen. ich versuche seit ca. einer Woche den Bridge Mode zu aktivieren. Über das Kundenportal geht es nicht, da ich davor erstmal den homespot deaktivieren muss. Allersdings habe ich das schon 5 mal eingestellt und der bleibt trotzdem immer...

forum.vodafone.de

Deine Antwort an @telefonicus:
... glaube ich eigentlich nicht mehr so richtig, denn an:
hättest Du dann eigentlich auch vorbeikommen müssen - DAS ist eine Eventlog-Message einer FRITZ!Box UND die enthält eine öffentliche IP-Adresse. Die kann die Box nur dann selbst erhalten, wenn der eRouter deaktiviert ist.

Bestreite ich keinesfalls und habe das auch zur Kenntnis genommen, aber:

3) Surfen und Telefonieren ging nicht mehr, Fritzbox meldet "kein Internet" Ob die DSL-Lampe aus war oder geblinkt hat, erinnere ich mich nicht mehr. Ich wolte gerade einen Linux-Paketupdate machen (Downloads aus vielen verteilten Quellen), der immer langsamer wurde und zweimal wegen Zeitüberschreitung abbrach. Danach konnte ich noch einmal google.de und vodafone.de pingen, dann ging auch das nicht mehr, und die Statusmeldung
auf der Web-Oberfläche lautete

4) ...nicht verbunden - Ereignismeldung: 30.10.19 18:01:27 Internetverbindung wurde getrennt.

Passt irgendwie nicht zusammen?
Das Setup der FB ist wie in Post#4 m.M.n vollkommen OK und wenn ER/Sie/D auch noch schreit: "Lesebrille auf" "ich bin im Bridge Mode, IPv6 hab ich nicht bestellt (siehe Link)", ja dann. Dann sollte ja alles OK sein

Anmerkung: Meine FB Konfig weicht vom TO ab und ist ähnlich Deinem Vorschlag.

Was mich stutzig macht aus Post #4 ist der Satz "immer langsamer....." und das deutet eher auf doppel NAT oder hin, sicherlich hast Du das auch gelesen.

Auch sind die Logs meiner pfSense für DHCP WAN & FB klinisch rein. Auch nach Tagen, kein Bezug der WAN Adresse, KEIN DHCPREQUEST auf der pfSense. Jedoch frage ich mich: Was mache ich falsch, was muß ich machen um in den gleichen Genuß der Verbindungsabbrüche zu kommen wie der TO?
Und wie bekannt. Die Konfiguration vom TO ist über alle Zweifel erhaben.

Aufzeigend hat der allwissende TO den Bridge Mode auf ON, bewiesen hat Er/Sie/D es aber nicht.

Ein winziger kleiner Screenshot vom VF Konto "Bridge Mode" hätte ein Wunder und Klarheit bewirkt und nicht nur mich in allerhöchsten Verzückungen versetzt.
Wahrscheinlich hat der TO beim schwimmen sich zusehr auf den großen Fluß konzentriert um deinen Vorschlag umzusetzen. Ob Er/Sie/D den Weg zurückfindet?
Übrigens, den Tipp mit der Eieruhr hättest Du Ihm nicht geben sollen. Geradezu fahrlässig bei dieser Strömung. Ich nehme mal das beste für Ihn/Sie/D an.

Keiner weiß ob der TO eine stabile VF Linie hat. Ich gehe mal davon aus das alles OK ist, ist allerdings schon wieder eine Annahme. Die Logs vom TO sehen m.M.n äußerst vielversprechend um nicht zu sagen geradezu hervorragend aus.

Strukturierte Menschen wie Du selbst, würden wahrscheinlich alles auf den VF Auslieferungszustand (Werksreset) setzen und beobachten auf: (Ein Raspi sollte für diese kleine Task doch zu haben sein)

Resets

Verbindungsabrüche​

Speed​

Latenzen​

Falls alles nach Deinem Wunsche hin funktioniert:

Bridge Mode ON​

​

Falls immer noch Probleme:

Austausch des LAN Kabels oder vorab Test mit einem rudimentären LAN Tester vom großen Fluß, falls du den Weg zurückgefunden hast.​

Tausch der VF Box​

​

Zur Sicherheit

Installation einer Atomuhr mit angeschlossenem Schaltausgang in redundanter Ausführung in einem EXi geprüften Gehäuse​

Auch das gibt mir zu denken...
https://www.kdgforum.de/viewtopic.php?f=52&t=40421 ----- ipv6 vs ipv4 FAST5460

Mutmaßlich war der TO zu sehr mit seiner Atomuhr abgelenkt sodas Er/Sie/D meine Frage für DS Lite nicht zu beantworten vermochte. Der despektierliche Ausdruck "Eieruhr" ist sicherlich nicht politisch Korrekt

Diesen Ausdruck "Eieruhr" werde ich aus meinem Gedächtnis streichen, vielen Dank für die Erklärung. Ich entschuldige mich vorab bei jedem geschundenen Salzkristall in der Eieruhr.

Kannst Du, Peter Pawn, da Licht ins Dunkle bringen.
Kann es sein das du bei einem KNB arbeitest?

Edit: Schau, Schau....

[Erledigt] - FAST5460 Bridgemode selbst aktivieren?

Hallo, seit gestern hängt meine Fritzbox am Vodakabel-Router FAST5460. Leider sind wichtige Ports darin gesperrt, so dass ich mit der Fritzbox eigentlich nichts sinnvolles anfangen kann. Ich möchte den Kabelrouter deshalb im Bridgemode betreiben. Normalerweise müsste ich mich dafür im Vodafone...

www.ip-phone-forum.de

 

[telefonicus]

Hier ein Schirmschuss vom 24.10.2019. Ohne Beweiskraft freilich, könnte ich ja auch gefälscht haben. Sind hier viele Fälscher unterwegs?

 

[PeterPawn]

@telefonicus:
Jetzt mußt Du schon noch beweisen, daß Du die Aktivierung des Bridge-Modus auch von einem Experten mit Netzwerkkenntnissen hast ausführen lassen, wie Vodafone das empfiehlt.

Den Betrieb nach der Aktivierung traut man bei Vodafone offenbar dann auch wieder dem "normalen Kunden" zu ... das ist doch mal eine gute Nachricht.

 

[iqjet]

Hallelujah, das ist schon mal ein sehr guter Ansatz.

Was hältst Du von meinem Vorschlag aus Post #34 ?
Bridge Mode OFF, Router Reset auf Werkseinstellungen, beobachten auf Reboots&Resets, Modemwerte, Speedtest, Latenzen und dokumentieren. Falls die Speedtests inkonsistent sind und nicht min. 70% der gebuchten Leistung erbringt oder sporadische Resets auftreten dann ist ein VF Ticket öffnen, ansonsten Step 2 aus meinem Post #34

Dann sind nur noch 2 Komponenten übrig, fangen wir mit dem 30m LAN Kabel an. Ist das ein gekauftes oder selbst gecrimptes Kabel? Prüfe ob das Kabel ein STP/FTP Standard ist, ein Linetester ist hilfreich, dabei am Stecker wackeln, ziehen etc. Falls du eine Wanddose hast, gilt das gleiche Procedere.

Zur Info:
UDP Kabel sind in der EU nicht gebräuchlich, STP oder FTP Kabel sind Standard.
Mein Speed ist immer => der vereinbarten Leistung. Ping um die 20ms
Hilfe für den VF Router -> https://kabel.vodafone.de/static/media/sagemcom_WLANRouter_FAST5460.pdf

Für deine VoIP Telefonie gibt es m.M.n auch eine Lösung für den "Router Modus" welche im Ansatz, der Bauern-Peter oder ich, gegeben haben.

@telefonicus:
Jetzt mußt Du schon noch beweisen, daß Du die Aktivierung des Bridge-Modus auch von einem Experten mit Netzwerkkenntnissen hast ausführen lassen, wie Vodafone das empfiehlt.

...und da kommen die Freelancer ins Spiel. PEN Tests inklusive
@PeterPawn: Könntest Du mich erhellen da Licht ins Dunkle bringen.

 

[KunterBunter]

UDP Kabel sind in der EU nicht gebräuchlich

Nichtsdestotrotz funktionieren die auch, sogar bei TCP.

 

[PeterPawn]

Könntest Du mich erhellen da Licht ins Dunkle bringen.

Ich wüßte nicht wie ... die Diagnose ist doch ziemlich eindeutig.

Wenn eine DOCSIS-Box an einem DS-Lite-Anschluß betrieben werden soll, dann wird ihr eRouter vom KNB auf "IPv6-only" provisioniert. Der IPv4-Support ist dann Sache des eRouters, der sollte beim DHCP(v6)-Request auch nach einem AFTR-Server fragen und vom DHCP-Server auch einen solchen erhalten. Die Messages heißen zwar beim DHCPv6 etwas anders (Solicite/Advertise/Request/Reply), aber das Prinzip ist dasselbe - der Client sucht nach einem Server (bei IPv6 über eine Multicast-Adresse, siehe RFC 8415) und handelt mit dem die Parameter aus.

Je nachdem, was der eRouter jetzt kann, fragt er den Server auch nach entsprechenden Infos ... das heißt, wenn ein eRouter natives IPv6 verwendet und den IPv4-Support über DS-Lite unterstützt (bei der FRITZ!Box kann man das einstellen, beim Sagemcom vielleicht auch - ich selbst habe von Vodafone ein CH7466CE erhalten und selbst da keine Ahnung (weil's mich nicht interessiert hat bisher), ob das eine passende Einstellung für DS-Lite hat und ob man die selbst auf "nur IPv6" umstellen kann), dann ist er auch dafür verantwortlich, im DHCPv6-Request die Anfrage nach einem AFTR-Server zu senden. Kriegt er keinen vom Server, kann er auch IPv4-Traffic nicht entsprechend verpacken bzw. weiß nicht, wohin er den dann senden soll - denn alles, was dann von den Clients per IPv4 kommt und in Richtung Internet soll, muß der eRouter selbst in IPv6-Pakete kapseln und an den AFTR-Server senden.

Wenn das nicht funktioniert, gibt es eigentlich nur wenige Möglichkeiten:

• der eRouter fragt nicht nach dem AFTR, weil er nur IPv6 machen soll nach seinen eigenen Einstellungen
• der DHCPv6-Server liefert keine AFTR-Adresse - das sollte zumindest zu einer Fehlermeldung beim eRouter führen
• der eRouter ist falsch implementiert (kann ich mir hier aber nicht vorstellen) und berücksichtigt die zusätzlichen Einschränkungen beim DS-Lite nicht, denn dabei müssen die Pakete anders fragmentiert werden, weil in einem Ethernet-Paket weniger Platz für die Nutzdaten bleibt, wenn zusätzlich die Infos für den Tunnel noch im Paket stehen müssen - abgesehen davon, daß IPv6-Pakete per se einen geringeren Platz für L4-Daten bieten, weil schon die IP-Adressen auf L3 halt doppelt so lang sind ... wobei der minimale IPv6-Header schon mal fix 40 Byte belegt (ohne Extensions), im Gegensatz zu den 20 Byte eines IPv4-Headers

Das mit der geringeren MTU/MRU bei IPv6 und erst recht bei IPv4 über einen IPv6-Tunnel fiel vor einiger Zeit auch bei AVM mal denjenigen auf die Füße, die über DS-Lite einen (ausgehenden) VPN-Tunnel betreiben wollten ... hier wurde die MTU nicht richtig berechnet und in der Folge waren die Pakete dann zu groß, die für den verschlüsselten Traffic erzeugt wurden und eine nachträgliche Fragmentierung verletzt beim VPN die Integrität der gekapselten Daten - in der Folge funktionierten bei "normalen" Unitymedia-Anschlüssen mit DS-Lite keine VPN-Verbindungen (auch keine ausgehenden, denn bei eingehenden Verbindungen ist das bei DS-Lite ja zu erwarten).

Bei IPv6 ist auch MTU Discovery Pflicht und die funktioniert nur, wenn man ICMPv6 nicht ausfiltert ... es gibt aber (m.W.) ab und an auch mal Router-Firmware, die auf diese Ideen kommt. Das kann dann einem IPv6-Client hinter einem solchen Router auch heftig auf die Füße fallen, wenn da irgendwelche zusätzlichen Einschränkungen bei der MTU/MRU dazukommen, z.B. eine PPP-Kapselung (+8 Byte, was zur bekannten MRU von 1492 Byte bei PPPoE-Anschlüssen (Standard für DSL in D) führt und auch das hat länger gebraucht, bis da alle Geräte problemlos funktionierten).

Was hier konkret schief geht, kann man aus der Ferne halt nicht sehen ... die Liste der möglichen Ursachen muß derjenige mit dem Problem schon selbst abarbeiten (und meine oben erhebt auch absolut keinen Anspruch auf Vollständigkeit, das sind nur die häufigsten Ursachen, die mir selbst bisher begegnet sind).

Das mit dem "eRouter" gilt halt jeweils auch nur für den Fall, daß es sich um ein IAD handelt (also ein einzelnes Gerät, was sowohl Cable Modem, als auch Router ist), was hier (FAST5460) ja so ist - sind CM und Router getrennt, gilt alles oben für den "eRouter" Geschriebene für den verwendeten Router. Kann der kein DS-Lite, wird der auch nicht nach dem AFTR-Server fragen ...

Lese ich die Konstellation im verlinkten Thread, denke ich mir (rein unter Hinzuziehen meiner Glaskugel) folgendes:

• der Anschluß existiert schon länger, die Probleme treten erst seit einer Vertragsanpassung auf, wo wohl der eRouter jetzt (wieder?) auf "IPv6 only" konfiguriert wird
• auch ohne genaue Kenntnis der Einstellmöglichkeiten des FAST5460 unterstelle ich mal, daß der (ähnlich der FRITZ!Box 6490: ) die Möglichkeit bietet, die IPv6-Unterstützung zu konfigurieren und diese Einstellung aber nur begrenzten Einfluß hat, solange das eCM auf "IPv4 only" oder auch "IPv4 + IPv6" konfiguriert ist
• vielleicht hat der Fragesteller dort zu einer Zeit an diesen Einstellungen herumgespielt (ggf. war es ja "IPv4 only"), wo es noch keine Auswirkungen hatte - vielleicht weil er die Hoffnung hatte, damit dann doch IPv6 zusätzlich zu erhalten
• nach der Konfiguration des eRouters auf "IPv6 only" gelten jetzt vielleicht diese geänderten Einstellungen und das Gerät versucht gar nicht erst, DS-Lite für die IPv4-Unterstützung zu aktivieren - das "deaktiviert" sieht ja schon danach aus und es stellt sich nur die Frage, woher diese Einstellung am Ende kommt
• das sollte nach dem Zurücksetzen des FAST5460 (als Vorschlag dort schon nachzulesen) aber Geschichte sein ... ob VF den eRouter zusätzlich noch über TR-069 umkonfigurieren kann (bzw. ob man das macht), weiß ich aber nicht - ansonsten sollte das tatsächlich dabei schon geändert werden und würde vermutlich auch immer wieder überschrieben, wenn es wirklich (immer noch) von VF-Seite falsch gesetzt wird

 

[iqjet]

Stimmt, aber bei 30m und unbekannten "Verlegeweg" ist STP/FTP sicherlich besser.
Ich hatte mal einen hartnäckigen Verbindungsfehler/No Connection to Device der kam und wieder ging. Ich habe mir einen Ast in einer Anlage gesucht.
Da wurden Switche/Router/Portconfigs der Switche in Frage gestellt usw.
Die Lösung war trivial, schlechtes Kabel / Crimpungen der Stecker und billigst Dosen aus dem Chinamarkt. Solche Kombinationen sind einmalig. Neues Kabel gezogen Telegärtner Dosen gesetzt mit Telegärtner Stecker und Ruhe war. OK, das war Mitte der 90er in Osteuropa.