LC1721+ Verbindungsabbrüche dann Gegenstelle antwortet nicht

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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:

Dazu hab ich 2 Kommunikationslayer angelegt

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

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

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

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:

[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

Anmeldungsdatum: 12.01.2010 Beiträge: 238

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 Sad

Gruß Dr.Einstein

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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

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

Das war's also auch nicht. Dann muss ich weiter suchen .... Sad

Anmeldungsdatum: 12.01.2010 Beiträge: 238

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.

Moderator Anmeldungsdatum: 12.11.2004 Beiträge: 870

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

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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. Sad

Grüße
Wolfgang

Moderator Anmeldungsdatum: 12.11.2004 Beiträge: 870

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

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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

Moderator Anmeldungsdatum: 12.11.2004 Beiträge: 870

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

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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:

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

Anmeldungsdatum: 12.01.2010 Beiträge: 238

Code:

[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:

Sending LCP terminate-request with ID 75 and length 14 to peer T-DSLSKN

Gruß Dr.Einstein

Moderator Anmeldungsdatum: 12.11.2004 Beiträge: 870

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

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4568 Wohnort: Aachen

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

Anmeldungsdatum: 06.04.2011 Beiträge: 18 Wohnort: Nürnberg

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

Moderator Anmeldungsdatum: 12.11.2004 Beiträge: 870

Moin Wolfgang!

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

Ciao, Georg