OPNsense Forum
International Forums => German - Deutsch => Topic started by: genfai on October 10, 2022, 09:21:08 pm
-
Hallo zusammen,
vor ein paar Tagen hatte ich schon mal im englischsprachigen Hardware and Performance Subforum geschrieben, konnte mich dort aber glaube nicht ganz verständlich machen. Das deutschsprachige Forum hatte ich glatt übersehen. :)
Folgendes Szenario:
Vodafone Glasfaser mit PPPoE Einwahl und 1000/500 Bandbreite. Vodafone stellt einen einfachen ONT von Huawei mit einem einzelnen 1 GBit Port bereit. Offiziellen Support für eigene Geräte gibt es nicht. Schließt man den ONT regulär per LAN an der DEC 750, erhält man 940/510, also das Gigabit Ethernet Limit im Downstream.
Getestet werden soll, ob man auf den ONT verzichten und durch Direktanschluss der Glasfaser die gebuchte Bandbreite erreichen kann.
Dafür habe ich zwei GPON Module (Lancom und Zyxel) jeweils mit den Daten des ONT konfiguriert, in einen der SFP-Ports der DEC 750 gesteckt und die Glasfaser verbunden. Die Konfiguration funktioniert grundsätzlich und man bekommt stabiles Internet ohne Übertragungsfehler.
Beide Module verbinden sich auf der SFP-Seite allerdings nur mit 1 GBit SGMII und die messbare Bandbreite fällt konstant auf 780/480.
Zumindest das Zyxel Modul unterstützt auch 2,5 GBit HGSMII auf der SFP-Seite. Die SFP-Ports unterstützen das aber wohl nicht? Ich habe in den FreeBSD Treiber Commits verweise auf 2,5 GBit gefunden, verstehe das aber leider nicht weiter. Egal, was ich im Menü von OPNsense auswähle, die Verbindung wird immer nur als 1 GBit SGMII angezeigt. Ich nehme an, die Ports oder Treiber unterstützen schlicht nur 1 GBit und 10 GBit?
Was ich habe gar nicht verstehe, ist die verschlechterte Bandbreite von 780/480. Hier sollte ja zumindest das gleiche wie beim Anschluss des ONT per LAN herauskommen. Gibt es da eine Idee zu? Die Verbindung des Moduls wird im OPNsense Dashboard mit 1 GBit SGMII sowie rxpause und txpause aktiviert angezeigt. Wenn ich das an anderer Stelle richtig verstanden habe, sollte das deaktiviert werden und könnte die Ursache sein? Allerdings habe ich keinen Weg gefunden, das in OPNsense für die SFP-Ports der DEC 750 abzuschalten.
In einem getesteten Unify-Gerät lässt sich für das Zyxel-Modul 2,5 GBit erzwingen und man erhält messbar 1040/510, sprich alles inkl. Overprovisioning von Vodafone.
-
Im SFP+ Slot kann ich auch für 10 GbE-Module, die auch 2.5 und 5 GBit/s unterstützen, diese Geschwindigkeiten nicht manuell auswählen. Offenbar wird als Signalisierung nur 1 und 10 GBit/s unterstützt.
Wenn also 2.5 GBit/s z.B. per Auto-Negotiation genutzt werden, wird trotzdem 10 GBit/s angezeigt. Das Verhalten kenne ich auch von Cisco-Switches.
Ich weiß nicht einmal, ob es standardisiertes Signaling bzw. Auswahl der echten Geschwindigkeit für andere Raten als 1 und 10 GBit/s gibt oder ob die Module bzw. das Gerät das jeweils auch können.
Ich hatte übrigens das selbe vor wie Du, bin aber schon bei der Herstellung der Verbindung als solches gescheitert und verwende jetzt den Huawei-ONT.
-
Die Verbindung selbst war erstaunlicherweise kein Problem. Der ONT wurde mit Standardzugang geliefert und das Passwort/PLOAM ließ sich damit auslesen. Das zusammen mit der Seriennummer in den GPON-Modulen gesetzt und in das DEC 750 gesteckt. Die wurden direkt erkannt und ließen sich normal konfigurieren. Ich hatte das auch über ein Wochenende laufen und gehofft, dass zumindest die auf 780/480 verringerte Bandbreite ggü. dem per Ethernet angeschlossenen ONT nur netzseitige Überlastung war. Nach dem Rückbau zum ONT waren aber sofort wieder die 940/510 verfügbar.
Das Zyxel Modul kann man per Shell auf 2.5 GBit zwingen. Der getestete Unify-Router hat damit eine "unbekannte Verbindung" angezeigt, aber ansonsten hat es funktioniert. In den SFP-Ports des DEC 750 wird das Modul dann gar nicht erkannt. Ich bin leichtfertig davon ausgegangen, dass wenn 2.5 und 5 GBit unterstützt werden, jenes auch für die SFP-Seite gilt. Aber hier wird dann vermutlich immer mit 10 GBit verbunden, egal was auf der Ethernet/Fiber-Seite ausgehandelt wird. Das können die GPON-Module nicht und deshalb Fallback auf 1 GBit. Wobei ich nirgendwo die genauen Spezifikationen der AMD SFP-Ports des Ryzen 1500 im DEC 750 finden konnte und ob das nun nur eine Treiberfrage oder eine Limitation der Hardware ist.
Das ist so aber zumindest nachvollziehbar. Warum die Bandbreite mit den GPON Modulen allerdings jeweils auf 780/480 fällt, ist mir nach wir vor nicht ganz klar. Verwendet man das Lancom Modul in einem Lancom Router, gibt es wieder die volle Bandbreite am Ethernet Limit mit 940/510. Es liegt also nicht am Modul oder dem Zusammenspiel mit dem OLT bei Vodafone.
-
Eventuell irgendein internes Buffering was dann Ethernet Flow Control benötigt. Hast Du das mal angeschaltet?
Müsste etwas in dev.ax.0.rx_pause oder tx_pause sein. Eventuell lassen sich mit sysctl auch die Probleme sehen (Statistik). Um hohe Geschwindigkeiten zu erreichen, sollte man auch RSS einschalten, da gibt es ein paar Threads dazu.
Ich stoße aktuell nicht an die Barriere, weil ich bei M-Net einen Tarif mit 600 MBit/s habe, der aber tatsächlich 680 bringt. Der Preis-Uplift auf 1000 skaliert somit nicht - schon gar nicht, wenn dann nur 950 (oder noch weniger) geht.
-
dev.ax.<x>.rss_enabled
Ist per Standard vorhanden und aktiviert. Deaktivieren hatte keinen messbaren Effekt.
dev.ax.<x>.rx_pause
dev.ax.<x>.tx_pause
Das habe ich jeweils aktiviert als auch deaktiviert getestet. Ich hatte im Netz gelesen, dass man es ggf. deaktivieren sollte. Sofern das Dashboard nichts Falsches anzeigt, wird Deaktivieren allerdings nicht umgesetzt, es bleibt immer eingeschaltet.
dev.ax.<x>.link_workaround
dev.ax.<x>.sph_enable
Damit hatte ich auch noch experimentiert. (Zugegeben aber nur weil "sysctl -a | grep dev.ax" das als Schalter ausgeworfen hat und ohne zu verstehen, was das genau bewirkt.)
Statistikdaten habe ich leider nicht gespeichert. Muss ich nachts, wenn niemand hier sonst gestört wird, noch mal umstecken. Es gab zumindest keinen packet loss. Latenz war ggü. Anschluss des ONT per Ethernet minimal besser. Rund eine halbe Millisekunde, sofern man das nicht als Messtoleranz bezeichnen will. Die CPU war nicht ausgelastet.
Im Code für den Treiber wird übrigens 2.5G erwähnt inkl. "gmii_2500".
https://reviews.freebsd.org/D25793
Den Code verstehe ich aber nur sehr eingeschränkt und habe auch unter opnsense nirgendwo gefunden, welche Treiberversion überhaupt verwendet wird. Per grep bekommt man nur AMD 10 GBit Ethernet ausgeworfen.
Den GBit Tarif gab es hier das erste Jahr zum Preis des kleinsten. Aber das geht hier ohnehin durch zwei Parteien, so dass das auch später human bleibt.
-
Ich habe mir das Telekom / Zyxel jetzt mal bestellt, dann kann ich den Huawei ONT dekommissionieren.
Aber zu Deinem Geschwindigkeits-Problem: Es scheint doch eine Limitation des SFP-Moduls zu sein, denn hier werden auch limitierte Werte gemeldet - aber an einem Mikrotik-Switch:
https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-13#post-26834775
Soweit ich es verstanden habe, verwendet sowohl das Huawei MA5671A als auch das ZyXEL PMG3000-D20B intern LANCOM-Chips. Das würde auch erklären, wieso Du mit beiden Modulen die gleichen Werte bekommst.
Das scheint also nicht an der DEC750 bzw. dem axgbe-Treiber zu hängen?
Ich hätte zwar einen Unifi-Switch zum Vergleich, aber ich werde bei meiner Line-Rate ja das Limit sowieso nicht erreichen.
-
Das Lancom SFP-GPON-1 bzw. eigentlich SPS-34-24T-HP-TDFO, wie ich im Lancom-Forum gelernt habe, war der erste Versuch, weil ich den passenden Lancom Router hatte, um SN/PLOAM damit einfach zu schreiben. Das Zyxel PMG3000-D20B war dann der zweite Test. Konfiguration hatte ich nach folgenden Anleitungen gemacht:
https://github.com/xvzf/zyxel-gpon-sfp
https://blog.jaseg.de/posts/telekom-gpon-sfp/
War so problemlos mit dem DEC 750 und opnsense möglich. Nur daran denken, dass die Shell nur erreichbar ist, wenn die Glasfaser angeschlossen ist, sonst baut der SFP-Link nicht auf.
Interessant bei Deinem Setup wird, ob die rund 740/480 irgendein oberes Limit in der Konstellation sind oder die Konfiguration für irgendeine grundsätzlich Degradierung der Leistung sorgt. Etwas seltsam ist ja ansonsten, dass auch der Upstream bei mir von 510 auf 480 fällt, also nicht die absolute Bandbreite das Problem ist.
Den Computerbase-Thread habe ich gelesen. Dort hatte ich auch die Info her, das/wie man 2.5G beim Zyxel erzwingen kann und den Hinweis auf Flow Control. Wobei sich letzteres im Netz unabhängig der Glasfaser öfter zu opnsense findet. Allerdings hatte ich kein Glück, an den Einstellungen etwas zu ändern. opnsense, der SFP-Port und/oder das Modul ignorieren das anscheinend einfach.
Das MA5671A habe ich nicht, nur noch ein GPON-ONU-34-20BI von FS. Aber alle haben anscheinend als Chipsatz einen Lantiq/Intel PEF98035. Das wusste ich bisher nicht. Muss ich mal schauen, ob ich ein konfigurierbares Modul mit einem anderen Chipsatz zum Testen finde.
Am Modul selbst kann es im Grunde nicht liegen, weil es im Lancom rund die erwartete Bandbreite bringt. Sind dort nur rund 900 MBit, was aber am Prozessor Geräts liegen dürfte. Im Lancom-Forum habe ich allerdings gelernt, dass das Modul dort nicht mit SGM-II verbinden würde, sondern 1000BASE-X. Ich weiß nicht, ob das solche Auswirkungen haben kann. Auswählen konnte ich 1000BASE-X bei opnsense, wurde aber nicht übernommen.
Tendenziell vermute ich tatsächlich, dass es primär ein Treiberproblem ist. In der Liste der unterstützten Hardware von Deciso erscheint kein GPON-Modul. Wurde vermutlich nie getestet. Mehr oder weniger gesichert via 2.5G Link Speed funktioniert es anscheinend nur mit einigen Unify Geräten und einer bestimmten Broadcom Karte.
-
War so problemlos mit dem DEC 750 und opnsense möglich. Nur daran denken, dass die Shell nur erreichbar ist, wenn die Glasfaser angeschlossen ist, sonst baut der SFP-Link nicht auf.
Das habe ich jetzt schon mehrfach gelesen - was sieht man dann im Status? Kein Link? Oder nur keine IP?
Ich frage, weil mein MA5671A keinen Link zeigt - weder am Unifi noch am DEC750, ich habe es aber nicht an die Glasfaser angeschlossen. Ich dachte schon, es sei defekt, aber eventuell liegt es nur da dran.
Als ich damals damit herumprobiert habe, ging es prinzipiell, aber ich bekam keine Verbindung zum OLT - inzwischen habe ich in dem Computerbase-Thread eine Info gefunden, die sich mit meinem Verdacht deckt: https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-2#post-26571921
Ich hatte damals notiert:
Es gibt da noch ein paar subtile Unterschiede, z.B. die OMCC-Version, die im HG8012H höher ist, nämlich 0xb0 statt 0xa0, was bedeutet, dass das extended message set unterstützt wird. Kann also gut sein, dass sich OLT und ONU schon nicht verstehen. Auch der Vendor Code unterscheidet sich (0x45 statt 0xcc, das entspricht wohl dem Präfix der Product ID).
Meine Hoffnung ist ja zunächst, dass das ZyXEL / Telekom einfach mal läuft... dann kommt die Speed-Optimierung. Ich kann mir aber nicht vorstellen, dass das der Treiber ist. Dann dürfte 10 GBit noch viel weniger gehen. Ich tippe da eher auf etwas in Richtung MTU.
-
So, habe das MA5671A nochmal reingesteckt. Mit Glasfaser gesteckt ist es online. SSH ging erstmal nicht, weil die Key-Algorithmen nicht passten, aber über die Weboberfläche kam ich in die LuCi-Oberfläche. Mein PLOAM-Status ist 5, aber danach gibt es keinen Verbindungsaufbau per PPPoE.
Mal sehen, wie es mit dem ZyXEL klappt, das scheint ja eine neuere Firmware zu haben, wenn SSH da ohne weiteres geht. Meine Hoffnung ist, dass die OMCC-Version dann auch neuer ist und es dann mit M-Net geht. Sonst habe ich zwei unbrauchbare GPON-Module...
-
Status O5 sollte eigentlich signalisieren, dass alles erfolgreich erledigt ist.
https://forum.huawei.com/enterprise/en/the-process-for-an-onu-to-go-online-gpon-technical-posts-12/thread/462895-100181
Was die PPPoE-Einwahl betrifft: Hast Du an das passende VLAN gedacht?
https://ubiquiti-networks-forum.de/board/thread/2259-vlan-ids-bei-ftth-dsl/
Bei M-Net soll das VLAN 40 sein. Wenn ich das VLAN 7 bei Vodafone nicht setze, tut sich da auch nichts.
SSH ist bei dem Zyxel ohne Mods oder Basteleien direkt möglich.
Noch zu den Treibern der AMD 10G SFP-Ports. Ich nehme an, dass nicht der Treiber oder die Ports ein Problem mit dem Durchsatz an und für sich haben, sondern SGM-II nicht richtig oder vollständig implementiert ist. Vielleicht wird bei den GPON-Modulen auch grundsätzlich etwas falsch erkannt. Es ist schon recht seltsam, dass die Schalter komplett ignoriert werden. Irgendwo hatte ich einen Post gelesen, in dem jemand die Bandbreite von lokalem 10G gemessen hatte. Das war nahe am Maximum. Grundsätzlich können die Ports und auch die Leistung des DEC 750 das.
Wenn Du Dein Modul zum Laufen bekommst, wäre ich sehr daran interessiert, ob die volle erwartete Bandbreite durchkommt.
-
Noch geht nichts, M-Net scheint da irgendwas Spezielles zu machen... siehe https://forum.m-net.de/viewtopic.php?f=23&t=14923 Das ZyXEL verhält sich da genauso wie das Huawei, auch bezogen auf "Interface up nur mit anliegender Glasfaser".
Ich glaube mittlerweile, dass Passwort und S/N 100% korrekt sind, weil der Link-Status mit fehlerhaften Daten anders ist - allerdings: Nur der Link-Status, nicht der ONT-Status, der war immer O5.
Natürlich habe ich an das VLAN 40 gedacht. Konkret ist es ja so, dass ich nur das pppoe0 von igb0_vlan40 (externes ONT) auf ax1_vlan40 (GPON) umschalte, d.h. ich kann mich auch nicht bei den Zugangsdaten vertippen...
Das mit der vollen Bandbreite werde ich nicht testen können, da mein Anschluss nur 600 MBit/s hat.
-
Der Link zum M-Net Forum führt für mich leider auf eine Login-Seite. Gibt es den noch anders?
Im Lancom-Forum hat jemand Dein beschriebenes Problem mit Deutsche Glasfaser. Auch O5, aber keine Einwahl möglich. Ist jetzt nicht besonders hilfreich. Aber vielleicht mal im Auge behalten, falls sich dort eine Lösung findet:
https://www.lancom-forum.de/viewtopic.php?t=19599&start=15
Jemand hat dort noch auf die Möglichkeit von DS-Lite hingewiesen, falls erforderlich. Wobei das bei Dir ähnlich dem VLAN natürlich nur Sinn machen würde, wenn es ansonsten im ONT geschieht und Du es nicht sowieso schon eingerichtet hast.
Ansonsten vielleicht auf dem WAN-Interface auch noch mal die MAC des ONT spoofen?
Mit der vollen Bandbreite meinte ich tatsächlich die volle Bandbreite Deines Tarifs, in dem Fall also die 600 MBit. Bei mir fällt ja auch der Upstream mit den GPON-Modulen von 510 auf 480. Würde bei Dir im Downstream die Bandbreite ebenfalls sinken, wäre das ein weiteres Indiz für ein Treiberproblem.
-
Oh, stimmt, das geht nur mit Anmeldung. Ich hatte dort im Wesentlichen das geschrieben, was ich hier berichtet habe. Einer der M-Net Admins hat aber gesagt, dass außer S/N und Passwort nichts benötigt wird - ich hatte dort schon den Verdacht geäußert, dass es weiterer Dinge bedarf, z.B. OMCC-Version oder MAC. Ich hatte ja bereits ein externes Huawei-ONT mit S/N und Passwort geklont.
Er meinte, dass seiner Erfahrung nach die S/N selten netto übertragen wird und vermutete das Problem dort.
Wiewohl das für das Huawei-Modul ja noch möglich gewesen wäre, ist es beim Telekom-Modul sehr unwahrscheinlich, zudem man die graduelle Änderung bei korrekter S/N sehen konnte:
#######################################################
# #
# Please login to CLI mode. Then You can do commands. #
# #
#######################################################
Entering character mode
Escape character is '^]'.
Login: admin
Password:
ZYXEL# hal
Hal# show
ont show ont parameter
link show pon link
ploam show ploam
tcont show tcont
gemport show gemport
counter show pon counter
softfeature show softfeature
tod1pps show tod1pps
speed show speed
stream show stream
unit UNI port
dhcp dhcp
pppoe pppoe
packet
extvlan vlan
access-list access list
mac-bind bind mac address
mac-filter filter mac address
monitor gemport
mac mac
storm show storm
rstp show rstp
port show port
multicast show multicast
i2c show i2c
sfp sfp hardversion
Hal# show ont
Hal# -----------------ONT Info-----------------
OMCC state : Ready
ONU ID : 101
SN : ZYWNc0e734b4
Password : 474F56454B4F48455650
Power Level : 1
Ont State : O5 OPERATION
Ranging State: UNKNOWN
Admin state : UNLOCK
Hal# show link
Hal# Link State: O3 SERIAL_NUMBER
Hal# set sn HWTC1cb0cd20
Hal# .set sn success!
unknow speed mode parameter!
unknow speed mode parameter!
Hal# show link
Hal# Link State: O5 OPERATION
Hal# SF_SetFeature: Set feature(10) to 1
SF_SetFeature: Set feature(10) to 1
SF_SetFeature: Set feature(10) to 1
Nächste Woche will der Admin das live mit mir testen, indem er am OLT schaut, was schiefgeht.
Andere Dinge, wie VLAN, DS-Lite usw. kann ich eigentlich ausschließen, weil der Anschluss mit dem externen Modem ja funktioniert.
Nach meiner Vermutung muss das irgendein subtiles Problem auf GPON/OMCI-Ebene sein. Ich habe aber nur begrenzte Kenntnisse, wie man das Problem debuggen kann, da kommt mir die Unterstützung des Experten sehr recht.
-
Was meinst Du mit netto übertragen?
Ich habe das bei dem Zyxel tatsächlich nur gemacht wie Du, set sn und sn password. Danach hat es abseits der beschriebenen Probleme grundsätzlich funktioniert.
Dass jemand von M-Net diesbezüglich Support leistet ist aber wirklich edel. Die meisten Anbieter wehren sich ja nach Leibeskräften auch nur zuzugeben, dass der Anschluss eigener Hardware nicht sofort das Ende des Universums zur Folge hat. :D
Gerne so detailliert wie möglich davon berichten!
-
Ja, ich werde berichten.
Und zum Thema "netto" siehe https://de.wikipedia.org/wiki/Netto - der Admin meinte, die Boxen übertragen teilweise nicht die Eingabe, sondern noch mehr. Angesichts des Aufbaus der S/N kann ich mir das vorstellen.
Die Notationen unterscheiden sich da ziemlich (hex, dez, mit Hersteller-Präfix). Ich "glaube", dass die Variante vier Zeichen Hersteller und Rest hexadezimal korrekt ist.
Allerdings möchte M-Net bei Fremdgeräten normalerweise folgende Angaben:
-Hersteller
-Seriennummer
-MAC-Adresse
-Modem-ID
Ich will das natürlich nicht, weil dann das M-Net Original-ONT nicht mehr als Fallback ginge.
Was eine "Modem-ID" sein soll, weiß ich nicht, vermutlich ist die Seriennummer in GPON-Notation gemeint ("Seriennummer" kann ja auch eine rein herstellerspezifische Nummer sein, die nicht übertragen wird).
Es sind aber zwei weitere Angaben genannt, nämlich MAC und Hersteller. Die MAC kann eigentlich nicht relevant sein (1. wegen Aussage des Admin und 2. weil ich schon den ONT erfolgreich durch einen mit einer anderen MAC ersetzt hatte).
Es bleibt noch der Hersteller - tatsächlich glaube ich, dass der PLOAM-Level O.K. ist und es dann in der OMCI-Schicht zu Problemen kommt (https://www.youtube.com/watch?v=iyEc0ja8ugk). Das kann die Software-Version oder die Hersteller-Kennung sein (trotz Änderung der S/N ist der Vendor ja immer noch ZxXEL).
Es gibt ein Posting, dass das zu bestätigen scheint: https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-2#post-26571921
Wenn man nachsieht, was die "Managed Entity class id = 332" ist, findet man in https://www.itu.int/rec/dologin_pub.asp?lang=s&id=T-REC-G.988-201711-I!!PDF-E&type=items in Section 9.13.11 Enhanced Security Control dazu Verschlüsselungsvarianten, das PLOAM Passwort kommt dort auch vor.
Es kann also sein, dass die GPON-Module aufgrund ihrer älteren OMCC-Version diese Angabe nicht unterstützen und nur ein Standardverfahren implementieren.
Interessanterweise bin ich mir aber gar nicht sicher, dass das Passwort tatsächlich benötigt wird. Im Original-Huawei-ONT war es gesetzt, aber in den o.a. Angaben kommt keins vor. Eventuell müsste man das Passwort einfach leer lassen und dann wird die Angabe, wie es verschlüsselt wird, nicht mehr notwendig?
Keine Ahnung - nächste Woche werden wir sehen.
-
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.
-
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...
-
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.
-
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.
-
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.
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.
-
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.
-
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):
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.