Als Router habe ich sowohl einen Zyxel USG20 wie auch einen Zyxel USG60 verwendet.
Nach dem Werksreset steht die FB auf dsldmode_bridge.
Danke für Deine Antwort ... wir/ich hatte(n) das Thema
vor kurzem erst für die 7490.
Die definitive Aussage, ob nun mit "full_bridge" der gesamte Verkehr inkl. VLAN-Tags durchgereicht wird oder nicht, war das, was ich mir von Deiner Antwort erhofft hatte.
Was ich nun nicht verstehe ... heißt
Bei dem USG20 durfte keine VLAN7 gesetzt sein. Beim USG60 habe ich noch nicht mit VLAN experimentiert.
nun, daß im Zyxel-Router kein VLAN eingestellt sein durfte (das würde dafür sprechen, daß die Box selbst taggt und es dann doppelt wäre) oder heißt das, der Zyxel-Router mochte es seinerseits nicht, wenn die Box wegen ihrer eigenen Einstellung auf VLAN7 (und Untagging) die Daten ohne VLAN-Tag nach innen durchgereicht hat?
Ich habe die FB auch als dsldmode_full_bridge eingesetzt. Nur das "_full" eingefügt und keine anderen Änderungen vorgenommen.
Ok, das ist doch schon mal was ... aber was war denn am Ende (in den Daten) der Unterschied zwischen "bridge" und "full_bridge"? Kannst Du das sagen oder hast Du nur konstatiert, wann es mit welchem Router ging und wann nicht und Dich nicht weiter um die Ursachen/Zusammenhänge gekümmert?
Wenn der Zyxel-Router selbst feststellen kann, ob die Pakete getaggt sind oder nicht (das läßt sich ja ermitteln, wenn man es bei der Analyse eines Datenpaket ins Kalkül zieht), dann würde das ja eindeutig darauf hindeuten, daß das Taggen/Untaggen tatsächlich der entscheidende Unterschied zwischen "bridge" und "full_bridge" ist. Ich würde mir das dann so erklären:
dsldmode_bridge -> FRITZ!Box entfernt selbst die VLAN-IDs aus eingehenden Paketen und fügt sie bei ausgehenden Paketen wieder hinzu -> macht das jetzt der Zyxel-Router noch einmal selbst, gibt das doppelte VLAN-Tags
dsldmode_full_bridge -> FRITZ!Box reicht VLAN-IDs 1:1 durch und Zyxel-Router erkennt selbst, ob getaggt oder nicht, deshalb ist ihm das auch Bummi
In jedem Falle ist es bei Dir also ein VDSL mit VLAN-Tags und dann auch noch Telekom, also VLAN-ID=7, was sowohl explizit als auch durch "tcom_targetarch=yes;default_tcom_vlan=7;" (bei Dir ist ja offenbar "targetarch=no") gesetzt sein könnte. Im anderen Thread war es ja "nur" ein ADSL-Anschluß und damit ist dann die prinzipielle Machbarkeit als VDSL-Modem wohl auch mit 06.2x geklärt.
Hier noch ein Stück meiner aktuellen Konfiguration:
Für die Entscheidung, wie sich der kdsld beim Bridgen des Verkehrs verhält, würde mich tatsächlich mal interessieren, was das Modem (bzw. wohl schon der dsld) da nach dem Training alles so an möglichen Anbindungen testet. Mich irritiert es weniger, wenn die Box als Modem es schafft, die VLAN.-Tags zu entfernen, bevor der Traffic nach innen weitergeleitet wird, weil dafür die VLAN-ID eigentlich egal ist. Vielmehr stelle ich mir die Frage, woher die Box weiß, welche VLAN-ID sie ausgehenden Paketen verpassen soll, wenn - wie bei Dir - tcom_targetarch=no gesetzt ist und sie somit keinen Schimmer hat, was das für ein Anschluß ist, an dem sie da hängt. Da ist es dann vermutlich entscheidend (nur Annahme, nicht getestet mangels "Test-Anschluß"), daß die Box als Standard in der ar7.cfg irgendwo die Einstellung
Code:
dslglobalconfig {
autodetect = yes;
[...]
}
hat und damit wohl nach erfolgreichem Sync ein passendes "Programm" an Tests abspuhlt, um den Anschluß zu "erraten".
Das würde dann aber auch bedeuten, daß eine so konfigurierte Box als Modem immer länger braucht, bis sie wirklich bereit ist (ich weiß nicht, ob erst ADSL oder erst VDSL getestet wird, anhand früherer Beobachtungen der 7490 - und der Ausgaben auf /dev/console - würde ich auf ADSL als erstes tippen, aber das habe ich auch schon lange nicht mehr bewußt beobachtet) oder sogar im schlechtesten Fall die Möglichkeit besteht, daß sie sich bei diesem Test auch mal vertut und dann nichts mehr geht. Da würde ich ja bei einer solchen Konfiguration versuchen, die Parameter nach der ersten erfolgreichen Verbindung von Hand festzuzurren und die Autoerkennung zu deaktivieren, schon aus (den vermuteten) Zeitgründen.
OT:
Dieser "full_bridge"-Modus wäre ja dann tatsächlich optimal, um mit einer abgesetzten Firewall (von IPCop über pfSense bis Sophos UTM Home) die Funktion der FRITZ!Box zu ergänzen und sie trotzdem noch als TK-Anlage und WLAN-AP zu verwenden - als TK-Anlage ist sie nicht schlecht und wenn da schon ein ac-WLAN drin ist, kann man es auch verwenden.
Der dsld würde dann praktisch keine Verbindung (keinen Paketaustausch) mit Rest der Firmware haben und die Standardroute der Box selbst müßte ins LAN (am besten auf die Firewall) zeigen. Damit würde man einerseits die Fähigkeiten der FRITZ!Box als TK-Anlage weiter nutzen können und hätte trotzdem eine "ausgewachsene" Router-Lösung, die auch Extrawünsche erfüllen könnte.
Dann einen passenden Embedded-Computer als Router (der muß schon den Durchsatz schaffen und da fällt ein RasPi dann sicherlich eher aus, schon wegen der Netzwerk-Anbindung) und man hat ein richtig schönes Paket im Heimnetz ... aber vor allem ist man in der Flexibilität nicht mehr durch die AVM-Firmware eingeschränkt (bei DNS, DHCP, DynDNS, iptables, Proxies usw.).
Das fände ich dann tatsächlich spannend, denn es ermöglicht ja auch zusätzliche Features wie eine richtige DMZ o.ä., was von AVM für den SOHO-Bereich sicherlich eher nicht zu erwarten ist (die paar "Business"-Router bei den Kabelprovidern fallen ja sicherlich kaum ins Gewicht bei der Beurteilung wünschenswerter Features).
Aber man könnte dann wohl auch als Paranoiker etwas ruhiger schlafen, denn diverse Kritikpunkte an der AVM-Firmware (für einen Router) hätte man selbst in der Hand (von unverschlüsseltem Telnet bis zu "everybody is root everytime") und könnte seine eigenen Vorstellungen umsetzen (selbst wenn die für Home/SOHO etwas übertrieben anmuten mögen). Das geht natürlich auch heute schon (mit Extra-Modem) und ob die Trennung zwischen dsdl und dem Rest des Netzwerkstacks ausreichend ist (der PA müßte dann ja eigentlich aus sein), weiß ich auch nicht ... aber das eingesparte Gerät (ext. Modem) könnte den Aufwand lohnen.