Mir geht es um den Fall, in dem die Systemzeit des IADs, warum auch immer, 1 - 30 Sekunden von der gesetzlichen Uhrzeit abweicht.
Üblicherweise kann man bei den IADs einen NTP-Server als Zeitquelle angeben, dies sollte man auch tun. Damit haben sich die Abweichungen erledigt, es sei denn die verbaute Hardwareuhr ist grottig.
Versuch macht klug. Zweimal im Jahr hast Du die Möglichkeit herauszufinden, wie während der Zeitumstellung IAD und Provider reagieren.
Da es verschiedene Methoden zur Angleichung der Uhrzeit gibt, hängt dies stark von der Implementierung im IAD ab.
Das kein SIP/VoIP Anbieter etwas zu verschenken hat, sollte man sich bewusst sein. Eine Entkopplung vom Anbieter für den Internetaccess hat durchaus einen Mehrwerte, der "nomadischen Nutzung" lautet. Ganz abgesehen von der freien Verfügungsmöglichkeit der Festnetznummer.
Klar ist jedoch auch, das man mit so einer Vorgehensweise für das Vertragsmanagement selbst verantwortlich ist. Ein wenig erhöhten Aufwand hat man damit schon.
Allerdings kann man auf der "Haben-Seite" verbuchen, das man immer den günstigsten Internetaccess-Tarif verwenden kann. Damals habe ich einen 400/200 Tarif gebucht, weil es der günstigste Tarif mit Telefonflat war. Von dem Bandbreitenbedarf hätte jedoch der ehemals kleinste 300/150 Tarif mehr als ausgereicht.
Das ist jedem Provider überlassen. Bei Deutsche Glasfaser ist das in "Technical Specification – DG – GPON / XGSPON" beschrieben. In der Version vom 22. Mai 2024 steht folgendes: DHCPv4 und DHCPv6.
Lease Time ist eine Stunde.
Das PDF ist abseits dessen ganz interessant, da HÜP, Gf-TA (ja wirklich!) und ONT (verschiedene Formfaktoren, auch SFP Module!) Erwähnung finden.
Technical_Specification_ DG_xPON_1.2_en_public.pdf
Für die AON-Topologie gibt es das ebenfalls: Technical_Specification_ DG_P2P_1.2_en_public.pdf
Ganz schlüssig ist das nicht, da der WLAN-Teil auch ein eigener SoC ist. Wie wir wissen kann dieser auch separat ein Update erhalten, hat jedoch keine Hardware-ID. Wie dem auch sei, es ist müßig darüber zu diskutieren. Mein Seelenfrieden ist mit dem "es ist so wie es ist" in diesem Falle wiederhergestellt.
Ich hatte einen Knoten im Hirn, sorry.
Natürlich muss der Client in der Lage sein je nach Ziel/Kommunikationspartner die richtige IPv6 Adresse zu verwenden. Vor allem dann, wenn mehrere IPv6 Adressen dem Client zugewiesen sind.
Ja der "normale Nutzer" denkt jedoch er könne die Nummer nur zu dem neuen ISP mitnehmen. Der Clevere lässt diese zu einem unabhängigen Anbieter portieren.
Der clevere Nutzer unter uns kann dann ja munter hin und her wechseln, wenn ihm die IP Adresse egal ist, und er im Besten Fall einen komplett externen E-Mail Account hat, wie z.B. - Web.de, o.ä.
Nicht zu vergessen die Portierung der Festnetznummer zu einem SIP/VoIP Anbieter, der ein anderer ist als der Internetaccess-Anbieter.
Leider verfällt auch heise der Effekthascherei bei Überschriften. Wer den Artikel liest, würde "IPv6-Einführung wohl obsolet" abändern in "vollständige Ablösung von IPv4 durch IPv6 nicht notwendig".
Nachtrag: pufferueberlauf war schneller.
Zumal die ULA Bereiche auch bekannt sind und WAN-seitig immer dem Global-Scope weichen sollten, ja sogar müssen. Aber was soll's, zumindest bei ChromeOS und damit sicher auch bei Android (durch Analogieschluss bei Google) ist das Problem behoben.
Wenn der HÜP über eine dem Kunden zugängliche Buchse verfügt bin ich geneigt dies als dem TKG konformen passiven Netzabschluss zu betrachten:
Dieser Zugang ist ein passiver Netzabschlusspunkt; das öffentliche Telekommunikationsnetz endet am passiven Netzabschlusspunkt.
Ist diese funktionierende und frei zugängliche Buchse nicht vorhanden, dann ist der Provider verpflichtet diese zu liefern, sei es wie bei EWE nachträglich. Dies verursacht Aufwände bei dem Kunden und Anbieter.
Was ich jedoch überhaupt nicht nachvollziehen kann, wenn bereits ein Fibertwist montiert ist und die Realisierung des passiven Netzabschlusspunktes (Gf-TA/Glasfaser-Dose) durch simples aufdrehen eines F2110 oder F2115 "Deckels" auf die Badeplate/FMU möglich ist, die Provider so tun, als kennen sie weder die gesetzliche Verpflichtung noch die technische Möglichkeit.
Viel Ärger, Beschwerden bei der BNetzA und unzufriedene Kunden sind die Folge. Ganz abgesehen von eventuellen Basteleien direkt an der FMU. Alles nur, weil man den billigen Plastikdeckel nicht beilegt.
Ich warte auf den Tag, dass jemand einen Sketch für den 3D-Druck hierfür veröffentlicht.
Nur eine Anmerkung: Ich würde keine "GO Box 100" mehr anschließen, diese wurde durch die "IP Base" ersetzt.
Eine einzige Ausnahme: wenn ich dieses Modell geschenkt bekommen würde. Es wird für die GO Box 100 keine Updates mehr geben.
In Bezug auf die IP Base: es gibt da einmal lediglich die Basisstation, als auch Bundles mit verschiedenen DECT Telefonen. Eine Kompatibilitätsliste gibt es ebenfalls: https://service.gigaset.com/de/support/sol…sis-kompatibel-
Willkommen im Forum!
Stimmen denn diese Daten noch?
Kannst Du uns mitteilen, woher Du das Oberteil F2115-2 des Genexis Fibertwists bezogen hast? Die Frage hiernach taucht immer mal wieder auf und eine generelle Bezugsquelle scheint es nicht zu geben. 30€ bei eBay ist nun auch wirklich überteuert.
frank_m Die von dir gepostet traceroute6 Ausgabe abgehend von init7 in #46 stoppt bei dir beim Eintritt in das Netz von DG immer noch? Bei mir nicht:
1 2a02:168:6229::1 ICMPv6: Time exceeded
2 2a02:168:2000:11::1 ICMPv6: Time exceeded
3 2a00:5641:f7::374 ICMPv6: Time exceeded
4 2001:1620:2::c2 ICMPv6: Time exceeded
5 2001:1620:2::b9 ICMPv6: Time exceeded
6 2001:1620:2::9e ICMPv6: Time exceeded
7 2a00:5641:118::1 ICMPv6: Time exceeded
8 2a00:5641:117::5 ICMPv6: Time exceeded
9 2001:438:ffff::407d:1efe ICMPv6: Time exceeded
10 2001:438:ffff::407d:1d41 ICMPv6: Time exceeded
13 2a00:6020:0:b::2 ICMPv6: Time exceeded
14 2a00:6020:ffff:ffff::12 ICMPv6: Time exceeded
15 2a00:6020:ffff:ffff::12 ICMPv6: Time exceeded
16 2a00:6020:1000:d1::ghjk ICMPv6: Communication with destination administratively prohibited
Nachtrag: das Bildchen eingefügt
Die Endgerätefreiheit gibt es nicht erst seit 2016. Sie wurde nur 2016 eindeutiger in einem Gesetz abgefasst.
Die ersten Regelungen zu diesen Thema gab es bereits 1988,
Hast Du eine Quelle hierfür? Ich kann mich ganz schwach daran erinnern, das Ende der 80er auch kundeneigener Telefone angeschlossen werden durften. Das war noch vor der Förderung in Höhe von 700 DM für ISDN-Telefonanlagen für Privatkunden?
Das die Hardware sich unterscheidet ist klar, warum dann jedoch im Falle der 5590 zwei ProductIDs verwendet werden, leuchtet mir immer noch nicht ein. Der SoC (Falcon) erhält in der 5590 die HardwareID 272 und in der 5530 die ID 257.
In deiner grundsätzlich Aussage weiter oben stimme ich dir zu. Ich habe #2 entsprechend korrigiert.
Evtl. ist ja mein Verständnisproblem auch gar nicht logisch auflösbar. Dann nehme ich das einfach so hin. Auch das Nummerierungsschema der FRITZ!Boxen wird von AVM nicht konsequent eingehalten.
Ich denke auch, dass wir mit einer pragmatischen Lösung am weitesten kommen. Mal ehrlich, für wie viele Kunden ist das SFP+ Modul von TEMU für den OpenWRT Router aus China denn wirklich ein K.O-Kriterium? Mit einer Handvoll relevanter Endgeräte wär die Diskussion vermutlich erledigt.
Ja, hier stimme ich dir zu. Pragmatische Lösungen sind gefragt, Verständnis für die Kundenwünsche und vor allem operative Exzellenz. Der Kund hingegen darf sich auch nicht in der Rolle als Wutbürger gefallen und cholerisch ins Telefon schreien (bildlich gesprochen), sobald es die kleinste Unzulänglichkeit auftritt.
Dennoch gefällt mir das Kleinreden oder ins lächerlich Ziehende nicht. Gerade die Kunden, die OpenWRT, MikroTIK oder OPNSense nutzen, sind diejenigen, welche auf Qualitätshardware achten.
Es wäre ein enormer Fortschritt, wenn die stetig wachsende Liste der BBF.247 zertifizierten Hardware bei allen TK-Providern mit GPON-Topologie problemlos zu provisionieren wäre. Idealerweise als Self-Service durch den Kunden.
Das war an jan gerichtet. Ja, für die Provisionierung spielt das keine Rolle, jedoch für meinen Seelenfrieden
.
jan mal etwas anderes: die Support-Datei von FRITZ!OS 8.00 enthält ja das Base64 kodierte und tar + gzipte 8 GB große AVM_TFFS. Kennst Du ein unter Windows lauffähiges Tool, welches mir vergleichbar mit fritz_tffs_read die Key/value Paare ausliest? Bitte als Windows exe.
Ich möchte mich ungern durch Peter Pawns YourFritz und EvaTools durcharbeiten.
Gut, dann eine Verständnisfrage: Warum hat eine 5530 die HW Revision 257, obwohl sie nur den Falcon Prozessor (Modemteil) beinhaltet?
Aus https://boxmatrix.info/wiki/FRITZ%21Box_5590_Fiber
HWRevision: 272 - HWSubRevision: 2
ProductID: Fritz_Box_HW272, Fritz_Box_HW273
Verstehe mich bitte nicht falsch, ich versuche lediglich eine Systematik zu erkennen.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
