LC1721+ Verbindungsabbrüche dann Gegenstelle antwortet nicht

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

LC1721+ Verbindungsabbrüche dann Gegenstelle antwortet nicht

Beitrag von logox2 »

Hallo Forum,
in dem Pfarramt, welches ich betreue, habe ich einen 1721+ installiert;
Hardware Rev G; 8.00.0221.

Der 1721 baut über sein internes DSL-Modem 2 Verbindungen auf: eine zu T-Online, eine zum Sicheren Kirchennetz (T-Intra-Select Plattform). Funktioniert auch:
Bild

Dazu hab ich 2 Kommunikationslayer angelegt
Bild

2 Gegenstellen; 2 Einträge in die PPP-Liste; MTU's angepasst:
Bild

Bild

Bild

Dann noch IP-Routing und Firewall-Regeln, damit 2 interne Netze getrennt über die DSL gehen und sich nicht gegenseitig sehen:
Bild

Bild

Bild

Soweit so gut. Funktioniert auch: die Netz 'sehen' sich nicht und jedes geht seinen Weg.

Aber:
Es passiert in unregelmäßigen Abständen, das sich die Verbindung ins sichere Kirchennetz abbaut, danach dort eine Wiedereinwahl erfolgen soll, dies auf einen nicht nachvollziehbaren Weg auch die Verbindung zu T-Online beendet (Line polling failed). Wenn dann beide Verbindungen wieder die Einwahl versuchen klappt es nicht: Meldung: Gegenstelle antwortet nicht.
Erst nach einem Kaltstart des Routers klappt bei beiden Verbindungen wieder die Einwahl.

Nach ein wenig Recherche im Forum fand ich den Hinweis auf das Thema mit dem Linecode. Fest eingestellt
Bild
und der Fehler tritt weiterhin auf.

Der Versucht mit FW 8.50 RC2 brachte auch keine Besserung.

Ein Trace auf die PPP brachte nur folgendes zum Zeitpunkt einer Verbindungsunterbrechung zum Sicheren Kirchennetz:

Code: Alles auswählen

[PPP] 2011/04/09 09:10:44,734  Devicetime: 2011/04/09 09:10:43,910

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 74 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:10:49,765  Devicetime: 2011/04/09 09:10:48,930

LCP polling timeout for peer T-CLSURF - echo-response received during last interval
Sending LCP echo-request with ID 58 and length 8 to peer T-CLSURF (channel 1)

[PPP] 2011/04/09 09:10:50,125  Devicetime: 2011/04/09 09:10:48,960

Received LCP frame from peer T-CLSURF (channel 1)

LCP echo-response with ID 58 and length 10 to peer T-CLSURF


[PPP] 2011/04/09 09:10:54,984  Devicetime: 2011/04/09 09:10:54,150

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 75 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:11:05,218  Devicetime: 2011/04/09 09:11:04,390

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 76 and length 14 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:06,234  Devicetime: 2011/04/09 09:11:05,320

Received LCP frame from peer T-DSLSKN (channel 2)
Terminate-Request-Received event for LCP

[PPP] 2011/04/09 09:11:06,609  Devicetime: 2011/04/09 09:11:05,320
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
This-Layer-Down action for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Resetting LCP restart timer with 3000 milliseconds
Change phase to TERMINATE for T-DSLSKN
Sending LCP terminate-request with ID 19 and length 4 to peer T-DSLSKN (channel 2)
Starting LCP restart timer with 3000 milliseconds
Sending LCP terminate-ack with ID 00 and length 4 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:06,609  Devicetime: 2011/04/09 09:11:05,320
Change phase to DEAD for T-DSLSKN
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer

[PPP] 2011/04/09 09:11:06,625  Devicetime: 2011/04/09 09:11:05,340

Transmit PADT frame to peer 00:90:1a:a0:15:24 for session 0c9d

[PPP] 2011/04/09 09:11:06,625  Devicetime: 2011/04/09 09:11:05,380

Received data packet for unknown session 0c9d from peer 00:90:1a:a0:15:24 => closing connection on AC
Transmit PADT frame to peer 00:90:1a:a0:15:24 for session 0c9d

[PPP] 2011/04/09 09:11:07,796  Devicetime: 2011/04/09 09:11:06,920

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 90 34 ba 85 a5 a2 de 62

[PPP] 2011/04/09 09:11:08,125  Devicetime: 2011/04/09 09:11:06,960

Received PADO frame from peer 00:90:1a:a0:15:24 for session 0000
AC-Name: BAYX41-erx, accepted
Host-ID: 90 34 ba 85 a5 a2 de 62, accepted
Service: (any), accepted
Cookie:  cc f6 e6 eb 27 2e c8 c5 ac 72 2e b7 0e 06 9e da, accepted

[PPP] 2011/04/09 09:11:08,140  Devicetime: 2011/04/09 09:11:06,960

Transmit PADR frame to peer 00:90:1a:a0:15:24 for session 0000
Host-ID: 90 34 ba 85 a5 a2 de 62
Service: (any)
Cookie:  cc f6 e6 eb 27 2e c8 c5 ac 72 2e b7 0e 06 9e da

[PPP] 2011/04/09 09:11:08,140  Devicetime: 2011/04/09 09:11:07,110

Received PADS frame from peer 00:90:1a:a0:15:24 for session 0dad
Service: (any), accepted
Host-ID: 90 34 ba 85 a5 a2 de 62, accepted

[PPP] 2011/04/09 09:11:08,156  Devicetime: 2011/04/09 09:11:07,110
Change phase to ESTABLISH for T-DSLSKN
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds

[PPP] 2011/04/09 09:11:08,328  Devicetime: 2011/04/09 09:11:07,310
Positive Restart-Timeout event for LCP
Stop waiting for connection
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer T-DSLSKN
Inserting local MRU 1456
Inserting local magic number 52d16f31
Sending LCP configure-request with ID 00 and length 14 to peer T-DSLSKN (channel 2)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2011/04/09 09:11:08,687  Devicetime: 2011/04/09 09:11:07,520

Received LCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-request with ID 72 and size 18
Peer MRU 1492 accepted
Peer requests authentication protocol PAP, accepted
Peer magic number 057ce671 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 72 and length 20 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:08,687  Devicetime: 2011/04/09 09:11:07,520

Received LCP frame from peer T-DSLSKN (channel 2)
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 T-DSLSKN
Generating PAP-request for peer T-DSLSKN
Resolved peer as T-DSLSKN in PPP table

Sending PAP-request with ID 43, size 43 and peer-id pfr303016@elkb.de.td@dsldial.de to peer T-DSLSKN (channel 2)
Stopping LCP restart timer

[PPP] 2011/04/09 09:11:09,031  Devicetime: 2011/04/09 09:11:08,120

Received LCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-request with ID 61 and size 18
Change phase to ESTABLISH for T-DSLSKN
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer T-DSLSKN
Inserting local MRU 1456
Inserting local magic number c4d034b8
Sending LCP configure-request with ID 00 and length 14 to peer T-DSLSKN (channel 2)
Starting LCP restart timer with 3000 milliseconds
Peer MRU 1456 accepted
Peer requests authentication protocol PAP, accepted
Peer magic number 5f066240 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 61 and length 20 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:09,328  Devicetime: 2011/04/09 09:11:08,170

Received LCP frame from peer T-DSLSKN (channel 2)
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 T-DSLSKN
Generating PAP-request for peer T-DSLSKN
Resolved peer as T-DSLSKN in PPP table

Sending PAP-request with ID 44, size 43 and peer-id pfr303016@elkb.de.td@dsldial.de to peer T-DSLSKN (channel 2)
Stopping LCP restart timer

[PPP] 2011/04/09 09:11:09,718  Devicetime: 2011/04/09 09:11:08,770

Received PAP frame from peer T-DSLSKN (channel 2)
Evaluate PAP ack with ID 44 and size 5
This-Layer-Up action for LCP
Change phase to CALLBACK for T-DSLSKN
This-Layer-Up action for LCP
Change phase to NETWORK for T-DSLSKN
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-DSLSKN
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 T-DSLSKN (channel 2)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2011/04/09 09:11:09,718  Devicetime: 2011/04/09 09:11:08,780

Received IPCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-request with ID 01 and size 10
Peer requests IP address 195.145.165.45, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID 01 and length 12 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:10,250  Devicetime: 2011/04/09 09:11:08,830

Received IPCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-reject with ID 00 and size 10
Peer rejects secondary DNS address 0.0.0.0, discard local option
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-DSLSKN
Inserting IP address 0.0.0.0
Inserting primary DNS address 0.0.0.0
Sending IPCP configure-request with ID 02 and length 16 to peer T-DSLSKN (channel 2)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2011/04/09 09:11:10,265  Devicetime: 2011/04/09 09:11:08,880

Received IPCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-nak with ID 02 and size 16
Peer NAKs IP address 10.18.2.91, accepted
Peer NAKs primary DNS address 10.17.0.125, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer T-DSLSKN
Inserting IP address 10.18.2.91
Inserting primary DNS address 10.17.0.125
Sending IPCP configure-request with ID 03 and length 16 to peer T-DSLSKN (channel 2)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2011/04/09 09:11:10,265  Devicetime: 2011/04/09 09:11:08,940

Received IPCP frame from peer T-DSLSKN (channel 2)
Evaluate configure-ack with ID 03 and size 16
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
This-Layer-Up action for IPCP
Stopping IPCP restart timer

[PPP] 2011/04/09 09:11:10,625  Devicetime: 2011/04/09 09:11:09,790

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 01 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:11:20,875  Devicetime: 2011/04/09 09:11:20,030

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 02 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:11:31,109  Devicetime: 2011/04/09 09:11:30,270

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 03 and length 14 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:11:31,562  Devicetime: 2011/04/09 09:11:30,720

Received LCP frame from peer T-CLSURF (channel 1)

Sending LCP echo-response with ID 45 and length 10 to peer T-CLSURF (channel 1)


[PPP] 2011/04/09 09:11:39,765  Devicetime: 2011/04/09 09:11:38,930

LCP polling timeout for peer T-CLSURF - echo-response received during last interval
Sending LCP echo-request with ID 59 and length 8 to peer T-CLSURF (channel 1)

[PPP] 2011/04/09 09:11:40,015  Devicetime: 2011/04/09 09:11:38,960

Received LCP frame from peer T-CLSURF (channel 1)

LCP echo-response with ID 59 and length 10 to peer T-CLSURF

[PPP] 2011/04/09 09:11:41,343  Devicetime: 2011/04/09 09:11:40,510

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 04 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:11:51,593  Devicetime: 2011/04/09 09:11:50,750

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 05 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:11:59,781  Devicetime: 2011/04/09 09:11:58,940

LCP polling timeout for peer T-DSLSKN - echo-response received during last interval
Sending LCP echo-request with ID 02 and length 8 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:12:00,031  Devicetime: 2011/04/09 09:11:58,990

Received LCP frame from peer T-DSLSKN (channel 2)

LCP echo-response with ID 02 and length 10 to peer T-DSLSKN

[PPP] 2011/04/09 09:12:01,828  Devicetime: 2011/04/09 09:12:00,990

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 06 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:12:12,062  Devicetime: 2011/04/09 09:12:11,230

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 07 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:12:22,312  Devicetime: 2011/04/09 09:12:21,470

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 08 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:12:29,765  Devicetime: 2011/04/09 09:12:28,930

LCP polling timeout for peer T-CLSURF - echo-response received during last interval
Sending LCP echo-request with ID 5a and length 8 to peer T-CLSURF (channel 1)

[PPP] 2011/04/09 09:12:30,000  Devicetime: 2011/04/09 09:12:28,960

Received LCP frame from peer T-CLSURF (channel 1)

LCP echo-response with ID 5a and length 10 to peer T-CLSURF

[PPP] 2011/04/09 09:12:32,546  Devicetime: 2011/04/09 09:12:31,710

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 09 and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:12:42,781  Devicetime: 2011/04/09 09:12:41,950

Received LCP frame from peer T-DSLSKN (channel 2)

Sending LCP echo-response with ID 0a and length 14 to peer T-DSLSKN (channel 2)


[PPP] 2011/04/09 09:12:49,781  Devicetime: 2011/04/09 09:12:48,940

LCP polling timeout for peer T-DSLSKN - echo-response received during last interval
Sending LCP echo-request with ID 03 and length 8 to peer T-DSLSKN (channel 2)

[PPP] 2011/04/09 09:12:50,015  Devicetime: 2011/04/09 09:12:48,990

Received LCP frame from peer T-DSLSKN (channel 2)

LCP echo-response with ID 03 and length 10 to peer T-DSLSKN
Leider ist mir die Deutung des Ergebnisses nicht ganz klar.

Hatte von euch jemand schon mal das Problem das nach einem Verbindungsabbau keine Einwahl mehr möglich war, erst nach einem Kaltstart?

Ich wüsste nicht mehr, nach was ich noch Suchen könnte um das Problem zu beheben.

Grüße
Wolfgang
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Dr.Einstein
Beiträge: 3241
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Hallo logox2,

ich hatte schon 2..3 ähnliche Fälle mit DSL Abbrüchen und keine Wiedereinwahl. Bei all den Kunden ist ein W1821n mit SW 8.00 RU2 aktiv. Auffällig ist, dass die DSLAM Herstellerkennung nicht erkannt wird. Aus meiner Sicht ist das immer ein Zeichen dafür, dass die DSL-Modemtreiber nicht 100% zusammenspielen mit dem DSLAM vom Provider.
Im nördlichen Raum bei Hamburg/Bremen und Raum Düsseldorf bei ADSL1 Anschlüssen ist mir dies häufiger aufgefallen.

Was ich überprüfen würde: Wenn du alles beim Modem auf automatisch stellst, ob dann die DSLAM Herstellerkennung erscheint.

Bei den genannten Fällen half bis dato nur ein externes ADSL-Modem.
Kann natürlich auch mit was ganz anderem zutun haben :(

Gruß Dr.Einstein
Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

Beitrag von logox2 »

Hallo Dr.Einstein,
jetzt hab ich das ADSL mal wieder auf automatisch gestellt, jetzt zeigt er den DSLAM-Hersteller an:
Bild

Dafür zeigt der WebAccess eine Rauschabstand Remote von 235.0 an ?!?
Bild

Bild

Das war's also auch nicht. Dann muss ich weiter suchen .... :(
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Dr.Einstein
Beiträge: 3241
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Wenn durch umsetzen auf automatisch die Hersteller-Kennung erscheint, laufen bei mir die Router DSL technisch stabiler. Sollte nichts helfen, mit externem Modem testen, um eine Providerstörung auszuschließen.
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 2036
Registriert: 12 Nov 2004, 16:04

Beitrag von MoinMoin »

Moin, moin!

> Dafür zeigt der WebAccess eine Rauschabstand Remote von 235.0 an ?!?
Bug im Linecode. Daher steht im LANmonitor auch nichts. Der Wert ist grob durch 10 zu teilen.

Die ADSL-Verbindung scheint ja stabil zu sein. Dann macht ein externes Modem keinen Sinn. Könnte ein Bug sein, der vor ein paar Tagen gefixt wurde.

Ciao, Georg
Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

Beitrag von logox2 »

Hallo MoinMoin,

willst du damit sagen, das es mit der 8.50RC3 vielleicht stabiler läuft?
Bisher muss der Router täglich min 1x kalt gestartet werden. :(

Grüße
Wolfgang
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 2036
Registriert: 12 Nov 2004, 16:04

Beitrag von MoinMoin »

Moin Wolfgang!

Nein, im RC3 ist der Fix noch nicht enthalten.
Ich frage mich allerdings gerade, ob es das überhaupt sein kann. Wie oft wird bei dir denn am Tag die Verbindung zu den Gegenstellen getrennt?

Ciao, Georg
Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

Beitrag von logox2 »

Hallo Georg,
die Verbindung zu T-Online wird (ohne die Reboots) einmal am Tag, die Verbindung zur T-Intra-Select-Plattform >20-30mal unterbrochen.

Nach was muß ich tracen, damit ich erkennen kann, ob der Router oder die Gegenstelle die Verbindung abgebaut hat?

Grüße
Wolfgang
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 2036
Registriert: 12 Nov 2004, 16:04

Beitrag von MoinMoin »

Moin Wolfgang!

Dann könnte es passen. Dem LANCOM gehen vermutlich nach dem 32. Verbindungsabbau die Speicherplätze für zusätzliche MAC-Adressen auf dem WAN-Interface aus. Wenn du die Verbindung zum T-Intra-Select offen halten kannst, dann kommst du möglicherweise auf eine Lebensdauer von rund zwei Wochen.

Wird T-Intra-Select nach Zeit abgerechnet? Oder warum wird da so oft getrennt?

Ciao, Georg
Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

Beitrag von logox2 »

Hallo Georg,
nein, die Intra-Select wird in diesem Fall nach Volumen, aber mit max. €-Obergrenze abgerechnet. Intra-Select ist von Telekom ein Projekt-Angebot, da gibts die unterschiedlichsten Abrechnungsmodelle.

Was ist das für ein Thema mit den MAC-Adressen am WAN? Davon hab ich noch nichts gehört.

Im Router hab ich 9999 als Haltezeit eingestellt, die Verbindung wird aber trotzdem immer wieder mal getrennt (Auszug aus Syslog):

Code: Alles auswählen

04/06/2011 14:33:01;4;5;Successfull logged in to peer T-CLSURF;
04/06/2011 14:33:01;4;5;local IP address for T-CLSURF is 84.147.126.176, remote IP address is 217.0.116.90;
04/06/2011 14:33:02;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 14:33:02;4;5;local IP address for T-DSLSKN is 10.18.2.52, remote IP address is 195.145.165.45;
04/06/2011 14:53:47;4;5;logged out from peer T-DSLSKN;
04/06/2011 14:53:50;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 14:53:51;4;5;local IP address for T-DSLSKN is 10.18.1.102, remote IP address is 195.145.165.45;
04/06/2011 15:13:50;4;5;logged out from peer T-DSLSKN;
04/06/2011 15:13:54;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 15:13:54;4;5;local IP address for T-DSLSKN is 10.18.2.139, remote IP address is 195.145.165.45;
04/06/2011 15:33:54;4;5;logged out from peer T-DSLSKN;
04/06/2011 15:33:57;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 15:33:57;4;5;local IP address for T-DSLSKN is 10.18.0.129, remote IP address is 195.145.165.45;
04/06/2011 15:53:57;4;5;logged out from peer T-DSLSKN;
04/06/2011 15:54:01;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 15:54:01;4;5;local IP address for T-DSLSKN is 10.18.1.128, remote IP address is 195.145.165.45;
04/06/2011 16:14:01;4;5;logged out from peer T-DSLSKN;
04/06/2011 16:14:04;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 16:14:04;4;5;local IP address for T-DSLSKN is 10.18.1.75, remote IP address is 195.145.165.45;
04/06/2011 17:07:52;4;5;logged out from peer T-DSLSKN;
04/06/2011 17:07:56;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 17:07:56;4;5;local IP address for T-DSLSKN is 10.18.2.2, remote IP address is 195.145.165.45;
04/06/2011 17:35:48;4;5;logged out from peer T-DSLSKN;
04/06/2011 17:35:52;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 17:35:52;4;5;local IP address for T-DSLSKN is 10.18.2.73, remote IP address is 195.145.165.45;
04/06/2011 18:05:57;4;5;logged out from peer T-DSLSKN;
04/06/2011 18:06:00;4;5;Successfull logged in to peer T-DSLSKN;
04/06/2011 18:06:00;4;5;local IP address for T-DSLSKN is 10.18.1.75, remote IP address is 195.145.165.45;
04/06/2011 18:43:34;4;5;logged out from peer T-DSLSKN;
04/06/2011 18:44:25;16;3;line polling to peer T-CLSURF failed;
04/06/2011 18:44:31;4;5;logged out from peer T-CLSURF;
Ich kann leider nicht erkennen wieso die Verbindung abgebaut wird. Wie könnte ich das im Trace erkennen, ob der Router oder das Gateway die Verbindung beendet?

Würde mir dann denn ein externes DSL-Modem helfen?

Gibt's eine Lösung für dieses Problem?
Ein Gedanke ist mir jetzt noch dafür gekommen:
Wenn ich für beide Verbindungen unter Kommunikation->Gegenstellen DSL->MAC-Adress-Typ von Lokal auf Global umstelle, funktioniert's vielleicht dann?

Grüße
Wolfgang
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Dr.Einstein
Beiträge: 3241
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Code: Alles auswählen

[PPP] 2011/04/09 09:10:54,984  Devicetime: 2011/04/09 09:10:54,150 

Received LCP frame from peer T-DSLSKN (channel 2) 

Sending LCP echo-response with ID 75 and length 14 to peer T-DSLSKN (channel 2) 


[PPP] 2011/04/09 09:11:05,218  Devicetime: 2011/04/09 09:11:04,390 

Received LCP frame from peer T-DSLSKN (channel 2) 

Sending LCP echo-response with ID 76 and length 14 to peer T-DSLSKN (channel 2) 

[PPP] 2011/04/09 09:11:06,234  Devicetime: 2011/04/09 09:11:05,320 

Received LCP frame from peer T-DSLSKN (channel 2) 
Terminate-Request-Received event for LCP 
Schaut eher aus Richtung des Providers aus. Als wenn die LCP Rück-Meldungen von dir nicht mehr ankommen.

Würdest du die Verbindung bewusst beenden wollen, dann müsste ungefähr folgendes im PPP-Trace stehen:

Code: Alles auswählen

Sending LCP terminate-request with ID 75 and length 14 to peer T-DSLSKN
Gruß Dr.Einstein
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 2036
Registriert: 12 Nov 2004, 16:04

Beitrag von MoinMoin »

Moin, moin!

Der Abbau von T-DSLSKN hat nichts mit dem Modem zu tuen. Wie Dr. Einstein schon geschrieben hat, wird won der Gegenstelle abgebaut. Vermutlich ist da ein Inaktivitäts-Timeout konfiguriert.

Du kannst die Global-Einstellung ja mal probieren. Ich habe keine Ahnung, ob dann überhaupt noch was funktioniert. Merkst du aber sehr schnell.

Ciao, Georg
backslash
Moderator
Moderator
Beiträge: 7132
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi,

einen Idle-Timeout auf Seiten des Proividers kannst du mit einem ICMP-Polling natürlich aushebeln. Da der Idle-Timeout des Providers offenbar 20 Miunten ist, sollte ein ping alle 15 Minuten (= 900 Sekunden) die Leitung offen halten.

Gruß
Backslash
Benutzeravatar
logox2
Beiträge: 18
Registriert: 06 Apr 2011, 20:17
Wohnort: Nürnberg

Beitrag von logox2 »

Hallo,
habe gerade mal den aktuellen Syslog durchgezählt, da komme ich auf insgesamt 52 Login-Vorgänge seit dem letzten Reboot. Kann somit das Problem mit den 32 Logins eigentlich auch nicht sein. Eine Umstellung auf "Global" hab ich da noch nicht ausprobiert.

Für den Ping zum offen halten der Verbindung kann ich doch die Polling-Tabelle verwendenm, oder? Mich irritiert da im Konfigurator "...für nicht PPP-basierte Gegenstellen...."

Somit habe ich wieder das Modem in Verdacht, muß ich halt doch mal einen Speedport davor hängen....

Grüße
Wolfgang
--
Speedport 701V für Entertain
LC1821n 8.50 RC2 für Produktivnetz
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 2036
Registriert: 12 Nov 2004, 16:04

Beitrag von MoinMoin »

Moin Wolfgang!

Laß es dir gesagt sein: da der Sync stabil ist, hat das nichts mit dem Modem zu tuen.

Ciao, Georg
Antworten