Provider DNS-Net findet LANCOM SFP-GPON-1 nicht

[Dr.Einstein]

Und das wird LANCOM nicht rausrücken. Dann brauchst du zum Konfigurieren ein LANCOM.

Ist das nicht das Standard Passwort vom Hersteller?

Code: Alles auswählen

login/passwd : ONTUSER / 7sp!lwUBz1

[Jirka]

Schon lustig dieses Forum manchmal, dank solchen Leuten wie Dr. Einstein...

wenn der Provider jedes Passwort akzeptiert

Und damit meinst Du jetzt das GPON-Passwort (oder PON-Passwort), was quasi kein Provider verwendet, soweit ich das verstanden und neulich auch wieder gelesen hatte.
Irgend so ein Ubiquiti-Teil hatte das SFP-GPON-1 schon mal nicht erkannt (den Fall hatte ich mal vor 3 oder 4 Monaten).

[Jirka]

Nach einem OpenWrt-Update wurde das Modul zumindest schon mal erkannt. An der Faser konnte es noch nicht getestet werden (ist ja erst die Meldung an die Telekom erforderlich).

Kunde fragt jetzt, ob das Modul ein Webinterface hat und wenn ja, was die Default-IP-Adresse ist. Weißt das jemand? Zugangsdaten hat Dr. Einstein ja offenbar schon geliefert.

Vielen Dank und viele Grüße
Jirka

[Dr.Einstein]

Kunde fragt jetzt, ob das Modul ein Webinterface hat und wenn ja, was die Default-IP-Adresse ist. Weißt das jemand? Zugangsdaten hat Dr. Einstein ja offenbar schon geliefert.

SFP: 192.168.1.10 Lancom: 192.168.1.99

Siehste auch am Lancom, der ein aktives GPON SFP hat, mit show ssh. Kann auch sein, dass du mit dem 2,5G / 1G Modus experimentieren musst.

[Jirka]

Hab's mal weitergegeben. Danke. Ich werde berichten. (Die 192.168.1.99 sehe ich übrigens nicht im 'show ssh'.)

+++++

Hier noch das, was mir geschrieben wurde (obwohl hier ja kein OpenWrt-Forum ist, denke ich, dass es sinnvoll sein könnte für Leute, die das LANCOM SFP-GPON-1 in einem OpenWrt-Router verwenden wollen), Modem-ID auf LANC12345678 anonymisiert:

> > nach einem OpenWrt Update
> oha. Und vorher? Nicht mal das Modul erkannt?

Ich bin mir jetzt nicht mehr sicher. Ich denke, einerseits hat das Update schon geholfen, dass der Treiber verfügbar ist (ich war noch auf einer älteren Version). Das allein hat das Problem vermutlich nicht gelöst. Denn bei einem normalen Start bekomme ich die Fehlermeldung:
router kernel: [ 13.853462] sfp sfp: please wait, module slow to respond
router kernel: [ 69.273678] sfp sfp: failed to read EEPROM: -ENXIO

Das Problem gibt es aber mit anderen SFP Modulen auch - häufig liegt es daran, dass die Module intern booten müssen und das teilweise recht lange dauert. Man kann eine Bootverzögerung beim Router einstellen, sodass das SFP Modul genügend Vorsprung hat. Damit bekomme ich dann:
router kernel: [ 12.629837] sfp sfp: Host maximum power 3.0W
router kernel: [ 12.954625] sfp sfp: module LANCOM Systems SFP-GPON-1 rev 1.0 sn LANC12345678 dc 240801

Ich bekomme auch eine Verbindung:
root@router:~# cat /sys/kernel/debug/sfp/state
Module state: present
Module probe attempts: 0 0
Device state: up
Main state: link_up
Fault recovery remaining retries: 5
PHY probe remaining retries: 25
Signalling rate: 1250 kBd
Rate select threshold: 0 kBd
moddef0: 1
rx_los: 0
tx_fault: 0
tx_disable: 0
rs0: 0
rs1: 0
Somit sollte eigentlich alles funktionieren... aber... leider kann ich via Webinterface von meinem Provider meine Modem ID nicht aktualisieren. Es scheint die Änderung nicht anzunehmen, denn mit meinem alten Modem komme ich wie gewohnt rein. Mit dem neuen SFP Modul kann ich keine PPPoE Verbindung aufbauen. Ich habe den Provider kontaktiert und hoffe, dass er das Problem morgen gefixt bekommt, dann kann ich es erneut probieren.

Ich glaube Zugang zum Modul bzw. PON-Passwort ändern werde ich nicht unbedingt brauchen... aktuell liegt's am Provider.

Anmerkung: Provider/Anschluss ist FTTH von Easybell via Telekom mit GPON. Weiter oben hatte ich nur von Telekom geschrieben, da war ich etwas durcheinander gekommen mit einem anderen Kunden.

[Dr.Einstein]

Ich glaube Zugang zum Modul bzw. PON-Passwort ändern werde ich nicht unbedingt brauchen... aktuell liegt's am Provider.

Naja du könntest notfalls die SN manipulieren:

Code: Alles auswählen

 root@SFP:/home/ONTUSER#onu gtcsng

 root@SFP:/home/ONTUSER#set_serial_number PMAC12345678
 (notice:The configuration takes effect only after the module is restarted)

[Jirka]

Leider ist es bisher mit etlichen Versuchen zu keiner funktionierenden Verbindung gekommen (mit dem OpenWrt-Router und dem LANCOM SFP-GPON-1). Der Kunde verliert so ein wenig die Hoffnung, nach einem durchgetesteten Wochenende, nach ewigen Wartezeiten von Easybell die Modem-ID über den von der Telekom geschalteten Anschluss zu ändern usw. Die Schwierigkeiten sind jedenfalls größer als erwartet und auch das Ändern der Modem-ID (auf dem SFP-GPON-1) brachte keinen Erfolg. Die letzte E-Mail, die ich gestern bekam, war so, dass er schrieb, dass PPPoE nicht funktioniert, es käme keine Antwort. Da habe ich erst mal gefragt, welchen GPON-Status er denn (erreicht) hätte. Weil so lange da nicht O5 vorliegt, braucht man ja mit PPPoE gar nicht erst anfangen. Da meinte er dann 1, und wenn er das Kabel abziehe wäre der Link weg.* Aber seine 1 ist daher wohl nicht die O1. Daher ergeben sich aktuell zwei Fragen:

Wie kann man die GPON-Zustände über das CLI (vom SFP-GPON-1) abrufen?

Sind in Übergangsphasen oder auch grundsätzlich providerseitig mehrere Modem-IDs möglich/erlaubt? (Kann es sein, dass der Provider sagt, die Modem-ID wurde jetzt geändert, aber die alte funktioniert immer noch? Das kann doch eigentlich nicht sein, oder?!)


*) Genau hat er geschrieben: "Mein Router meldet Link up und auf dem SFP Modul sehe ich state 1. Wenn ich die (mitgelieferte) Faser abziehe, verliert er den Link."

[Dr.Einstein]

Wie kann man die GPON-Zustände über das CLI (vom SFP-GPON-1) abrufen?

Befehl müsste folgender sein, Phasen müssten dem der Lancom CLI entsprechen, 1-5.

Code: Alles auswählen

gtop -b -g a | grep "PLOAM state"

[Jirka]

Rotwang, liest Du auch noch mit? Wenn Du eine Idee hast, es sieht im Augenblick nicht gut aus...

Nachfolgend gebe ich 1:1 die Kunden-E-Mail wieder, falls jemand helfen kann:

hier das Ergebnis - PLOAM State O1:

BusyBox v1.22.1 (2021-06-18 14:15:53 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

OpenWrt - (14.07_ltq) --- Lantiq Edition for GPON
----------------------------------------------
root@SFP:/home/ONTUSER# gtop -b -g a | grep "PLOAM state"
PLOAM state 1

Es wird aber definitiv eine Gegenstelle erkannt, denn der Link Status (laut cat /sys/kernel/debug/sfp/state auf meinem Router) wechselt von "wait_los" zu "link_up", wenn ich das Glasfaserkabel verbinde. Außerdem ist nur im "link_up" State überhaupt eine SSH Verbindung auf das SFP Modul herstellbar (und wird getrennt, wenn ich das Kabel rausziehe).

Gibt es Einstellungen, die ich für ein Telekom/easybell FTTH auf dem Modul anpassen kann, sodass die beiden Seiten auch miteinander reden? Es kann ja eigentlich nur die Art und Weise sein, wie das SFP mit der Gegenstelle spricht, ansonsten würde ich O3/O5 erwarten.

... und hier noch der vollständige Output von

root@SFP:/home/ONTUSER# gtop -b -g a
Page: Status
OPTION VALUE
PLOAM state 1
Downstream FEC enable no
Upstream FEC enable no
PLOAMd message waiting in buffer no
PLOAMd message buffer overflow no
Receive state machine status hunt
Receive superframe state machine status hunt
PEE received no
ONU ID 254
Start Offset enable no
[0] Interface mode 15
[0] PHY status 4
[0] PHY duplex 1
[0] WOL status 0

"Receive state machine status hunt" sagt eigentlich alles aus

[Dr.Einstein]

Wenn O1 bleibt, dumme Frage: Passen wirklich die Stecker des Kabels zur Dose / Lancom-SFP? Kannst du auch mal prüfen lassen, ob das andere Modem XGS-PON macht statt GPON?

[Jirka]

Wenn O1 bleibt, dumme Frage: Passen wirklich die Stecker des Kabels zur Dose / Lancom-SFP?

Es handelt sich um das originale Kabel von LANCOM, was dem SFP-Modul beiliegt. Und wenn er das Kabel absteckt/zieht, dann geht der Link verloren, also scheint es ja zu funktionieren. Bei dem Anschluss handelt es sich um einen relativ neuen Anschluss der Telekom in einer großen Stadt in einem neuen Wohngebiet.

Kannst du auch mal prüfen lassen, ob das andere Modem XGS-PON macht statt GPON?

Das war auch meine Idee (aber ich schicke Dir mal die Adresse, dann kannst Du mal schauen), weil mir langsam die Ideen ausgehen und ich es auch nicht verstehe, was da vor sich geht. So schrieb ich also schon vor Deinem Posting um 19:35 Uhr an den Kunden:

> Gibt es Einstellungen, die ich für ein Telekom/easybell FTTH auf dem Modul anpassen kann, sodass die beiden Seiten auch miteinander reden?

Also das Modul ist von der Telekom abgenommen und zertifiziert für das GPON-Netz der Telekom.
XGS-PON (10 Gigabit Symmetrical PON) hast Du nicht zufälligerweise?!
Ich alleine habe schon etliche Module davon verbaut oder verkauft, die problemlos an Telekom-Anschlüssen laufen (ohne dass da einer was eingestellt hat). Wenn was nicht lief, dann war es bisher immer so, dass der Router das Modul nicht erkannt hat (z. B. Ubiquiti). Alle LANCOM-Router erkennen das Modul aber ab 10.50-er Firmware. Deswegen wundert mich bei Dir nach wie vor einiges.

Ausführliche Antwort folgt!!!

Die Antwort darauf:

Ja, die Telekomzertifizierung war auch der zentrale Grund, es mal mit dem Lancom Modul zu probieren... ich habe keine Ahnung warum das nicht zusammenspielen will...
Hier mal ein Screenshot aus der aktiven Fritzbox Verbindung, sieht alles nach normalen GPON aus:

Screenshot-FRITZ!Box.png

[rotwang]

Rotwang, liest Du auch noch mit?

Ja, aber ich wüßte nicht allzuviel, was ich dazu beitragen könnte. Ich kann in erster Linie etwas zu diesen Modulen in LCOS-Routern sagen. Wenn ich als Kunde einen OpenWRT einsetzen will, dann hätte ich mich im Netz nach Erfahrungsberichten umgeschaut, welche GPON-Module man dort schon einmal zum Laufen bekommen hat. Das LANCOM-Modul kauft man doch in erster Linie, weil es in LANCOM-Routern offiziell unterstützt ist, und akzeptiert dafür den Aufpreis.

hier das Ergebnis - PLOAM State O1:

O1 ist der State, den man mit dem Modul in einem LCOS-Router auch schon bekommt, wenn gar kein Glasfaserkabel dran steckt:

Code: Alles auswählen

Interface  Management-State    Device                Serial-number  Operating-State    Temperature  Rx-Power         Tx-Power         Version          Reduced-Buffer      Reconnects  Resets
===========----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
WAN-1      Ready               SPS_34_24T_HP_TDFP    PMAC4421000A   O1-Initial         34           ---              2.27             6BA1896SPLQA40   Disabled            0           0     

Kein LOS, aber trotzdem O1 sieht mir danach aus, als ob das Modul zwar generell 'Licht' von der Providerseite sieht, aber irgendwo auf MAC/L2-Ebene etwas noch nicht zusammen passt. Wenn der Provider nur die MAC-Adresse des Endgeräts nicht akzeptiert, kriegt man irgend etwas mit O2 oder O3.

Es wird aber definitiv eine Gegenstelle erkannt, denn der Link Status (laut cat /sys/kernel/debug/sfp/state auf meinem Router) wechselt von "wait_los" zu "link_up", wenn ich das Glasfaserkabel verbinde.

"Gegenstelle erkannt" ist ein sehr schwammiger und ungenauer Begriff und hilft wenig bei der Fehlersuche, weil man nicht weiß, auf welchem Layer da etwas 'erkannt' wird. Ich kann Dir nicht sagen, wie die genaue Bedingung dafür ist, dass das GPON-Modul das LOS-Signal an der SFP-Schnittstelle wegnimmt. Kann wie gesagt sein, dass dafür das Vorhandensein von optischer Energie reicht.

Du kannst ja z.B. auch per Glasfaser und SFP einen 1GBit- und einen 10Gbit-Ethernet-Port miteinander verbinden. Da werden beide Seiten 'LOS:0' melden, also eine Gegenstelle irgendwie 'erkannt' haben, aber verstehen tun sie sich trotzdem nicht.

Außerdem ist nur im "link_up" State überhaupt eine SSH Verbindung auf das SFP Modul herstellbar (und wird getrennt, wenn ich das Kabel rausziehe).

Das hängt halt damit zusammen, dass der Router das LOS-Signal des Moduls (also ob Licht auf der GPON-Seite da ist) mit in den Linkstatus der 1000BASE-X-Verbindung zwischen Router und Modul hinein verknüpft. Das LCOS 'weiss', dass das LOS sich auf die GPON-Seite des Moduls und ignoriert daher das Signal für die Ermittlung des Links auf der Ethernet-Seite. Deshalb kann das LCOS auch eine SSH-Management-Verbindung zu dem Modul aufbauen, wenn auf der Faserseite gar nichts drinsteckt. Vielleicht hat der OpenWRT-Router auch irgendeine 'Ignore-LOS'-Einstellung, ich kenne mich mit denen aber wie gesagt nicht aus.