Lancom an GPON Anschluss in Spanien

[dwulfing]

Guten Abend,
ich habe folgende Herausforderung:

Es soll ein 1781 EF+ mit GPON Modul an einem Glasfaseranschluss der Telefonica auf Mallorca betrieben werden.

Ich habe schon einiges zu dem Thema herausgefunden, in folgenden Beitrag geht es um den Anschluss einer FritzBox

https://www.glasfaserforum.de/forum/thr ... /?pageNo=1

Es ist wohl erforderlich das PON Passwort aus dem alten Router auszulesen und im Lancom Router einzutragen. Hier ist nun mein Problem. Der Lancom möchte dieses Passwort gerne im ASCII Format, der Router der Telefonica gibt es mir als HEX. Das Passwort beginnt immer mit F202…

Ich habe nun versucht das HEX Passwort in ASCII umzuwandeln, das wird aber von LAN Config nicht angenommen.

Habt ihr eine Idee?

[Dr.Einstein]

Andere Optionen wie DHCP hatten für die Hexdarstellung folgendes Muster: 0x74,0x65,0x73,0x74

Vielleicht klappt das ja auch hier?

[MoinMoin]

Moin dwulfing,

wenn das LCOS aktuell ist, dann kannst du das Passwort zumindest auf der Konsole eingeben. 20 Hex-Zeichen, bei Bedarf am Ende mit Nullen aufgefüllt.

Ciao, Georg

[Frühstücksdirektor]

Hallo,

normalerweise könntest du den Hex-String (20 Zeichen) in ASCII (10 Zeichen) umwandeln. Leider verwendet Telefonica/Movistar "Non-Printable Characters", so dass das nicht funktioniert.

Ab LCOS 10.80 kann man beim GPON das Passwort entweder per HEX oder ASCII eingeben. LCOS 10.80 ist aber noch nicht verfügbar.

Für deinen 178EF+ ist die letzte Firmware die 10.50. Eine 10.80 wird der 1781EF+ also nicht bekommen. Ich empfehle hier den 1800EF als Ersatz oder ein externes GPON-Modem.

Viele Grüße,
Frühstücksdirektor

[MoinMoin]

Moin, moin,

upps, daß die Zielversion 10.80 ist, war mir entfallen.

Ciao, Georg

[passi]

Hallo,

ich würde gerne diesen Thread mal nach vorne holen, da ich aktuell ebenfalls mit einem 1800VA mit GPON Modul vor Problemen bei dem spanischen Provider Movistar stehe.
Eingesetzt wird LCOS 10.90, die Eingabe des PON-Passworts als 20 Zeichen hex String bereitet keine Probleme, die Einwahl klappt auch, im Trace sehe ich die öffentliche IPv4 Adresse. Leider aber auch als Gateway eine private IP 192.168.144.1 und nach 20 Sek. wird die Verbindung getrennt.

Ich erhalte einen LCP Frame der beantwortet wird und dann ist Ende:

Received LCP frame from peer MOVISTAR (channel 11)
LCP echo-request with ID 00 and length 8 for peer MOVISTAR
Sending LCP echo-response with ID 00 and length 8 to peer MOVISTAR (channel 11)

[PPP] 2025/05/13 10:03:28,538 Devicetime: 2025/05/13 10:03:27,163
Change phase to DEAD for MOVISTAR
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping IPV6CP restart timer

Hat jemand diese Konstellation stabil am Laufen?

[Frühstücksdirektor]

Hallo,

ich habe das schon so an einem Anschluss mit einem 1800EF und dem GPON-1 eingerichtet bei Movistar in Spanien. Hat problemlos geklappt mit der 10.80 damals.
Du darfst aber nicht den Schalter "MTU-1500-über-PPPoE" verwenden, weil der BRAS das zwar ankündigt er könne das, danach aber nicht funktioniert.
Also: MTU-1500-über-PPPoE"=Nein.
WICHTIG: Danach muss die Internetverbindung einmal getrennt werden, damit die Änderung greift.
Falls das nicht hilft, kann ich dir per PN ggf. remote helfen.

Viele Grüße,
Frühstücksdirektor

[Dr.Einstein]

Ist ein Linepolling auf die WAN-Verbindung eingerichtet? Wenn ja, lösch das mal.

[passi]

Danke schon mal für die Antworten!

Den Schalter "MTU-1500-über-PPPoE" hatte ich erst bei späteren Tests mal eingeschaltet, da es vorher ohne bereits zu den Abbrüchen kam. Der Support hatte mich darauf hingewiesen dies wieder abzuschalten.

Ein aktives Line-Polling ist für die Gegenstelle nicht konfiguriert, da es eine PPPoE Gegenstelle ist die ja bereits LCP Polling nutzt.

Aktuell läuft der Lancom hinter dem Mitrastar GPT-2741GNAC, ich habe erst am 11.6. wieder jemand vor Ort der die Glasfaser umstecken kann für weitere Test. Um das Gateway mit der privaten IP muss ich mir keine sorgen machen?

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-request with ID 7a and size 10
Peer requests IP address 192.168.144.1, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID 7a and length 10 to peer MOVISTAR (channel 10)

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-nak with ID 00 and size 22
Peer NAKs IP address 83.49.xxx.xxx, accepted
Peer NAKs primary DNS address 80.58.61.250, accepted
Peer NAKs secondary DNS address 80.58.61.254, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer MOVISTAR
Inserting IP address 83.49.xxx.xxx
Inserting primary DNS address 80.58.61.250
Inserting secondary DNS address 80.58.61.254
Sending IPCP configure-request with ID 02 and length 22 to peer MOVISTAR (channel 10)
Starting IPCP restart timer with 3000 milliseconds

[Dr.Einstein]

Eine (Default) Route auf die Gegenstelle MOVIESTAR existiert aber? Hast du noch irgendwas mit IPv6 auf der Gegenstelle konfiguriert?

[passi]

Ja, die Default-Route ist gesetzt. IPv6 habe ich nicht genutzt, der vorh. Mitrastar vom Provider scheint das auch nicht zu nutzen.

[backslash]

Hi passi

Um das Gateway mit der privaten IP muss ich mir keine sorgen machen?

eine PPP-Link ist ein "unnumberd" Link - also einer ohne Transfernetz und Gateway...
Das was dir als Gateway angezeigt wird, ist die IP-Adresse der Gegenstelle - also deines Providers. Er hat die Adtresse während der PPP-Verhandlkung gefordert und das LANCOM hat sie akepatiert:

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-request with ID 7a and size 10
Peer requests IP address 192.168.144.1, accepted

Das legt nahe, daß das dein Provider selbst nochmal ein NAT macht, obwohl er dir scheinbar eine öffentliche Adresse zuweist:

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-nak with ID 00 and size 22
Peer NAKs IP address 83.49.xxx.xxx, accepted

Das hat alles nichts mit deinem Abbruch zu tun...

Wenn die Leitung unmotiviert wegbricht, dann solltest du mal schauen, welcher Fehler gemeldet wird.
Dazu läßt du neben dem PPP-Trace auch noch einen "display" Trace laufen (der Name ist historisch). Der Trace zeigt dir den Zustand der WAN-Verbindung und etwaige Fehler an.
Unmotivierte Abbrüche gehen auf einem "normalen" DSL-Anschluß meist mit einem "Layer-1 Fehler" einher, was einem Link-Verlust entspricht.
Ob die GPON-Module das auch machen, kann ich dir allerdings nicht sagen. In jedem Fall solltest du den Fehler in "hardwarenähe" (Wackelkontakt, fehlerhafter Anschluß der Glasfaser, zu hohe Dämpfung, etc..) oder gar beim Provider suchen und ggf. eine Störmeldung machen (auch wenn die meisten Provider dann leider sagen: sie haben nicht unseren Router angeklemmt - da machen wir nichts)


Gruß
Backslash

[MoinMoin]

Moin, moin,

ein gleichzeitig laufender PON-Trace kann auch nicht schaden.

Ciao, Georg

[passi]

Hallo,

aktuell ist jemand vor Ort zum umstecken der Leitung. Ich habe mal den trace mit PPP, PON, Status und Error laufen lassen:

Code: Alles auswählen

Received PADO frame from peer MOVISTAR (24:21:24:be:c8:42) for session 0000
Service: (any), accepted
AC-Name: hl4pmmo1-104, accepted
Host-ID: e0 9d 7c 99 9d f6 3d 6c, accepted
Cookie:  f6 77 71 de 4b 39 d8 2d d4 a1 e7 0a fa 55 18 d7, accepted

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,718

Transmit PADR frame to peer MOVISTAR (24:21:24:be:c8:42) for session 0000
Service: (any)
Host-ID: e0 9d 7c 99 9d f6 3d 6c
Cookie:  f6 77 71 de 4b 39 d8 2d d4 a1 e7 0a fa 55 18 d7

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,721

Received PADS frame from peer MOVISTAR (24:21:24:be:c8:42) for session 0001
Service: (any), accepted
Host-ID: e0 9d 7c 99 9d f6 3d 6c, accepted

[Status] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,721
Status: DSL-CH-2: Protocol (using DSL-1)

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,721
Change phase to ESTABLISH for MOVISTAR
Lower-Layer-Up event for LCP
Remote: MOVISTAR (cPhysicalComChannel)
Current LCP TxOpt AktMru: 1492
Current LCP RxOpt AktMru: 1492
Resulting LCP RxOpt AktMru for connection 1492
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,726

Received LCP frame from peer MOVISTAR (channel 10)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer MOVISTAR
Inserting local MRU 1492
Inserting local magic number 4efb1eb6
Sending LCP configure-request with ID 00 and length 14 to peer MOVISTAR (channel 10)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 75 and size 19
Peer MRU 1500 accepted
Peer requests authentication protocol CHAP with MD5 encryption, accepted
Peer magic number 502d8a0c accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 75 and length 19 to peer MOVISTAR (channel 10)

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,729

Received LCP frame from peer MOVISTAR (channel 10)
Evaluate configure-ack with ID 00 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for MOVISTAR
Stopping LCP restart timer

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,730

Received CHAP frame from peer MOVISTAR (channel 10)
Got CHAP-Challenge from peer MOVISTAR
Challenge = 5f 52 fd 91 0a 58 c3 96 41 20 46 db a1 7e 92 37 8c e8 c4 3f b9 24 2a 08 d7 6d 32 a4 61 c7 09 41 1a
Found peer-id MOVISTAR in PPP table
Sending CHAP-response to peer MOVISTAR (channel 10), length = 16

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,747

Received CHAP frame from peer MOVISTAR (channel 10)
Got CHAP-Success from peer MOVISTAR
This-Layer-Up action for LCP
Change phase to NETWORK for MOVISTAR
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer MOVISTAR
Inserting IP address 0.0.0.0
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 22 to peer MOVISTAR (channel 10)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,748

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-request with ID c4 and size 10
Peer requests IP address 192.168.144.1, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID c4 and length 10 to peer MOVISTAR (channel 10)

[PPP] 2025/06/10 10:41:13,224  Devicetime: 2025/06/10 10:41:13,750

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-nak with ID 00 and size 22
Peer NAKs IP address 83.49.1xx.xx, accepted
Peer NAKs primary DNS address 80.58.61.250, accepted
Peer NAKs secondary DNS address 80.58.61.254, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer MOVISTAR
Inserting IP address 83.49.1xx.xx
Inserting primary DNS address 80.58.61.250
Inserting secondary DNS address 80.58.61.254
Sending IPCP configure-request with ID 02 and length 22 to peer MOVISTAR (channel 10)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2025/06/10 10:41:13,244  Devicetime: 2025/06/10 10:41:13,754

Received IPCP frame from peer MOVISTAR (channel 10)
Evaluate configure-ack with ID 02 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
This-Layer-Up action for IPCP
Stopping IPCP restart timer

[Status] 2025/06/10 10:41:13,284  Devicetime: 2025/06/10 10:41:13,762
Status: DSL-CH-2: MOVISTAR (using DSL-1)


[PPP] 2025/06/10 10:41:29,184  Devicetime: 2025/06/10 10:41:29,701

Received LCP frame from peer MOVISTAR (channel 10)
LCP echo-request with ID 00 and length 8 for peer MOVISTAR
Sending LCP echo-response with ID 00 and length 8 to peer MOVISTAR (channel 10)

[PON] 2025/06/10 10:41:31,761  Devicetime: 2025/06/10 10:41:32,279
WAN: Management connection closed

[PON] 2025/06/10 10:41:33,740  Devicetime: 2025/06/10 10:41:34,258
WAN: Opening management connection


[PON] 2025/06/10 10:41:40,841  Devicetime: 2025/06/10 10:41:41,360
WAN: Management connection established

[PON] 2025/06/10 10:41:40,841  Devicetime: 2025/06/10 10:41:41,360
WAN: Reading configuration

[PON] 2025/06/10 10:41:41,305  Devicetime: 2025/06/10 10:41:41,822
WAN: Writing configuration

[PON] 2025/06/10 10:41:41,305  Devicetime: 2025/06/10 10:41:41,822
WAN: Read configuration done

[PON] 2025/06/10 10:41:41,305  Devicetime: 2025/06/10 10:41:41,822
WAN: Configuration written

[PON] 2025/06/10 10:41:41,305  Devicetime: 2025/06/10 10:41:41,822
WAN: rebooting device

[Status] 2025/06/10 10:41:43,207  Devicetime: 2025/06/10 10:41:43,719
Status: DSL-CH-2: Disconnecting (using DSL-1)

[PPP] 2025/06/10 10:41:43,207  Devicetime: 2025/06/10 10:41:43,719
Change phase to DEAD for MOVISTAR
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping IPV6CP restart timer

[Status] 2025/06/10 10:41:43,248  Devicetime: 2025/06/10 10:41:43,735
Status: DSL-CH-2: Ready (DSL layer 1)

Der PON lässt mich grübeln, warum "WAN: Management connection closed" und "WAN: rebooting device"?

[Frühstücksdirektor]

Kannst Du bitte mal die 10.80 RU10 testen?