GPON SFP Deutsche Glasfaser

Also hier:

sieht das so aus:

Zitat

III. Add ONT / ONT register
Add ONT to interface
typ:isadmin>configure#configure equipment ont interface 1/1/4/2/1 sernum ALCL:F8237F51 sw-ver-pland 3FE56557AFFA61
[1/1/4/2/1 rack/shelf/slot/pon/ont-id]

d.h. jeder ONT muss individuell registriert werden, da kann man sicher auch andere Werte ueberpruefen...

Zitat von pufferueberlauf

d.h. jeder ONT muss individuell registriert werden, da kann man sicher auch andere Werte ueberpruefen...

Die SW Planned muss nicht angegeben werden. Auch ein paar Andere Dinge sind Providerspezifisch, gerade der VPLS wird zumindest bei uns nicht genutzt.

kingpin42 Weitere Infos sind dringend erwünscht

Beitrag

RE: GPON Whitelist Deutsche Glasfaser

Achtung: es kann pro Fritz-Typ unterschiedliche Versionen (Hardware Revision) geben!
5530: 257
5590: 272,273
5690 Pro: 279

Und die Softwareversionen der 5530: ab 7.26 alle mir bekannten

5590: ab 7.29 alle mir bekannten

5690 Pro: bei DG aktuell keine

HubeBube

25. Oktober 2024 um 10:37

Wüsste nicht, wo ich da helfen könnte. Arbeite nicht für die DG und kenn ihren Aktivierungsprozess auch nicht.

Zitat von Gruni22

Bei der DG ist es einfach.

Versteckt sich alles in den OMCI MEs 7, 256 und 257

Equipment ID - max. 20 Zeichen

Hardware Version - max. 14 Zeichen

Software Version - max. 14 Zeichen

Seriennummer - 8 Byte

Hersteller ID - 4 Buchstaben

wird gebraucht.
Die Mac Adresse nur, wenn man nicht ne Stunde warten will.

Alles anzeigen

Hardware Version und Software Version halte ich für beliebig. Muss vorhanden sein, wird ausgelesen, jedoch nicht validiert.

Meinst Du mit Hersteller ID die Vendor ID/ME #256 vendor ID attribute, vendor id of ONU-G OMCI ME (4 byte) | first 4 chars of gpon_serial/Modem-ID? Halte ich auch für nicht unbedingt notwendig, da diese aus der Seriennummer abgeleitet werden kann. Ich bin mir nicht sicher, ob diese ME validiert wird.

Ich habe mal ein wenig "educated googling" betrieben. Der zuerst genannte Link ist 3 Jahre neuer als der weiter unten stehende und in diesem Thread bereits genannte!

How to check ONT service operation mode

NOKIA ISAM 7360

typ:admin># show equipment ont interface 1/1/1/2/33 detail

ont-idx : 1/1/1/2/33

eqpt-ver-num : HL-4G_001

sw-ver-act : V2.0.13

sw-ver-psv : V2.0.13

vendor-id : HW

equip-id : HL-4G

actual-num-slots : 3

version-number : HL-4G_001

num-tconts : 16

num-trf-sched : 16

num-prio-queues : 160

auto-sw-planned-ver :

auto-sw-download-ver :

sernum : HALN:206EB8D8

yp-serial-no : unknown

oper-spec-ver : ctc-v2.0

act-ont-type : hgu

act-txpower-ctrl : not-supported

sn-bundle-status : idle

cfgfile1-ver-act :

cfgfile1-ver-psv :

cfgfile2-ver-act :

cfgfile2-ver-psv :

actual-us-rate : 1.25g

**************************************************

Configure Step NOKIA 7360 FX-4

typ:isadmin>#show equipment ont interface

ont-idx : 1/1/4/2/1

eqpt-ver-num : 3FE56525AAAA01

sw-ver-act : 3FE56557AFF*

num-slots : 2

version-number : 3FE56525AAAA01

sernum : ALCL:F8237B88

yp-serial-no : F8237B88

**************************************************

Alles oben geschriebene gilt im Kontext der Provisionierung eines GPON SFP-Modules oder eines ONTs in die GPON-Topologie (Nokia OLT) von Deutsche Glasfaser.

Hersteller Id und Hardware Version mag beliebig sein.
Mit der falschen Software Version hatte ich noch keinen Erfolg. Zumindest nicht beim G-010-Q Klon.
Wahrscheinlich wird dann immer versucht die upzudaten. Das ONT startet dann nämlich ständig neu.

Ja, daher ist mein Ansatz auch der eine Fritze zu simulieren, anstatt einen Klon des Provider ONTs anzufertigen.

Genau der von dir beschriebene Sachverhalt kann beim Klonen des Provider ONTs auftreten. Dies war auch stets die von frank_m und anderen geäußerten Bedenken beim Cloning.

Jetzt wo die Fritzbox simuliert ist kann ich theoretisch mit den Versionen spielen.
Ich versuche mal einen absurden Wert und siehe da... völlig egal. Habe meine Tabelle aktualisiert.

Laut einem Kontakt wird die Version nur bei gewissen Modellen geprüft…
Das untermauert den Verdacht.

Sind die "gewissen Modelle" Fritzen ?

So groß ist die Auswahl ja nicht und was bedeutet geprüft? Ist das eine Validierung nach dem Motto "Version ist gleich" (halte ich für fatal) oder "Version ist größer oder gleich"?

Die gewissen Modelle, können eigentlich nicht die Fritzen sein sondern nur die Geräte, die vom Provider ausgeliefert werden. Denn nur da, kann ja der Provider die Softwareversionen steuern und kennt diese auch bereits vorher.

Habe nun diese Config und es funktioniert:
Model F!Box5590
Hardware Version F6005V6.0
Software Version V6.0.10N20

Nochmals in Schriftform: Vielen Dank für deine umfangreichen Tests und vor allem für die Mitteilung der Ergebnisse!

Und nun Stelle ich mir die Frage, warum Deutsche Glasfaser nicht in der Lage ist diese Informationen mitzuteilen? (OK, ist wohl eine rhetorische Frage).

Das ist doch kein Hexenwerk. Das Reverse Engineering ist jedoch extrem zeitaufwändig.

Zitat von HubeBube

Und nun Stelle ich mir die Frage, warum Deutsche Glasfaser nicht in der Lage ist diese Informationen mitzuteilen?

Wofür kann man die Information denn gebrauchen? Um obskure SFP Module ins Netz zu holen, die normalerweise nicht reinkämen. Nicht im Sinne des Providers.

Genau so wird es sein… aber da ist ja noch das Heiß gekochte TKG mit dem Thema passiver Netzabschluss und das der Provider verpflichtet ist diese Infos bereitzustellen.

Da bin ich skeptisch. Das TKG sieht vor, dass Zugangsdaten für zugelassene und kompatible Endgeräte zur Verfügung gestellt werden. Dass irgendwelche SFP Module per Cloning andere Geräte vorgaukeln, ist damit wohl nicht abgedeckt.

Meine Interpretation des passiven Netzabschlusses ist eher, dass der ISP jenseits von generischen kompatibilitaetsanforderungen an ONTs, bestenfalls eine Denay-List fuehren darf mit Model/Software Kombinationen die als inkompstibel bekannt sind... Aber ohne einschlaegiges Gerichtsaurteil zu dem Thema ist mir schon klar wie irrelevant meine Meinung da fuer die Realitaet ist

Zitat von frank_m

Da bin ich skeptisch. Das TKG sieht vor, dass Zugangsdaten für zugelassene und kompatible Endgeräte zur Verfügung gestellt werden. Dass irgendwelche SFP Module per Cloning andere Geräte vorgaukeln, ist damit wohl nicht abgedeckt.

Dem TKG nach müssen die Zugangsdaten unabhängig vom Endgerät bereitgestellt werden. Es gibt kein "zugelassene". Für "kompatibel" muss der Provider die Anforderungen benennen.

Cloning ist Notwehr gegen Provider, die das nicht wahrhaben wollen und wäre unnötig, wenn die Provider damit korrekt umgehen würden.

So ist es Elemir, welche Geräte "zugelassen" sind bestimmt nicht der Provider, sondern der Gesetzgeber des jeweiligen EU Landes (in unserem Falle).

Zitat von HubeBube

So ist es Elemir, welche Geräte "zugelassen" sind bestimmt nicht der Provider, sondern der Gesetzgeber des jeweiligen EU Landes (in unserem Falle).

Doch, im Endeffekt legt das trotzdem der Provider fest. Siehe Vodafone damals beim TC4400. Da wurden erst im Nachgang die Spezifikationen geändert, weil das System von Vodafone ein Tabulator-Zeichen, das in einem String vom TC4400 gesendet wurde, nicht akzeptierte, obwohl es laut Standards in Ordnung gewesen war. So wird das auch bei ONTs passieren, die sich aus welchen Gründen auch immer, nicht provisionieren lassen.

Und das muss auch sein gutes Recht bleiben, um die Versorgungssicherheit zu gewährleisten. Daran kann und darf ein TKG nichts ändern, sonst verfehlt es seinen Zweck.

Zitat von kingpin42

Doch, im Endeffekt legt das trotzdem der Provider fest. Siehe Vodafone damals beim TC4400. Da wurden erst im Nachgang die Spezifikationen geändert, weil das System von Vodafone ein Tabulator-Zeichen, das in einem String vom TC4400 gesendet wurde, nicht akzeptierte, obwohl es laut Standards in Ordnung gewesen war. So wird das auch bei ONTs passieren, die sich aus welchen Gründen auch immer, nicht provisionieren lassen.

Naja, ich wuerde dass jetzt nicht als beabsichtigtes Aussperren interpretieren sondern halt ein Fehler wie er schon mal vorkommt und der moeglicherweise etwas Zeit zur Diagnose und zur Behebung braucht. Die BNetzA erweckt auf mich den Anschein in solchen Faellen eher mit ihrem "Partner der ISPs" Hut zu handeln und ist da sehr nachsichtig. Und ich wette das wird bei GPON so bleiben... d.h. nur wenn nachweislich und absichtlich ohne gute Begruendung (wie ONT Typ/Revision inkompatibel mit OLT) gesperrt erwarte ich Gegenwind durch die BNetzA.