Glasfaser GPON Modul / DEC 750 SFP-Ports / Leistung & Link Speed

[genfai]

Das Konzept von netto ist mir jetzt schon bekannt. :D Ich hatte das nur noch nie im Zusammenhang mit Zugangsdaten gehört. :)

Also im Prinzip, dass neben der Seriennummer als direkte Antwort noch etwas übertragen wird. Da wäre es vermutlich interessant, den OLT zu erfahren. Ich könnte mir vorstellen, dass das dann weniger mit dem Internetanbieter als mehr der Umsetzung des Herstellers des OLT zu tun hat. Bei meinen eigenen Recherchen hatte ich bei Huawei gelesen, dass die Huawei OLT nur das Passwort und die Vendor-ID (die ersten 4 bzw. 8 Stellen) prüfen, den Rest der Seriennummer aber ignorieren. Die Vendor-ID wird wiederum deshalb geprüft, weil der Betrieb von Dritt-ONT extra lizenziert werden muss. Es wäre ja nicht undenkbar, dass andere Hersteller hier noch andere Mechanismen nutzen.

Was die Modem-ID betrifft, hätte ich sofort gesagt, dass das Synonym für Fiber-ID, Home-ID oder auch Seriennummer ist. So wie auch Password/PLOAM/SLID identisch sind. Weiterhin wird meines Wissens nach beides unabhängig der erforderlichen Eingabe letztendlich in HEX übertragen. Ich kann aber beides natürlich nicht belegen. Das bezieht sich auch nur darauf, was ich dazu irgendwo im Netz gelesen habe. Allerdings musste ich die 16-stellige Seriennummer meines ONT auch in die ASCI/HEX-Schreibweise sowohl des Lancom- als auch des Zyxel-Moduls konvertieren. Die steht dort übrigens tatsächlich als Seriennummer bezeichnet einfach auf der Rückseite.

Das M-Net anscheinend zwischen Seriennummer und Modem-ID unterscheidet, finde ich hochinteressant. Möglicherweise ist das in Anbetracht der unterschiedlichen Nomenklatur nur ein Kommunikationsproblem und meint bei denen den Modemtyp/SKU. Aber das klärt sich bestimmt bei Deinem Termin.

Wenn ein anderer ONT einfach läuft, würde ich das Thema MAC auch erst mal verwerfen.

Ich musste jetzt erst mal lesen, was genau man mit OMCI machen kann. Vorweg: Extrem interessant. Hatte ich mich nicht mit beschäftigt, weil bei mir nicht erforderlich. Aber wenn der Anbieter sich hier nicht mit einer einfachen Authentifizierung zufrieden gibt, sondern irgendetwas konfigurieren oder auslesen will, gibt es natürlich unendlich viele Bruchstellen. Das mit der OMCC-Version und der Verschlüsselung würde ich aber völlig untechnisch für nicht sehr wahrscheinlich halten. Ich habe da jetzt eine Weile gegoogelt und mir von mehreren Seiten erklären lassen, was da möglich ist und wie das in etwa funktioniert. Und es wird in diesem speziellen Kontext nirgendwo etwas erwähnt wie "funktioniert erst ab Version xy" oder "achten sie auf Kompatibilität". Im Grunde habe ich nur den Computerbase-Thread und diesen hier gefunden. Klar, das ist kein Beleg für gar nichts... :)

Aber hier mal etwas Schlichteres in den Raum geworfen:

https://hack-gpon.github.io/gpon-auth/

"Fake O5 Status

This known issue with Alcatel/Nokia OLT giving fake O5 ONU Status, OLT will hold OMCI Provisioning until correct OMCI Information

It happens when the OLT detects that the ONT is drunk. And try to update the firmware before opening the GEM link. One must try to change the software version or other data."

OLT will Update anstoßen/prüfen, ONT/GPON-Modul versteht es nicht und Tilt.

[meyergru]

Bei meinen eigenen Recherchen hatte ich bei Huawei gelesen, dass die Huawei OLT nur das Passwort und die Vendor-ID (die ersten 4 bzw. 8 Stellen) prüfen, den Rest der Seriennummer aber ignorieren. Die Vendor-ID wird wiederum deshalb geprüft, weil der Betrieb von Dritt-ONT extra lizenziert werden muss. Es wäre ja nicht undenkbar, dass andere Hersteller hier noch andere Mechanismen nutzen.

Interessant, eine solche Prüfung könnte natürlich neben dem S/N-Präfix auch noch auf zwei anderen Dingen basieren:

1. MAC-OUI (erste drei Bytes der MAC)
2. OMCI-Vendor-ID

Wenn es das wäre, würde es zumindest erklären, wieso der M-Net Admin glaubt, es werde sonst nichts geprüft - ist eventuell nur ein Lizenzproblem aufgrund der verbauten Technik.

Beide Angaben würde bei meinem externen ONT passen, das MA5671A ist zwar von Huawei, hat aber n.m.E. eine andere OUI, und beim ZyXEL ist beides sicher anders. Wäre es also die OUI, würde das zu den Beobachtungen passen.

Vielleicht sollte ich mal schauen, ob / wie man die MAC beim ZyXEL ändern kann...

Ach und was die OMCC-Version bzw. die OMCI-Features angeht: https://youtu.be/iyEc0ja8ugk?t=712, da geht es genau um die subtilen Unterschiede zwischen OMCI-Implementierungen verschiedener Hersteller. Das betrifft Geräte-Generationen, weil OMCI mehrfach inkompatible Änderungen erfahren hat und auch unterschiedliche Interpretationen der diversen ITU-Standard-Versionen. In dem Video wird konkret auf fehlende Managed Entities eingegangen.

Bei Tracespan wird auch genau auf den Unterschied zwischen PLOAM und (anschließendem) OMCI hingewiesen: PLOAM-Status O5 sagt nur, dass der erste Teil abgeschlossen ist. Erst danach werden die Features und die Konfiguration, bis hin zu Software-Updates per OMCI ausgehandelt. Wenn es dabei zu Fehlern kommt, wird eben kein Kanal für die Kommunikation der Netzwerkebene ausgehandelt. Insofern muss O5 gar kein "Fake" sein - es geht danach nur eventuell nicht weiter.

Ich kann mir gut vorstellen, dass Huawei da im Zweifel Probleme mit dem "eigenen" MA5671A hat, weil die zugrundeliegende OMCI-Implementierung eben von Lancom (und uralt, nämlich von ca. 2011) ist. Da unterscheiden sich die Lancom-basierenden Module nicht groß. Es gibt ja offenbar Hunderte MEs und wiederum Hunderte, die herstellerspezifisch sind.

Stellt sich nur die Frage, ob M-Net ggf. das oder die fehlenden MEs "abschalten" kann, also auf den "mandatory" Basisset umstellen, um höhere Kompatibilität herzustellen. Mich würde auch mal interessieren, ob eine Fritzbox 5590 damit läuft...

[genfai]

Hier wurde das mit der Lizenz bei Huawei für Drittanbieter-ONT geschrieben:

https://forum.huawei.com/enterprise/en/how-to-add-a-third-party-ont-to-a-huawei-olt-ma5608t/thread/486989-100181?page=1

Dass der OLT tatsächlich nur das HWTC in der Seriennummer prüft, kann ich bestätigen, weil ich mich bei der restlichen Seriennummer erst vertippt hatte und es trotzdem funktioniert hat.

Das MA5671A hat anscheinend Support, die MAC zu ändern. Siehe das eine Bild in folgendem Thread.

https://forum.fibra.click/d/23881-ma5671a-e-vodafone-25-gbps/64

Ganz einfach funktioniert es bei dem von FS, weil offiziell unterstützt. Siehe Q&A "Configuration".

https://www.fs.com/de-en/products/133619.html

https://hack-gpon.github.io/ont-fs-com-gpon-onu-stick-with-mac/

Wenn es dagegen tatsächlich an der OMCC-Version liegt, wäre die beste Spekulation vermutlich tatsächlich die Fritz Box 5590 bzw. deren beiliegendes GPON-Modul oder vielleicht auch das von FS. Beide platzieren sich ja anbieterunabhängig an Endkunden und AVM versucht ohnehin, auch bei Glasfaser die Endgerätefreiheit durchzusetzen. Das macht ja nur Sinn, wenn es dann an 99% der Anschlüsse auch problemlos funktioniert. Ich hatte noch keine Fritz Box mit Glasfaser in der Hand, meine aber gelesen zu haben, dass man da ansonsten auch nur die SN und Passwort einträgt. Wäre ja mal ein spannender Test, wenn sonst nichts funktioniert.

Die Slides aus dem YouTube Video hatte ich tatsächlich schon durchgesehen, die Erläuterungen hatte ich noch nicht gehört. Aber der Admin von M-Net sollte ja eigentlich wissen, was da genau passiert. Wenn man erst einmal weiß, was abgefragt wird, kann man ja sehr viel sinnvoller nach Fehlern suchen und es ggf. anpassen. Alleine der genaue OLT wäre schon sehr interessant.

Ich konnte übrigens das Zyxel in einem Lancom-Router an einem 500/100 der Telekom testen. In dem Lancom kommt diese Bandbreite voll an. Wenn ich mich dazu durchringen kann, meinen opnsense Router abzubauen, müsste ich das noch mal damit testen, um zu sehen, ob die Bandbreite dann irgendwie abfällt... bzgl. vermutetem Treiberproblem etc.

Meinst Du Lantiq anstatt Lancom in Bezug auf das MA5671A? Lancom hat ja selber erst seit relativ kurzer Zeit das eine zugekaufte GPON-Modul. Aber in der absoluten Mehrheit der Module steckt anscheinend ein Lantiq Chipsatz und da wurde nach der Übernahme durch Intel wohl nichts mehr weiterentwickelt. GPON ist quasi zu dem Zeitpunkt eingefroren.

Die Telekom kann - wenn sie denn will - lt. Foren wohl einen Reset/Refresh im OLT auslösen, was ein Retraining neuer Endgeräte zur Folge hat. Vielleicht kann M-Net etwas Vergleichbares.

[meyergru]

Das MA5671A hat anscheinend Support, die MAC zu ändern. Siehe das eine Bild in folgendem Thread.

Das Telekom-Modul auch. Es gibt zumindest "mac" als Befehl, zum dauerhaften Setzen würde ich unterstellen, dass "set mac" geht.

Ich bin mir ziemlich sicher, dass das Problem nicht mehr die S/N oder das Passwort betrifft, sondern nur im OMCI oder noch später (PPPoE) zu suchen ist. Vielleicht klappt das mit dem VLAN nicht - aber dann dürfte ja Telekom auch nicht gehen, es sollte ja egal sein, ob man VLAN 7 oder 40 verwendet.

Ich teste das morgen mit M-Net. Inzwischen weiß ich, dass einige 5590 bei M-Net erfolgreich laufen, weshalb M-Net auch gespannt ist, was hier nicht geht. Ich habe inzwischen auch eine Ankündigung über eine Downtime am 3.11. wegen eines Firmware-Updates im Netz bekommen, wobei ich nicht weiß, ob das mit dem Problem zu tun hat (z.B. weil sie gemerkt haben, dass die Firmware hier zu alt für Fremd-ONUs ist) oder unabhängig davon.

Und ja, ich meinte Lantiq, nicht Lancom.

[meyergru]

Sooooo. Läuft. Und übrigens mit vollen >600 Mbit/s down und >200 MBit/s up, genau wie vorher. Ich glaube, für die Durchsatzfrage bringt das nicht viel Erkenntnis.

An der Deciso DEC750 meldet das Ding auch nur einen Link-Status von 5, was 1 GBit und nicht 2.5 GBit bedeutet (die Info dazu hier: https://hack-gpon.github.io/ont-zyxel-pmg3000-d20b/ ist fehlerhaft, wie ich gesehen habe, weil die verschiedenen Speeds aufgelistet werden). Ich nehme aber an, dass das daran liegt, dass der FreeBSD AX-Treiber eben noch kein HSGMII unterstützt.

Ursache war tatsächlich eine Inkompatibilität bei den OMCI-Profilen.

Ich hatte bei dem Telekom/ZyXEL-Modul gesehen, dass die Managed Entities 332 und 373 fehlten - das lässt sich auch insofern nachvollziehen, als diese in den externen Huawei-ONTs vorhanden sind, im Quelltext für das Lantiq-SFP-Modul aber fehlen.

Code Select Expand


Log# show log omci_task
     41231 omci.c:4341 omci ready.
     51211 omci.c:3420 Invalid me class=373 or action=9. return SUCCESS
     51220 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     51222 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     51225 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     51227 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     51230 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     73341 omci.c:1035 Me isn't exist.
     73341 omci.c:1202 FillGetRspPacket fail, result = 1.
     73342 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x80000008.
     73348 omci.c:1035 Me isn't exist.
     73348 omci.c:1202 FillGetRspPacket fail, result = 1.
     73349 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x80000009.
     73523 omci.c:1749 Mib upload start!
     73802 omci.c:1883 Mib upload end!
     80141 omci.c:3420 Invalid me class=373 or action=9. return SUCCESS
     80148 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     80151 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     80153 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     80156 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
     80159 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    103256 omci.c:1035 Me isn't exist.
    103257 omci.c:1202 FillGetRspPacket fail, result = 1.
    103257 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x80000017.
    103263 omci.c:1035 Me isn't exist.
    103263 omci.c:1202 FillGetRspPacket fail, result = 1.
    103264 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x80000018.
    103434 omci.c:1749 Mib upload start!
    103707 omci.c:1883 Mib upload end!
    107109 omci.c:1749 Mib upload start!
    107386 omci.c:1883 Mib upload end!
    108014 omci.c:1749 Mib upload start!
    108275 omci.c:1883 Mib upload end!
    108904 omci.c:1749 Mib upload start!
    109162 omci.c:1883 Mib upload end!
    605030 omci.c:3420 Invalid me class=373 or action=9. return SUCCESS
    605037 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    605040 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    605042 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    605045 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    605048 omci.c:3420 Invalid me class=332 or action=8. return SUCCESS
    626874 omci.c:1035 Me isn't exist.
    626874 omci.c:1202 FillGetRspPacket fail, result = 1.
    626875 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x800002B4.
    626882 omci.c:1035 Me isn't exist.
    626883 omci.c:1202 FillGetRspPacket fail, result = 1.
    626883 omci.c:3840 Response handler failed: MEI100:0, AI9, ID0x800002B5.
    627087 omci.c:1749 Mib upload start!
    627366 omci.c:1883 Mib upload end!
    630722 omci.c:1749 Mib upload start!
    631054 omci.c:1883 Mib upload end!
    631657 omci.c:1749 Mib upload start!
    631980 omci.c:1883 Mib upload end!
    632518 omci.c:1749 Mib upload start!
    632874 omci.c:1883 Mib upload end!


Im Grunde werden bei M-Net Fremdgeräte jetzt zugelassen, gemäß dem Standardvorgehen, dass im M-Net-Forum veröffentlicht ist. Da gibt man seine S/N und den Hardwaretyp an, ein Passwort wird neuerdings gar nicht benötigt. Bei neueren OLTs funktioniert das meistens "einfach so" - es sind z.B. schon etliche Fritzbox 5590 im Einsatz.

Konkret war bei mir ein etwas älterer Huawei-OLT im Einsatz, der noch ein entsprechend geändertes Profil für meinen ONT benötigte.

Wenn ein eigener ONT also wider Erwarten nicht funktionieren sollte, meldet Euch bei M-Net, dann wird Euch geholfen!

P.S.: Mein Huawei MA5671A funktioniert auch.

[genfai]

Super, vielen Dank für die Infos und schön, dass es funktioniert! Hatte auch gelesen, was Du im Computerbase-Forum geschrieben hast.

Dass die 600/200 bei Dir durchkommen, spart mir dann zumindest das Vorhaben, meine DEC 750 abzubauen und an dem weiter oben erwähnten Telekom-Anschluss zu testen. Der verringerte Durchsatz ggü. den theoretischen Werten bei noch höheren Bandbreiten muss dann auch noch ein eigenes Problem sein.

HSGMII lässt sich zumindest auch über die Shell des Zyxel nicht erfolgreich erzwingen bzw. am Modul schon, es kommt dann aber in der DEC750 nicht mehr hoch. Was in den Treiber-Commits über HSGMII steht, kann was mein nicht vorhandenes Verständnis betrifft letztendlich auch etwas bedeuten wie "in jedem Fall ablehnen". Oder die Treiberversion in opnsense ist eine andere. Werde es nach dem kommenden Update auf die nächste Hauptrevision noch mal testen.

[meyergru]

Dazu noch zwei Anmerkungen:

1. Das MA5671A verhält sich etwas anders als das ZyXEL: Kürzerer Ping, aber etwas weniger Durchsatz. Man sieht bei Speedtests ca. 20-30 KBit/s weniger und dass der Speed langsamer ansteigt (vermutlich andere Puffergrößen, was auf den TCP-Verbindungsaufbau wirkt). Ich habe jetzt wieder das ZyXEL dran, trotz der anderen Nachteile (IP-Adresse ist 10.10.1.1/8 und stark limitiertes Web-Interface).

2. HSGMII kann in der DEC 750 m.E. nicht gehen, da der FreeBSD axgbe-Treiber das (noch) nicht kann. In der Liste der unterstützten Modi kommt 2.5 und 5 GBit nicht vor. Interessanterweise scheint der Linux-Treiber das zu können (dort gibt es auch Einträge für 2.5 und 5 GBit):

Code Select Expand

static void xgbe_change_mode(struct xgbe_prv_data *pdata,
     enum xgbe_mode mode)
{
switch (mode) {
case XGBE_MODE_KX_1000:
xgbe_kx_1000_mode(pdata);
break;
case XGBE_MODE_KX_2500:
xgbe_kx_2500_mode(pdata);
break;
case XGBE_MODE_KR:
xgbe_kr_mode(pdata);
break;
case XGBE_MODE_SGMII_100:
xgbe_sgmii_100_mode(pdata);
break;
case XGBE_MODE_SGMII_1000:
xgbe_sgmii_1000_mode(pdata);
break;
case XGBE_MODE_X:
xgbe_x_mode(pdata);
break;
case XGBE_MODE_SFI:
xgbe_sfi_mode(pdata);
break;
case XGBE_MODE_UNKNOWN:
break;
default:
netif_dbg(pdata, link, pdata->netdev,
  "invalid operation mode requested (%u)\n", mode);
}
}


Vor einiger Zeit gab es mal eine Initiative zum Upgrade des FreeBSD-Treibers, der von AMD selbst vorangetrieben wurde (https://reviews.freebsd.org/D21728), dieses Feature war aber nicht dabei. Es sollte eigentlich einfach sein, die Funktion nachzurüsten, weil nur ein paar Konstanten eingefügt werden müssten.

Ich habe dazu den damaligen AMD-Koordinator der Aktion direkt angeschrieben, aber noch keine Antwort.
Eventuell könnte Deciso hier auch selbst Hand anlegen oder einen FreeBSD-Patch einbringen.