FritzBox 7490 nur als DSL Modem

Ja.
Dazu wird die 7490 auf Werkseinstellungen gebracht und nicht eingerichtet. Ein anderer Router, an LAN1 der FBF angeschlossen, kann dann ganz normal per PPPoE die 7490 als Modem nutzen.

Wieso fragst du, wenn du es vor kurzem selbst behauptet hast?

crash7782 schrieb:

Die 7490 kann als reines DSL Modem betrieben werden!

Zum Vergrößern anklicken....

Andre schrieb:

Dazu wird die 7490 auf Werkseinstellungen gebracht und nicht eingerichtet. Ein anderer Router, an LAN1 der FBF angeschlossen, kann dann ganz normal per PPPoE die 7490 als Modem nutzen.

Zum Vergrößern anklicken....

Kannst Du das - die Grenzen der möglichen Einrichtung - noch etwas genauer formulieren? Gilt das z.B. nur für den Internet-Zugang oder schon für die Benutzerkonfiguration bzw. die Einrichtung eines Kennworts für die FRITZ!Box? In welcher Konfiguration - Anschluß der 7490 an welcher DSL-Technologie (Anbieter (impliziert VLAN-IDs), ATM/GbE, 2.PVC ja/nein), was war der Router hinter der 7490 für ein Modell, bei FRITZ!Box: mit welcher Einstellung (sicherlich Kabelmodem o.ä., wobei mich dann die PPPoE-Kapselung irritieren würde) - hast Du das getestet/festgestellt?
Auch aus einer nicht konfigurierten Box kann man die Support-Daten auslesen, wenn man die Seite als Deep-Link aufruft, kannst Du da mal ein Protokoll machen (da stehen dann ja überhaupt noch keine kritischen Daten drin, damit ist der Aufwand zum "Maskieren" ja nicht so groß)? Interessant sind weniger die DSL-Daten als die Netzwerk-Konfiguration und die ar7.cfg (das sollte allerdings die aus "/etc/default..." sein) der Box.
Und als letzte Frage: Überlebt dieser Modus (mode=dsldmode_bridge) auch mehr als einen Start der Box und auch einen versehentlichen Zugriff auf das GUI (wo der ctlmgr dann feststellt, daß die Box nicht konfiguriert ist und den Assi für das Kennwort startet)?

Eine Menge Fragen, die ich ja auch gefälligst selbst überprüfen könnte ... aber vielleicht kannst Du ja doch zumindest einzelne Aspekte beantworten.

Warum?

Bisher ging/gehe ich davon aus, daß der ctlmgr bei seinem ersten Start den Modus der Box explizit setzt, natürlich nicht über einen direkten Zugriff auf die ar7.cfg, sondern über die Einstellung
mit den möglichen Werten
Die Interpretation der möglichen Werte ist natürlich zu einem guten Teil nur Vermutung, aber die Modi mit "_eth_" und "_wlan_" stehen offenbar für eine WAN-Verbindung über LAN1 bzw. WLAN, bei "_ip" als IP-Verbindung (statisch oder DHCP), bei "_pppoe" eben mit entsprechender Kapselung. Die Bedeutung von "op_mode_ether" ist für mich "DHCP über DSL" (im Gegensatz zu "dsldmode_pppoe") und was am Ende bei "opmode_standard" tatsächlich an Einstellungen verändert wird, habe ich seit mehr als 6 Monaten nicht mehr getestet. (Weitere mögliche Werte für opmode am Ende des Beitrags als Ergänzung.)

Das eigentlich Spannende ist es nun, daß diese Einstellungen unmittelbare Auswirkungen auf die Kombination von "mode" und "ethmode" am Beginn der ar7.cfg haben (auch noch auf andere Stellen wie die Konfiguration von Bridges usw., aber das ignorieren wir erst einmal).
Für "mode" sind dabei wohl folgende Einstellungen möglich:
und für "ethmode" dann:
Bei allen meinen früheren Versuchen wurde der DSL-Modus immer wieder auf "dsldmode_router" gesetzt, auch wenn bei den Provider-Einstellungen "Anderer Anbieter" ausgewählt war, was dann wohl für "opmode_standard" steht. Wenn dabei auch bei der 06.23 immer noch der "dsldmode_router" automatisch gesetzt wird, geht es wohl tatsächlich nur im unkonfigurierten Zustand. Wobei meine Tests wie gesagt schon etwas her sind und wenn tatsächlich jemand mal die Verwendung der Box als reines Modem testen will, dann braucht er als "mode" wohl die Einstellung "dsldmode_bridge" oder "dsldmode_full_bridge" (Was das wohl ist? Ich würde auf VLAN-Tagging entfernen/hinzufügen bei "bridge" tippen und auf tatsächlich transparente Durchleitung der getaggten Pakete bei "full_bridge" - aber reine Spekulation!) dafür. Ob es bei "dsldmode_both" tatsächlich möglich ist, PPPoE-Passthrough parallel zum Router-Modus zu benutzen (dann sicherlich untagged), wage ich nicht einmal zu prognostizieren.

Da der ctlmgr nach meinen früheren Tests bei seinem Start die Konfiguration der Box anhand der Angabe "active_provider" in der ar7.cfg validiert, brachte (das könnte inzwischen anders sein) auch die manuelle Änderung von "mode" auf einen anderen Wert keinen Erfolg. Wenn AVM da tatsächlich etwas geändert/korrigiert hat für die 06.20 und spätere Versionen, dann könnte die 7490 tatsächlich auch wieder dauerhaft als DSL-Modem benutzt werden.
Aber auch die (m.W.) fortwährende Korrektur von "ethmode_router" in "ethmode_bridge" sprach/spricht in meinen Augen dagegen, daß der ctlmgr da einfach die Füße still hält. Es gibt auch in der Firmware nur noch im kdsldmod.ko und in libar7cfg.so ein Vorkommen von ethmode_router (ethmode_bridge zusätzlich noch in einigen (alten?) Provider-Einstellungen und der default-ar7.cfg) und daher glaube ich nicht daran, daß da tatsächlich für ethmode noch andere Einstellungen akzeptiert werden auf Dauer. Das kann für "mode" natürlich anders sein, aber ob man tatsächlich den kdsldmod.ko "foolen" könnte und nach dem Start des ctlmgr noch einmal an den Einstellung in der ar7.cfg drehen könnte, wenn man anschließend den dsld neu startet, kann ja jeder Interessent mal selbst testen. Die Hilferufe, daß die alten Beschreibungen zu "ethmode" nicht mehr funktionieren, sind jedenfalls auch nicht zu überlesen.

Bei "opmode_standard" wurde nach meinen Tests - wenn ich nichts übersehen habe - "mode = dsldmode_pppoe;" und "ethmode = ethmode_bridge;" gesetzt.

PS: Ob "das DSL" dann am Ende per Powerline tagged oder untagged als PPPoE tatsächlich an eine entfernte Firewall gesendet werden kann, weiß man damit immer noch nicht, also ist auch da ein "Selbst-Test" angezeigt.

EDIT: Wie mir gerade noch auffiel, würde sich meine Interpretation der Modi "dsldmode_bridge" und "dsldmode_full_bridge" ja mit Deinen Beobachtungen nicht vertragen. Da die korrekten VLAN-IDs ja providerabhängig sind, müßte der "Standard-Modus" aus der ar7.cfg (dsldmode_brigde) ja tatsächlich PPPoE-Pakete inklusive VLAN-Tagging durchreichen. Dann wäre die Frage, was "dsldmode_full_bridge" tatsächlich ist oder ob die "unkonfigurierte FRITZ!Box" unter Umständen doch nur bei bestimmten Bedingungen (wie eingangs mit der Frage nach dem Provider angedacht, also ADSL vs. VDSL, mit vs. ohne VLANs) als DSL-Modem agieren kann.

EDIT2: Neugierig geworden, habe ich dann noch die folgenden Werte für "opmode" gefunden:
Die verschiedenen Methoden der Authentifizierung (PPPoA mit/ohne LinkLevelControl, Subnetwork Access Protocol,usw.) sind imho ziemlich eindeutig, auch die "_usb_"-Modi dürften außer Zweifel stehen. In "opmode_eth_ipclient" sollte sich der reine Bridge-Mode LAN/WLAN manifestieren und die bei dieser Fragestellung im Thread tatsächlich spannende Einstellung könnte "opmode_modem" sein. Man müßte halt mal testen, welche Einstellungen sich in der 7490 ändern, wenn man ein "ctlmgr_ctl w box settingspmode opmode_modem" per Telnet absetzt. Ich habe aber im Moment keine 7490 zum Testen übrig.

Was ich getestet hatte:
Nach Werkseinstellungen der 7490 pfSense auf Igel 4210lx dahinter. 2.PVC habe ich nicht (Regio bei 1&1). Da mir die 7490 als reines DSL-Modem etwas übertrieben war, hatte ich sie später durch ein All033cj ersetzt.
Momentan habe ich aufgrund Anbieterwechsel bzw. vorübergehend zweiter Leitung noch keine Zeit gehabt, alles anzupassen und die 7490 am Magenta S als Router aktiv, kann also aktuell keine weiteren Tests machen.
Was ich definitiv weis aus meinen Versuchen: Benutzer einzurichten IP zu ändern, WLAN und DHCP abschalten ist definitiv unschädlich fürs PPPoE Passthrough. Ich hatte die FBF parallel über zwei Lankabel am pfsense, einmal als WAN (DSL-Modemfunktion), einmal am Switch auf LAN-Seite.
Die weiteren Versuche kann ich erst machen, wenn mein neuer pfsense so weit fertig ist (Fujitsu D3003-S2 Board mit zusätzlicher Netzwerkkarte, DualWAN mit Loadbalancing, kompletter Datenverkehr außer SIP, IMAP, Fernzugriff auf interne FBF über Cyberghost), das kann noch etwas dauern.

Danke für die Antwort. Die weiteren Tests kann ich dann bei Gelegenheit auch selbst wieder vornehmen ... es ging nur um aktuell vorhandene Erkenntnisse; es ist einfacher, bestehende Annahmen zu verifizieren oder zu falsifizieren.

Eine einzige Frage habe ich noch: War das Zufall, daß Du LAN1 verwendet hast als Anschluß für die pfSense oder ging es tatsächlich nur über LAN1? Wenn nur LAN1 ging, wäre das ja auch noch irgendeine etwas krude Bridge-Konfiguration, da ja dann sicherlich dieser einzelne Port (normalerweise eth0, dann aber wohl irgendwie umbenannt in diesem Modus) von den anderen getrennt war. Da würde es mich brennend interessieren, ob da tatsächlich nach Renumbering noch ein eth0 existiert oder ob die lan-Bridge dann nur noch eth1-3 und wlan umfaßt. Wenn das tatsächlich eine DSL-to-LAN-Bridge ist (also 'dev dsl' auf 'dev lan' ungefiltert durchgeleitet wird), fällt in diesem Falle ja das Splitten der Bridge flach und auch der Rest des LANs (inkl. WLAN) der Box kann dann nicht einfach wieder als lokales Netz verwendet werden. Dann wäre u.U. auch wieder für den Unterschied zwischen "bridge" und "full_bridge" eine weitere Interpretation denkbar, eben "bridge" nur für LAN1 und "full_bridge" für alle Ports auf der lokalen Seite.

Auch könnte ich mir tatsächlich vorstellen, daß das Ganze nur in einer Konfiguration (out of the box) funktioniert, wo DSL-seitig keine VLAN-Tags benötigt werden. Das muß allerdings noch nicht heißen, daß man nicht tatsächlich auch noch diese Konfiguration in den Griff kriegen kann, andererseits hängen die VLAN-Konfigurationen nach der ar7.cfg zu urteilen an "dslifaces" (i.d.R. internet + voip) und die dürften im Bridge-Mode ja gar nicht vorhanden sein.

Und auch der TE sollte eigentlich ja nun in der Lage sein, sich seine eigenen Tests für sein konkretes Anliegen zu planen ... meine Tests waren - wie geschrieben - für 06.05 und die allerersten 06.10-Laborversionen und müssen inzwischen nicht mehr stimmen. Wenn er also einfach mal mit dem ctlmgr_ctl-Kommando etwas experimentiert, kann er das problemlos selbst herausfinden. Allerdings definitiv keinen Provider setzen, denn dann wird tatsächlich (an einer 7390 getestet, aber das sollte nahezu identisch sein) umgehend ein "opmode" gesetzt, wie man über ein "ctlmgr -m" leicht protokollieren lassen kann (man muß eben Telnet so aktivieren, daß man nichts großartig per GUI konfiguriert) und auch an den Lua-Quellen problemlos nachverfolgen kann. Der Eintrag "mode = dsldmode_bridge;" als Standard-Einstellung ist jedenfalls mal verbürgt für die 7490, wenn es damit geht, sollte das ja problemlos machbar sein.

Ansonsten sorry für viele nur theoretische Überlegungen ... es ist ein weites Feld und bisher ist es offenbar Konsens gewesen (ich habe mich nur am Rande damit befaßt, als ich die Wirkung von opmode analysiert habe, deshalb habe ich auch nur Vermutungen zu den dsldmode-Einstellungen, da ich keine gefunden hatte, die "dsldmode_(full_)brigde" gesetzt hätte), daß eine 7490 als reines VDSL(!)-Modem nicht eingesetzt werden kann, weil die Firmware notwendige Einstellungen nicht mehr unterstützt. Wenn ich das richtig sehe, hast Du sie ja auch tatsächlich nur als ADSL-Modem eingesetzt ... die Box versucht ja selbst festzustellen, an was für einem DSL-Anschluß sie eigentlich läuft.

Ob und wie "dsldmode_modem" am Ende wirkt (das wird im GUI auch getestet, aber m.W. nicht gesetzt, jedenfalls habe ich auf die Schnelle nichts gefunden), muß man eben mal probieren. Spannend wird es ja dann, wenn der TE derjenige ist, der tatsächlich über Powerline-Adapter den DSL-Anschluß als PPPoE-Verbindung in den Keller bridgen und das LAN wieder zur FRITZ!Box zurücklegen will (getrennt über VLAN-Switch), um dann den AP der FRITZ!Box wieder zu nutzen ... mir ist irgendwie so, wenn ich die Nicks nicht verwechsele.

LAN1 war nur Zufall/Gewohnheit.
Leider fehlen mit ca. 100m zum DSLAM, so dass ich zwar fast 18.000/2.600, aber kein VDSL bekommen kann :-(

Falls es noch jemand interessiert: "dsldmode_bridge" lässt nur PPPoE durch. "dsldmode_full_bridge" lässt komplett alles durch.

leseratte10 schrieb:

Falls es noch jemand interessiert: "dsldmode_bridge" lässt nur PPPoE durch. "dsldmode_full_bridge" lässt komplett alles durch.

Zum Vergrößern anklicken....

Ich habe mir ja nicht einen Wolf geschrieben, weil es mich nicht interessiert und sei es auch nur zu Dokumentationszwecken ... aber die Frage für mich ist, was das genau heißen soll und wie Du das festgestellt hast? An einem DOCSIS-Anschluß und dem Unterschied bei einer 6360 mit und ohne Bridge-Mode? Da dort ja auf der DOCSIS-Seite gar kein PPPoE zum Einsatz kommt (soweit mir bekannt ist), würde mich dann interessieren, wie Du das getestet hast (wenn meine Annahme stimmt).

Oder hast Du die Information aus irgendeiner Dokumentation, die nicht öffentlich zugänglich ist? Wenn ja, will ich auch nicht wissen, welche das genau ist ... nur die "grobe Quellenangabe" (also meinetwegen Hersteller- oder providereigene Dokumentation) wäre nett und sicherlich auch nicht verfänglich.

Wenn Du die Information "nur" aus wehavemorefun.de hast, ist das auch akzeptabel, obwohl dort die Informationen auch schon etwas älter sind und für aktuelle Modelle (konkret die 7490 - und vermutlich weitere VR9-Modelle - mit aktueller Firmware) nicht mehr in vollem Umfang gültig sind, denn die ursprünglichen "Betriebsmodi" im Webinterface sind schon eine Weile den erwähnten "opmode"-Einstellungen gewichen und es gibt im gesamten Webinterface (gleich am Seitenanfang unter "Betriebsmodi" so zu lesen) nicht mehr eine explizite Bezugnahme auf irgendeine "dsldmode"-Einstellung (zumindest nicht mit dsldmode im Namen, ob libluadsl.so irgendetwas in der Richtung mit anderem Namen exportiert, weiß ich nicht). Dann wirst Du auch die weiteren Fragen eher nicht beantworten können ...

Bei "bridge" wäre dann der Betrieb als Modem an einem DSL-Anschluß ohne PPPoE nicht möglich und man müßte stattdessen "full_bridge" nehmen, im Prinzip in allen Fällen, wo auf der DSL-Seite kein PPPoE zum Einsatz kommt?

Ist da dann am Ende ein Unterschied bei der Behandlung von VLAN-Tags oder nicht? Werden die vielleicht auch bei "bridge" bereits transparent durchgereicht? Das ist ja nicht nur eine Petitesse, das wäre entscheidend für die Frage, ob die Verwendung als VDSL-Modem machbar ist oder nicht.

Gibt es dann jeweils einen fest zugeordneten Port für ge"bridge"te Boxen oder nicht und wie ist es bei "full_bridge"? Bei den Bridge-Modi der DOCSIS-Modelle (wo letzten Endes ja das DOCSIS-Interface die Stelle des DSL-Modems einnimmt) kann man ja explizit für die LAN-Ports einzeln festlegen, welcher davon nun direkt durchgeleitet werden soll und welcher nicht (irgendwo in lanbridges.lua glaube ich). Die restlichen Ports sind dann ganz normaler Bestandteil der "lan"-Bridge. Im Prinzip ist das bei passenden Modellen auch bei VPN mit LAN-LAN-Kopplung dasselbe, denn dort kann man ja dann eine VPN-Verbindung auch nur an einem bestimmten LAN-Port zur Verfügung stellen (als gesonderte "ipsecbrX"-Bridge) und damit das dort angeschlossene Gerät (oder auch mehrere über passende Switches) komplett vom Rest des lokalen Netzes isolieren und zum "virtuellen" Bestandteil ausschließlich des entfernten Netzes machen (sogar für zwei verschiedene Verbindungen, ob es bei Verzicht auf das Gastnetz an LAN4 sogar dreimal geht, habe ich gerade nicht im Kopf, aber LAN1 geht wohl prinzipiell - im GUI - nicht), quasi ein "remote port" für die Gegenstelle (das muß auch nicht zwingend eine FRITZ!Box dort sein).
Wenn man sich das wieder in den Quellen von AVM ansieht, müßte eigentlich bei passendem Switch in der Box so ziemlich jede beliebige Kombination von Ports zu realisieren sein (avm_cpmac, ifx_7port) und es bleibt eben die Frage, wie AVM das im dsld (oder wo auch immer) realisiert, wenn da einzelne Ports aus einem Verbund zu lösen sind. Das würde dann z.B. auch die Realisierung eines OpenVPN-Tunnels nur für einen einzelnen Port gestattet, wenn man den einfach über das Bridgen des TUN/TAP-Devices in die "ipsecbr1" zum entsprechenden LAN-Port dazutackert. Genug der Ausflüge in andere Gebiete ...

Daß es prinzipiell eine Möglichkeit zur unterschiedlichen Behandlung von VLAN-Tags geben sollte, entnehme ich den von AVM freigegebenen Quelltexten an einigen Stellen, z.B. hier:
Oder ist am Ende der PA komplett aus dem Spiel, wenn es sich um einen (dsldmode-)Bridge-Modus handelt? Das würde dann die Frage aufwerfen, ob bzw. wie es bei einer "normalen" Routerkonfiguration mit PPPoE-Passthrough funktionieren würde oder ob das am Ende der Grund für die Abschaffung von PPPoE-PT war.

Läuft bei einem der Bridge-Modi überhaupt ein dsld? Wenn nicht, wie wird das dann bei "dsldmode_both" realisiert? Greift erst da dann die Paketbehandlung (inkl. VLAN-(Un)Tagging) wieder? Wie unterscheidet die Box dann bei PPPoE-PT und Ingress vom WAN zwischen Paketen für sich selbst und solchen für die Durchleitung? Nur anhand der PPPoE-Session-ID?

Oder ist dann tatsächlich der lokale Teil der FRITZ!Box nicht mehr zu benutzen, weil das Brigding für alle LAN-Ports gilt? Wie konfiguriert man dann die Box in diesem Modus bzw. wie kommt man wieder raus? Welche Funktionen sind dann überhaupt in der Box noch zu benutzen (die Benutzereinrichtung funktioniert ja offenbar noch)? Solche Sachen wie Update-Suche, Push-Mails, SIP-Telefonie, VPN, usw. - letztlich alles, wofür die Box eine Internetverbindung bräuchte - müßten dann ja komplett unbenutzbar sein, wenn die Box nicht wieder über die "lan"-Bridge irgendein Gateway erreichen kann, "hinter" dem das Internet lauert.

Ich weiß schon, daß vieles vor Urzeiten schon mal ausgetestet wurde und damals dann auch so lief, wie es in whmf steht ... aber die Informationen altern inzwischen schon beim Zusehen und sind lange nicht mehr aktuell. Die letzten substantiellen Änderungen (danach gab es nur noch neue Bilder) stammen aus dem April 2012 - da war an 06.xx-Firmware noch gar nicht zu denken und einige Box-/Repeater-Modelle existierten höchstens auf dem Reißbrett.

Ich habe das Wiki dort selbst oft genug als Nachschlagewerk und zum Ver-/Abgleichen mit eigenen Vor-/Feststellungen genutzt, aber die Entwicklung bei den FRITZ!Boxen bleibt nun mal nicht stehen und daher stimmt eben einiges von dem dort Geschriebenen inzwischen definitiv nicht mehr und vieles Neues wird gar nicht erst erwähnt.

Das Ergebnis sieht man dann u.a. hier, wenn die Leute verzweifelt versuchen, irgendwelche alten Anleitungen (es gibt aber natürlich auch noch genug, was immer noch wie beschrieben funktioniert, damit wir uns nicht falsch verstehen und es am Ende so klingt, als hielte ich whmf für überflüssig - das ist durchaus nicht der Fall) nachzuvollziehen und es seit einigen Firmware-Versionen eben so nicht mehr funktioniert (Beispiel). Daher muß man die Aussagen für aktuelle Firmware einfach noch einmal überprüfen und ggf. eben auch selbst kritisch bewerten können, wie weit die heute noch gültig sein könnten.

Wenn man sich das Wiki ansieht, stellt man z.B. irgendwann fest, daß quasi mit der Einführung des "Packet Accelerators" (avm_pa) in der 05.05 die Dokumentation an dieser Stelle aufhört und die fortschreitenden Änderungen dann unberücksichtigt bleiben. Gerade bei der Realisierung des WAN-Zugangs und diesen ganzen Geschichten mit dem Wegfall von PPPoE-Passthrough dürfte der PA aber eine entscheidende Rolle gespielt haben (PPPoE-PT ist offiziell letztmalig in 04.8x drin, wenn ich mich richtig erinnere).

EDIT: Ich habe tatsächlich den Thread noch einmal gefunden, wo der Unterschied zwischen "full_bridge" und "bridge" unter anderem eben in der Behandlung von VLAN-Tags liegen soll.

Das stünde dann auch im Widerspruch zu whmf ... auf Layer2 muß man nun einmal wissen, ob Ethernet-Pakete VLAN-Tags enthalten oder nicht, denn nur so findet man den Payload direkt an der richtigen Stelle.

(Theoretisch könnte man das zwar auch über 0x8100 als "Ethertype"-Inhalt feststellen, aber dann verschieben sich eben andere Daten im Paket entsprechend nach hinten (der eigentliche "Ethertype" kommt dann 4 Byte weiter erst) und das ist für gerade hardware-basierte Auswertelogiken i.d.R. etwas schlechter zu realisieren (wenn da mitten im Paket zwei Byte für den TCI woanders hingeschoben und die zwei Byte der Tag-Anzeige entfernt werden müssen) bzw. auch bei solchen Konstruktionen wie dem PA ja immer eine zusätzlich notwendige Entscheidung, die man bei Kenntnis des genauen Aufbaus gleich vermeiden kann.)

Wenn aber das "nur PPPoE wird durchgereicht" bei "bridge" genauer eigentlich "nur Pakete mit der konfigurierten VLAN-ID der PPPoE-Verbindung werden - nach dem Untaggen - durchgereicht" heißen müßte, gäbe das wieder eine (mögliche) logische Einheit.
Da spielt dann wohl auch noch das ominöse "tcom_targetarch/vdsl_resalearch" wieder mit hinen, denn m.E. wird über "default_tcom_vlan = 7;" das Tagging der PPPoE-Pakete auch noch einmal implizit gesetzt, was bei anderen Providern schon mal zu erheblichen Problemen führen kann (alles nur meine Eindrücke nach Tests und man kann einfach nicht jede Situation korrekt abbilden ohne Hintergrund-Dokumentationen) ... diese Einstellung "überschreibt" wohl auch explizit bei "dslifaces" gesetzte Werte, wenn die nicht übereinstimmen.

Da es im anderen Thread "Mecker" gab, grabe ich die Threadleiche hier unfreiwillig aus

Auch wenn der Thread schon älter ist, aber jünger als so manch anderer....

Kann ich denn eine 7490 mit aktueller Firmware (7.21) als reines VDSL-Modem (dsldmode_full_bridge) verwenden?
Wenn ja, läuft die 7490 dann wirklich als reines Modem oder werde noch andere Pakete übergeben?


FritzBox 7490 nur als DSL Modem
Hallo zusammen, ist es denn möglich die FB 7490 nur als DSL Modem zu benutzen?

www.ip-phone-forum.de

Habe hier zwei 7490 (eine günstig als Backup geschossen) und eine davon würde ich gerne als Modem am 100er VDSL der T-Com betreiben (der geliehene Vigor 165 funktioniert super, aber die Backup-7490 wäre günstiger) wollen und die zweite kommt dann als AP und VOIP-Anlage hinter die OPNsense...

Zum Vergrößern anklicken....

Nö, das ist kein meckern, aber hier findest du eher die richtige Hilfe.
Und andere Suchende finden es dann an der richtigen Stelle.

Wenn deine OPNsense das nötige VLAN-ID setzen kann, müsstest du dsldmode_full_bridge mal selbst testen.

@Olaf Ligor

Jap, das kann die OPNsense definitiv - die Frage ist ja quasi, ob der dsldmode_full_bridge bei der 7490 mit aktueller Firmware überhaupt noch möglich ist und dann funktioniert...

Wenn das niemand anders bisher bei 7.21 bzw. Labor 07.24-85840 getestet hat, könnte das dein wundervoller Beitrag zum Forum werden. ;-)

Als ich konnte jetzt mit dem Fritz!Box Export Editor 0.6.9.7k die Config anpassen, der Modus steht auch noch nach einen Reboot auf


und ich konnte mich mittels der produktiven 7490 via LAN1 <--> LAN1 - 7490 (VDSL Modem) ins Internet verbinden - also die produktive 7490 hat die Internetzugangsdaten erhalten und sich eingewählt...

Jetzt wäre eigentlich nur noch zu klären, ob wirklich kein anderer Traffic über das "Modem" läuft?!

Vielleicht hat ja @PeterPawn hier noch hilfreiche Erkenntnisse?

Nein, habe ich leider nicht. Mich würde aber tatsächlich nicht wundern, wenn bei dieser Betriebsart am Ende auch Broadcasts der FRITZ!Box, die eigentlich nur im LAN sichtbar sein sollten, ebenfalls über das Modem zum DSLAM gehen - es ist halt eine Bridge. Die FRITZ!Box sollte in diesem Modus ja auch nicht als Router arbeiten, sondern ihrerseits (am besten mit einer festen IP-Adresse, wobei das bei PPPoE wieder weniger kritisch ist, weil da ein DHCP-Request der FRITZ!Box, der zum DSLAM geht, keine weiteren Auswirkungen haben sollte und die Antwort dann von der LAN-Seite kommen müßte) wie ein IP-Client und irgendein anderes Gerät im LAN als Gateway nutzen.

Denn ansonsten hat natürlich die FRITZ!Box auch so "ihre Bedürfnisse", was Internet-Verbindungen angeht (angefangen bei Uhrzeit und Update-Suchen) - das wird (m.W.) alles nicht automatisch mit abgedreht, weil die Box nun plötzlich IP-Client ist. Wenn sie also etwas von einem Host will, der nicht zu ihren LAN-Einstellungen paßt, geht das ans konfigurierte Gateway und vermutlich sind sogar die ARP-Requests bei der Suche nach dessen MAC-Adresse anhand seiner IP auf der "WAN-Seite" (also jenseits des DSL-Modems) zu sehen.

Ich könnte mir (so aus theoretischen Erwägungen) sogar vorstellen, daß der Durchsatz in diesem Modus stark eingeschränkt ist, weil die Hardware-Beschleunigung nicht aktiv ist (darauf würde ich sogar wetten) und ich nicht sicher bin, daß tatsächlich im internen Switch der FRITZ!Box eine "back-plane" vom Modem-Port zu den anderen Ethernet-Ports geschaltet wird und nicht nur zur CPU. Sollte das nur die Kombination aus Modem-Port und CPU-Port sein, müßten die Pakete ggf. erst mal über die CPU und die Software-Bridge im Linux ... ob deren Konfiguration auch in diesem Modus direkt im internen Switch programmiert wird (was m.W. der "dsld" machen müßte), müßte man nachsehen oder vielleicht auch nur messen. Ohne Hardware-Support und ohne direkte Weiterleitung im internen Switch dürften 100 MBit/s für einen VR9-Prozessor auch zur Herausforderung werden.

Danke für die Informationen @PeterPawn

Dann werde ich statt der 7490 einen Vigor an die TAE hängen und die 7490 als Backup in den Schrank legen...

Mal eine andere Frage: kann man Fritzboxen als Bridge nutzen, aber irgendwie dafür sorgen dass die Fritzbox sich um das VLAN7 kümmert und nicht die Firewall davor? Es soll ja Firewalls geben, die PPPoE nur untagged unterstützen...

Das geht wohl nicht, deswegen habe ich damals auch den TP-Link TL-ER6120(V1) in die Ecke geschleudert.
Blöde Router ohne Tagging-Möglichkeit und Fritzboxen im Bridge-Mode passen irgendwie nicht zusammen.

Olaf Ligor schrieb:

in die Ecke geschleudert.

Zum Vergrößern anklicken....

Dann hättest den auch mir geben können ...