Beiträge von Elemir

Zitat von frank_m

Ok, wenn euch das reicht. Bislang wurde das TKG diesbezüglich immer sehr wörtlich ausgelegt.

Es würde mir dauerhaft nicht reichen (erstmal != dauerhaft). Aber es gibt die Klarstellung, wie das zu interpretieren ist und dass es nicht zu Verschlechterungen kommen kann.

Der Rest wird dann schon kommen, spätestens wenn GPON durch XGS-PON ausgestauscht wird, kann sich keiner mehr herausreden, das anders ausgelegt zu haben, oder was auch immer die Behauptung der Provider ist.

Dass es dann nicht von heute auf morgen geht - wegen mir. 5 Jahre: eigentlich zu lang, wir werden sehen.,

Ich persönlich bin nicht betroffen, da sowohl mein Anschluss als auch der von mir betreute Anschluss bei Providern liegen die da keine Probleme machen und beim von mir betreuten Anschluss auch nicht der Wunsch besteht, da etwas zu ändern.

Aber wäre ich betroffen, würde ich den Provider nach dem endgültigen Bescheid mit Verweis auf den Bescheid schon auffordern, mir das zu ermöglichen. Ist für den Provider eigentlich auch Win-Win: tut der ONT nicht und hat er alle Informationen veröffentlicht, ist er raus. Ist doch eigentlich viel einfacher als die Diskussionen mit dem Kunden.

Dumm halt nur, wenn er es a la DG mit Whitelisten im POP aktiv verhindert.

Zitat von pufferueberlauf

Mmmh, gucke ich in:

1TR112_V14.1_Amendment_1_GPON_IF-PON.pdf

sehe ich keine explizite Whitelist (wohl aber Listen mit Anforderungen die ein ONT erfuellen muss)... wo finde ich die fuer die Telekom?

Ich denke auch, dass es keine Whitelist in dem Sinn gibt, sondern "nur" eine Config-Liste mit einzelnen Parametern für spezielle Geräte, jedes dort nicht enthaltene Gerät wird aber nicht ausgeschlossen, sondern mit Default-Parametern betrieben. Das ist aber nur Spekulation, weil sich dazu eben nichts findet.

Zitat von flotux

Wenn die ersten 8 Hex Zeichen "5A59574E" umwandle, kommt ZYWN heraus, was dem der Vendor ID Zyxel entspricht. Diese Vendor ID mit den übrigen 8 Zeichen als Hex ergibt dann 12 Zeichen in einer Schreibweise, die ich auch auf der Rückseite des Original ONT Geräts Nokia I-010G-U bei einem Bekannten erkannt habe.

Sorry, natürlich 8, damit 4 Zeichen rauskommen. Sonst kommt man ja nicht auf die 12 Zeichen. Weiß nicht, wo ich da geistig war

Zitat von frank_m

Genau. Das sehe ich auch so. Vielleicht wird der ein oder andere zusätzliche Komponenten aufnehmen über ein Zertifizierungsprogramm. Aber mehr ist realistisch nicht zu erwarten.

Das reicht doch erstmal.

Immerhin wird keiner den Zwang zum Provider-ONT neu einführen, wenn man sich die Anträge durchgelesen hat, dann stand das durchaus als Befürchtung im Raum. Künftige Newcomer werden sich auch danach richten.

Und wie bestehende damit umgehen werden, werden wir mal sehen.

Was, wenn ein Kunde die eigene 5690 anschließt, dem Provider eine Störung meldet und für die Ausfallzeit Ersatz einfordert? Mit welcher gerichtsfesten Begründung wird der Provider die Zahlung ablehnen? Ein Verweis auf eine ungültige AGB-Klausel - schwierig. Ein Richter in einem Verfahren könnte sich hier an die Entscheidung der BNetzA halten und das als Ausfall sehen, aber wie das halt so ist, vorher weiß man es nicht.

Auf jeden Fall haben es die Provider nun schwerer und werden zumindest mit "Standardteilen" wie 5690 oder üblichen SFP-Modulen weniger herumzicken. Bei Exoten werden es dann halt Einzelfälle sein, wo sie das Risiko eher eingehen werden.

Zitat von flotux

Ich habe jetzt direkt nochmals das Gespräch mit LEW TelNet gesucht und explizit nach der Unterstützung für mein SFP-Modul Zyxel PMG3000-D20B gefragt. Dort wurde mir mitgeteilt, dass es nicht unterstützt wird, weil die Modem-ID länger als 12 Zeichen sei und nur genau 12 Zeichen unterstützt werden.

Auf der Verpackung des Geräts sind die MODEM-ID (16-stellig in Hexadezimalschreibweise) und SN (S<12 Dezimalziffern>) aufgedruckt. Welche ID muss hier für den Rediscover LEW TelNet geschickt werden? Ist das sie SN ohne führendes S? Das wären nämlich zufälligerweise (?) genau 12 Zeichen.

Du könntest die 4 ersten Zeichen der Modem-ID von Hex in ASCII wandeln, da sollte etwas sinnvolles (also nur Zahlen+Buchstaben) herauskommen. Dann hättest Du eine 12-stellige ID.

Ich kann da natürlich nicht für Dein Zyxel sprechen, aber bei anderen Geräten ist (räusper: war) es so, dass man beim Klonen teilweise diese Umwandlung durchführen musste, weil die Darstellung an verschiedener Stelle sich so unterschieden hat.

Quelle: eigene Notwendigkeit

Zitat von frank_m

Der Einkäufer kauft keine ONTs separat. Siehe unten.

Hm.

Zitat von frank_m

2016 war die Entscheidung für GPON bei den Providern aber längst gefallen. Da war der Gesetzgeber einige Jahre zu spät.

Dann haben die Provider nicht zukunftssicher ausgeschrieben und beschafft.

Zitat von frank_m

Siehste, ein schönes Beispiel, dass deutlich macht, dass die BNetzA es nicht verstanden hat. Der Provider kauft keinen einzelnen ONT. Er kauft die Kombination als OLT und ONT, und es ist Sache des Zulieferers, sich um diese Schnittstelle zu kümmern. Die Komponenten werden passend aufeinander abgestimmt geliefert. Das steht so im Standard, und so machen es die Hersteller, und das kann man einkaufen.

Das Argument bringen ja nichteinmal die Provider vor. Die Argumentieren "nur" damit, dass sie ja alle Kombinationen zertifizieren müssten und das in allen Kombinationen zu aufwendig sei.

Ansonsten:

"Netzbetreiber bezögen bewusst
Komponenten von unterschiedlichen Ausrüstern, um nicht von einem einzigen Lieferanten
abhängig zu werden (Multi-Vendor-Strategie), was die Interoperabilität zwischen Geräten
(OLT wie ONT) unterschiedlicher Hersteller fördere. Das Broadband Forum (BBF) habe mit
dem Zertifizierungsprogramm BBF.247 einen Weg geschaffen, der die Interoperabilität
zwischen OLT- und ONT-Geräten verschiedener Lieferanten darstellbar mache. Dadurch
sichere es Auswahl, Flexibilität und den Schutz vor Störungen der Lieferketten für
Dienstanbieter wie Endnutzer, und zwar auch unter den Bedingungen einer immer
weitergehenden Ausdifferenzierung der Dienste."

Zitat von frank_m

Wie schon des Öfteren erwähnt, arbeitet auch die Telekom mit einer Whitelist.

Das wäre an sich auch nicht unzulässig, solange sie sich nicht weigert, neue/unbekannte Geräte in diese Liste aufzunehmen.

Allerdings ist das für mich derzeit nur eine unbelegte Aussage.

Zitat von frank_m

Lass uns in 5 Jahren schauen, was sich an der jetzigen Situation geändert hat.

Vermutlich nicht viel - wer das jetzt schon erlaubt, wird es nicht verbieten, und die anderen werden sich erstmal auf die Aussage auf "künftige Entwicklungen" berufen um Zeit zu gewinnen - das war ja schon ein ziemlich deutlicher Fingerzeig. Nur mit solchen Aktionen wie derzeit mit der 5690 werden sie kaum noch durchkommen.

Wichtiger ist, dass es jetzt nicht dazukommen wird, dass weitere Provider die Wahlfreiheit einschränken werden.

Zitat von frank_m

Braucht es auch nicht, da die Definition des Endgeräts ja bereits erfolgt ist. Die Referenz ist normativ, nicht informell.

Allerdings ist dabei nicht festgelegt worden, wer die Schnittstelle zwischen den "oder" festlegt. Dass der Provider das bestimmt legt die Definition nämlich auch nicht fest.

Zitat von frank_m

Aber beim Mobilfunk ist das die vorgesehene Endkundenschnittstelle, ist entsprechend standardisiert und wird getestet. Das ist bei der Schnittstelle zwischen ONT und OLT nicht so.

Dann hat der Einkäufer der Hardware bei der Ausschreibung leider etwas falsch gemacht, was ihn spätestens jetzt auf die Füße fällt.

Zitat:

"Die Antragstellerinnen können sich auch nicht darauf berufen, dass die Pflicht zur
Zugangsgewährung am passiven Netzabschlusspunkt für sie nicht vorhersehbar gewesen
sei. Diese Pflicht bestand von Anfang an und wurde nur deshalb nicht problematisch, weil es
am Markt lange Zeit keine integrierten Telekommunikationsendgeräte gab. Wie oben zur
Entwicklung der Rechtslage dargestellt, hatte der Gesetzgeber bereits im Jahre 2016 zu
erkennen gegeben, dass Netztopologien mit gemeinsam genutzten Infrastrukturen keinen
Grund für Ausnahmen von der Zugangsgewährung am passiven Netzabschlusspunkt sind.
Sie hätten sich von Anfang an darauf einrichten müssen, dass sie die gesetzlich
vorgegebene Art der Zugangsgewährung auch faktisch durchführen müssten."

"Hierbei ist zu berücksichtigen, dass der Betreiber des öffentlichen
Telekommunikationsnetzes und Anbieter von öffentlich zugänglichen
Telekommunikationsdiensten verpflichtet sind, Schnittstellenbeschreibungen zu
veröffentlichen, in denen die technischen Anforderungen ihrer Anschlüsse an Endgeräte
offengelegt werden, und diese ständig auf aktuellem Stand zu halten. Die Pflicht ergibt sich
aus Art. 4 der Richtlinie 2008/63/EG (sowie § 74 TKG). Danach müssen die
Schnittstellenbeschreibungen hinreichend detailliert sein, um den Entwurf von
Telekommunikationsendeinrichtungen zu ermöglichen, die zur Nutzung aller über die
entsprechende Schnittstelle erbrachten Dienste in der Lage sind. Der Verwendungszweck
der Schnittstellen muss angegeben werden. Die Schnittstellenbeschreibungen müssen alle
Informationen enthalten, damit die Hersteller die jeweiligen Prüfungen in Bezug auf die
schnittstellenrelevanten grundlegenden Anforderungen, die für die jeweilige
Telekommunikationsendeinrichtung gelten, nach eigener Wahl durchführen können,"

"Sofern die Antragstellerinnen geltend machen, dass die technischen Anforderungen an den
ONT bzw. die von ihm wahrzunehmenden Funktionen zu komplex seien, um sie in
Schnittstellenbeschreibungen abzubilden, ist dem weiter entgegenzuhalten, dass sie selbst
über solche Schnittstellenbeschreibungen verfügen müssen, um geeignete ONT und ggf.
integrierte Geräte für sich selbst einzukaufen. Es ist nicht nachvollziehbar, dass die von
ihnen genutzte Telekommunikationsinfrastruktur für sie selbst eine „black box“ mit nur
teilweise bekannten Eigenschaften sein sollte. Auch ein Hersteller von
Telekommunikationsinfrastruktur hat ein Interesse daran, Leistungen und technische
Parameter seiner Geräte potentiellen Kunden mitzuteilen, weil er ihnen anders nicht
vermitteln kann, dass sein Angebot für sie geeignet sein könnte. Die Anzahl gelisteter
Telekommunikationsendgeräte und Chipsets mit GPON-ONU-Zertifizierung nach BBF.247 ist
ein deutlicher Hinweis darauf, dass eine entsprechende Transparenz der technischen
Anforderungen an OLT wie ONT bzw. Endgeräte mit integrierter ONT-Funktion herstellbar ist
und auch vom Markt gelebt wird. Es ist darum im Folgenden davon auszugehen, dass
sämtliche für die Interoperabilität maßgeblichen technischen Anforderungen formuliert und in
einer Schnittstellenbeschreibung dargestellt werden können."

Die Telekom kann es ja. Wenn es auch nur einer kann, fällt leider das Argument weg, dass es nicht geht.

Zitat von frank_m

Wir sind ein Rechtsstaat. In den anderen Fällen sind sie auch durch Gerichte zurückgepfiffen worden. Erst kürzlich bei den 5G Frequenzen. Ja, war politische Einflussnahme, wurde am Ende aber auch duech die BNetzA verbockt. Genau wie bei der Smartmeter Regulierung.

Ja, der Klageweg steht frei.

Allerdings gibt es hier ein Gesetz, von die Provider eine Ausnahme wollen.

Deine Beispiele folgten keinen Gesetzen, weshalb das als Vergleich ganz schlecht ist.

Zitat von frank_m

Ihr könnt es drehen und wenden, wie ihr wollt. Es wird keine schnelle Lösung für das Dilemma geben

Eine schnellere, als wenn die BNetzA die Ausnahme gewähren würde. Zitat:

"Würde dagegen wegen möglicherweise noch bestehender Unsicherheiten in GPON vom
Grundsatz des Zugangs am passiven Netzabschlusspunkt abgewichen, würde kein Anreiz
mehr bestehen, Interoperabilität, Dienstqualität und Sicherheit der Netze durch technische
Fortentwicklung an endnutzerfernen Netzkomponenten auf einen Stand zu bringen, der
demjenigen in anderen Netzen wie DSL, VDSL- und Kabelnetzen entspricht, weil
Netzbetreiber sich auf ihre Herrschaft über den ONT verlassen würden. Die technische
Entwicklung würde abgeschnitten, und es wäre nicht zu erwarten, dass zukünftig ein Zustand
erreicht würde, der es dann gestattete, von der gewährten Ausnahme wieder abzugehen."

DAS halte ich für den so ziemlich wichtigsten Punkt: würde man jetzt eine Ausnahme gewähren, würde sich an der derzeitigen Situation nie etwas ändern.

Zitat von frank_m

das über eine Whitelist hinausgeht.

Sie dürfen gerne eine Liste getesteter Geräte veröffentlichen:

"Hinsichtlich der von den Antragstellerinnen stark herausgestellten Bedeutung von Tests ist
darauf hinzuweisen, dass Netzbetreiber wie Endgerätehersteller diese Tests auf freiwilliger
Grundlage jederzeit durchführen und werblich einsetzen können. Eine Werbung mit
erfolgreich durchgeführten Interoperabilitätstests würde auch das allgemeine Bewusstsein
für die Bedeutung schnittstellenkompatibler Endgeräte fördern."

Nur müssen sie halt auch andere Geräte zulassen.

Und die Provider sind ja auch nicht unerheblich an dieser Situation selber schuld:

"Der passive Netzabschlusspunkt stellt auch sicher, dass der Endnutzer ein integriertes Gerät
als Eigentümer nutzen kann und nicht auf ein vom Anbieter gemietetes Gerät angewiesen
ist, wenn dieser keine Kaufgeräte anbietet. Nach Angaben der VZ-RlP sei es bei Mietgeräten
häufiger zu überhöhten Schadensersatzforderungen bei der Rückgabe beschädigter Geräte
oder dem Unterschieben von Vertragsverlängerungen beim Austausch von Geräten
gekommen. Solche Risiken werden durch Pflicht zur Zugangsgewährung am passiven
Netzabschlusspunkt vermindert."

Warum fühle ich mich bei den Vertragsverlängerungen an kürzliche Diskussionen hier erinnert?

Zitat von frank_m

Und hast du den Artikel zu Ende gelesen? Schöner hätte ich nicht beschreiben können, warum die Regelung so nicht funktioniert.

Eine Regelung funktioniert nicht, weil sie von den ISPs blockiert wird? Interessante Meinung.

Zitat von frank_m

Nur weil die BNetzA der Meinung ist, heißt das noch nicht, dass es auch den aktuellen Stand der Technik widerspiegelt. Warum sich das Vorhaben der BNetzA auf Basis der aktuellen Normen und Standards nicht so uneingeschränkt umsetzen lässt, wie sie es gerne hätten, hab ich ja an anderer Stelle ausführlich dargelegt.

Und ich habe im Entwurf gelesen, warum die BNetzA der Auffassung ist, dass es funktioniert.

Vereinfacht: die Provider sollen alles offenlegen, was sie benötigen, dann kann es Geräte geben, die die Anforderungen erfüllen. Da es derzeit daran scheitert, das nicht alles offengelegt ist, ist das nicht-Funktionieren eine Folge der fehlenden Spezifikation und damit in der Verantwortung der Provider. Außerdem bezweifelt die BNetzA, dass den Providern selber die Anforderungen nicht bekannt wären: andernfalls können sie ja auch selber keine passenden Geräte beschaffen bzw. zur Beschaffung ausschreiben, und eine Ausschreibung ist nunmal Pflicht.

Es sind also die Provider gefragt, alles offenzulegen. Tun sie es nicht, brauchen sie sich auch nicht beklagen.

Die BNetzA fordert nicht, dass an einem Anschluss jedes Gerät funktionieren muss. Sie fordert, dass alle nötigen Informationen veröffentlicht werden, dass ein Gerätehersteller an diesen Anschluss funktionierende Geräte herstellen kann.

Zitat von frank_m

Nein, meine Bedenken nicht. Darauf sind sie nicht eingegangen. Das war auch nie Gegenstand des Verfahrens. Was nicht heißt, das es nicht trotzdem relevant ist.

Und wie gesagt: nur weil sie der Meinung sind, heißt das nicht, dass es den Stand der Technik widerspiegelt. Sie sind oft genug zurückgepfiffen worden. Schau dir mal die Smart Meter Gesetzgebung an.

Es wird hier kein "zurückpfeiffen" geben. Kurz: manche Provider wollten die Regeln ändern lässen, die BNetzA akzeptiert die Gründe nicht. Damit sind die Provider zurückgepfiffen worden, nicht die BNetzA, weil die in diesem Fall gar nichts ändert.

Zitat von frank_m

Nein, das ist leider eindeutig. Die Verordnung (EU) 2015/2120 fordert in Paragraph (5),

Nein. Die 2015/2120 hat nur Artikel und keine Paragraphen, aber was Du da zitierst, ist kein kein Teil der Verordnung, sondern nur ein Erwägungsgrund, welcher bei der Erstellung eingeflossen ist. Das ist etwas anderes. Weiter herunterscrollen hilft, wenn man die Verordnungen lesen will.

Relevant ist da Artikel 3 Satz 1. Der enthält aber die Referenz auf die Verordnung 2008/63 nicht.

Zitat von frank_m

Nur weil die BNetzA der Meinung ist, heißt das noch nicht, dass es auch den aktuellen Stand der Technik widerspiegelt. Warum sich das Vorhaben der BNetzA auf Basis der aktuellen Normen und Standards nicht so uneingeschränkt umsetzen lässt, wie sie es gerne hätten, hab ich ja an anderer Stelle ausführlich dargelegt.

Die BNetzA schreibt allerdings auch, wie sich das umsetzen lässt und warum sie die Aussage, warum es sich nicht umsetzen ließe, nicht gelten lässt.

Es mag sein, dass Du das an anderer Stelle dargelegt hast, aber die BNetzA hat das alles widerlegt.

Zitat von frank_m

Ins Netz dürfen die Geräte, von denen man sicher weiß, dass sie zumindest für die anderen Teilnehmer im gleichen Segment keinen Ärger machen. So viel hat man aus den Rückwegstörern im Kabelnetz gelernt.

Das sieht die BNetzA in ihrem Entscheidungsentwurf anders und sie geht dort u.A. auf das Thema Rückwegstörer in dem Entwurf ein.

Auch wenn Dir das nicht gefallen wird, auf alles, was Du hier zu Fremd-ONT bisher vorgebracht hast, geht die BNetzA ein und sieht es nicht als Grund, bei ONTs eine Ausnahme von der Endgerätefreiheit zuzulassen.

Nur Geräte von einer Whitelist freizuschalten ist definitiv nicht zulässig (die Stellungnahme ist ja nur eine Klarstellung des Ist-Zustandes, keine neue Regelung)

Zitat von frank_m

Also entweder hab ich die Funktionsweise des Servers nicht verstanden, oder du hast kein Problem.

Er schreibt zur Zertifikatserneuerung. Also vermutlich LetsEncrypt, und die wollen zur Zertifikatserneuerung den Server über HTTP Port 80 und über den im Zertifikat eingetragenen Namen erreichen.

Zitat von frank_m

Wenn der Server nach draußen telefoniert, hast du auf jeden Fall eine ausgehende Verbindung, auf der die angesprochenen Gegenstellen antworten können. Das ist auch bei CGNAT kein Problem, dafür gibt es Connection Tracking in den Firewalls. Allerdings ist das eher die Arbeitsweise eines Clients, nicht eines Servers.

Der Server "telefoniert" also nach außen z.B. zu LetsEncryt und sagt LetsEncrypt "Du kannst bei mir auf Port 80 verifizieren, dass ich es bin". Dazu nutzt er den lokalen Webserver (oder startet temporär selber einen auf Port 80), über den LetsEncrypt dann per HTTP einen Key zur Verifikation holt und so die Richtigkeit sicherstellt.

Da hilft Connection Tracking nicht wirklich, das ist eher mit FTP zu vergleichen. Die bestehende Verbindung will LE da genau nicht verwenden, es will ja selber verifizieren.

Und wenn er sonst nur per Wireguard zugreift, hilft das an dieser Stelle nicht, denn LetsEncrypt prüft natürlich die Erreichbarkeit des ausgestellten Zertifikats im öffentlichen Internet und nicht im VPN.

Lösung wäre neben einem wie schon beschriebenen Tunnel nur noch, das Zertifikat über DNS verifizieren zu lassen, aber dazu braucht man automatisierten Zugriff auf seinen DNS und eine eigene Domain.

Zitat von Bracew

VPN über

Eben, "über". Das "Über" will ich vermeiden, weshalb ich noch auf eine öffentliche, gerne dynamische, IPv4 Wert lege.

Zitat von HubeBube

Willkommen im Forum!

Mit geänderten (IPv6-) Präfixen sollten jedoch alle Devices im internen Netz zurechtkommen.

Wo klemmt es denn?

Schreibt er doch: interne Verbindungen.

Zum Beispiel eine Verbindung mit dem NAS. Da bekommt der Client nicht unbedingt mit, dass die IP des Ziels sich ändert und er deswegen die Verbindung neu aufbauen müsste.

Lösung wären zusätzliche feste interne private IPv6-Adressen zu vergeben. Aber das muss man manuell machen, spätestens mit mehreren internen Netzen reichen die link-local-Adressen dafür nicht aus.

Zitat von kerneltask

Dann besorg dir am besten eine richtige v4 via GRE Tunnel, oder verwende IPv6 für das VPN..

Bei GRE brauchst Du aber erstmal eine Gegenstelle, mit der Du Dich verbindest. Dann das Routing manuell einstellen, dass nur die VPN-Verbindung zur Arbeit über den Tunnel geht, der Rest ins Internet nicht. Das willst Du jemand zumuten, der nicheinmal weiß, ober er eine IPv4 braucht?

Das zweite ist keine Lösung, sitz' mal im Hotel und versuche Dich mit Zuhause zu verbinden, wenn Du Zuhause nur IPv6 hast und das Hotel nur IPv4.

Zitat von e16

Koax als Medium weiter zu nutzen mag technisch gehen, am Ende bleibt es eine wackelige Bastelei. Ich weiß wovon ich rede. Habe lange gebraucht, auf 12-adrigen Telefonkabeln stabiles Gigabit Ethernet zum laufen zu bekommen.

Prinzipiell ist eine neue Ethernetverkabelung immer vorzuziehen, aber wenn das warum auch immer nicht geht oder wirtschaftlich umsetzbar ist, dann willst Du hoffentlich nicht Koax und Telefondraht vergleichen. Telefondraht ist vielleicht für Brandbreiten von einigen MBit geeignet (DSL geht bis 250 MBit), während Koax durch seinen Aufbau schon für mehrere GBit geeignet ist (und bei Internet über TV-Kabel ja auch genutzt wird). Deine Erfahrungen mit Telefondraht auf Koax zu übertragen ist falsch. Und beides ist noch besser als jegliches WLAN, Koax ist da eher mit zwei direkt verbundenen WLAN-Antennen vergleichbar: WLAN ohne Störung von außen und mit langer Entfernung. Warum sollte es vom Provider zum Kunden mehrere GBit können, aber wenn es davon abgetrennt wird, im kürzeren Stück beim Kunden plötzlich wackelig sein?

Es hat nur den Nachteil, dass die Umsetzer Geld kosten, Strom verbrauchen und das Kabel nicht mehr einfach für TV oder Kabelinternet nutzbar ist.

Altes RG-58-Ethernet ist auch Koax, wäre problemlos auch auf mehr als 10 MBit aufzubohren gewesen. Nutzt heute nur keiner mehr, weil es andere Nachteile hat (Kette statt Baum)

Hallo,

leider fehlt die Info, ob es sich um ein Einfamilien- oder Mehrfamilienhaus handelt. Ich gehe mal von einem Einfamilienhaus aus.

Zitat von HubeBube

Ja, aber nur, wenn Du auf KabelTV und Internetzugang via Kabelmodem verzichtest.

Mit der Verwendung von MOCA-Adaptern (nicht bei G.hn-Adaptern) und einen Tiefpassfilter am Hauseingang des TV-Kabels könnte man zumindest Kabel-TV weiternutzen. Internetzugang via TV-Kabel wäre nicht mehr nötig, da das ja per Glasfaser verfügbar wäre. Gilt natürlich nur im EFH und wäre etwas für einen Fachmann.

Wenn über mehrere Accesspoints im Haus nachgedacht wird, sollte der Router im Keller stehen, da wie schon oben geschrieben WAN und LAN im selben Kabelnetz schwierig ist.

Wenn man sich mit VLANs und deren Konfiguration auskennt könnte man das zwar machen, aber der Router im Keller ist einfacher.

Die Nutzung eines ansonsten unbenutzten und vom öffentlichen Kabelnetz getrennten TV-Kabels zur Verteilung des LANs im Haus ist unproblematisch, läuft bei uns mit G.hn-Adaptern (da kein TV-Signal mehr vorhanden, s.o.). Router im Keller, von dort per TV-Kabel und G.hn-Adapter zu einer Fritzbox als Mesh-Client in jedem Stockwerk. Fritzboxen, weil gebrauchte 7520 billiger zu bekommen sind als Fritz-Repeater und dafür völlig ausreichen

Zitat von HubeBube

Ja, das gilt sogar für Provider-ONT plus Mietrouter, siehe TKG §3 "Begriffsbestimmungen".

Und noch einmal, es wurde ein Vertrag über ein Mietrouter abgeschlossen, da gab es weder Zwang (sofern der Vertragsnehmer nicht zum Abschluss in einer von ihm ungewollten Art bedrängt wurde) noch sind Zugangsdaten notwendig.

Das ist egal, die Zugangsdaten sind notwendig, wenn er ein eigenes Gerät anschließen möchte.

Die Verpflichtung die Daten mitzuteilen steht im selben Abschnitt, in dem zwei Sätze vorher geschrieben wird, dass dem Kunde der Anschluss eigener Geräte nicht verweigert werden darf. Eine weitere Abhängigkeit zu irgendetwas anderem steht in dem Abschnitt nicht. Es steht also eindeutig im sachlichem Zusammenhang zu eigenen Geräten.

Zitat von Ralf75

Nein ich kann das ONT nicht mehr nutzen. Das ging nur als der Techniker da war. Der hat sich das telefonisch hin und her stellen lassen als wir getestet haben.. Wenn ich mich da melde und ne Umstellung will, dauert das 3-5 Tage . Bei Ihm 30 Sekunden

OK schade, damit hat sich meine Antwort von gerade erledigt - hat sich überschnitten.

Hast Du überprüft, dass die 7530 der DGN dieselben Login-Daten für den PPPoE-Login erhält, wie Sie Dir per Brief mitgeteilt haben und Du dann in der 5530 einträgst? Trage die Zugangsdaten, die Du in der 5530 einträgst, mal in der 7530 ein, falls die 7530 automatisch konfiguriert wird/wurde und Du das noch nicht getestet hast.

Von dem Login hängt das Dir zugeordnete Profil ab, und bei der DGN gab es bei uns da Probleme. Zwar andere als bei Dir, aber die DGN scheint da Probleme mit der richtigen Provisionierung der Zugangsdaten zu haben

Zitat von HubeBube

Das ist ein Verstoß,

Nein.

"Sie können dem Endnutzer Telekommunikationsendeinrichtungen überlassen, dürfen aber deren Anschluss und Nutzung nicht zwingend vorschreiben."

Zitat von HubeBube

Hierfür sind keine Daten zur Einrichtung mehr notwendig und in Folge müssen diese dann auch nicht mitgeteilt werden.

Doch, siehe obigen Satz. Die Nutzung des bereitgestellten Routers darf nicht vorgeschrieben werden, daher weiß der Provider nicht, ob der Kunde die Daten braucht oder nicht. Damit ist es notwendig, diese mitzuteilen.

Zitat von Phino

Na ganz pragmatisch.

Der Kunde bekommt den Mietrouter oder die Daten. Ein Problem ist es doch erst, wenn er sie nicht raus gibt.

Mietrouter und Daten.

Zitat von Phino

Bei meinem ISP DNS:NET gibt es immer den Brief und es steht alles hübsch auf der Internetseite, auch SIP. Sind nicht alle böse.

Alle normalen Provider schicken die Daten, das würden sie kaum machen, wenn diese der Meinung wären, es wäre nicht vorgeschrieben.