Irgendwas ist faul in Friedberg

Alle Themen rund um die DSL - Produkte

Moderatoren: Yusuf, Florian S., Sven

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Irgendwas ist faul in Friedberg

Beitragvon bastard » 02.05.2007, 16:29

Hallo Technik,

irgendwas ist faul in Friedberg. Mein fli4l trennt per cron jeden Tag um 05:00 Uhr die Verbindung und wählt dann wieder ein. Bislang klappte das auch hervorragend. Aber seit neuestem wird die Verbindung getrennt:

Code: Alles auswählen

Einwahl                 Auswahl                 Online in Sekunden
30.04.2007   05:00:10   01.05.2007   02:47:59   78469
01.05.2007   02:48:20   01.05.2007   05:00:02   7902
01.05.2007   05:00:13   01.05.2007   10:11:17   18664
01.05.2007   10:11:33   01.05.2007   12:16:03   7470
01.05.2007   12:16:17   01.05.2007   14:43:48   8851
01.05.2007   14:44:01   01.05.2007   18:04:03   12002
01.05.2007   18:04:15   01.05.2007   18:17:44   809
01.05.2007   18:18:20   01.05.2007   21:05:26   10026
01.05.2007   21:05:38   02.05.2007   05:00:01   28463
02.05.2007   05:00:10   02.05.2007   05:29:35   1765
02.05.2007   05:29:52   02.05.2007   14:07:29   31057
02.05.2007   14:08:11   02.05.2007   14:13:41   330
02.05.2007   14:13:54   02.05.2007   14:23:52   598


Nach wenigen Sekunden klappts dann wieder. Was ist denn da los am DSLAM? Wackelkontakt? Ich werde, sobald ich zu Hause bin auch noch meinem Modem auf die Finger schauen, ob da was auffälliges signalisiert wird.
Im syslog konnte ich nichts verdächtiges finden.
Könnt Ihr euch vorstellen, an was es liegen könnte?

MfG

Stefan

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 03.05.2007, 07:57

Hallo Technik,

es geht munter weiter:

Code: Alles auswählen

Einwahl                 Auswahl                 Dauer in Sekunden
02.05.2007   14:24:07   02.05.2007   16:39:38   8131
02.05.2007   16:39:54   03.05.2007   03:11:34   37900
03.05.2007   03:11:51   03.05.2007   05:00:01   6490
03.05.2007   05:00:18   03.05.2007   05:05:17   299


(Vertrag Nr. 797566)

Wäre nett, wenn sich einer von Euch das mal näher anschauen könnte.

MfG

Stefan

Jost
M-net Support Team
M-net Support Team
Beiträge: 1383
Registriert: 21.07.2006, 15:50

Beitragvon Jost » 03.05.2007, 10:50

Hallo!
Wohnst du im Augustakom Bereich? Dann schreib doch bitte eine Mail an service@augustakom.de
Gruß,
Jost
M-net Support

s0r
Senior - Member
Senior - Member
Beiträge: 605
Registriert: 23.08.2006, 20:28

Beitragvon s0r » 03.05.2007, 17:36

Jost hat geschrieben:Hallo!
Wohnst du im Augustakom Bereich? Dann schreib doch bitte eine Mail an service@augustakom.de


ja, Friedberg ist im Ak Bereich :p
mit freundlichen Grüßen

s0r

Das Geheimnis des Könnens liegt im Wollen!

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 04.05.2007, 12:25

Hi Jost,

ich glaube zwar nicht, daß dort jemand ist, der mit den Begriffen fli4l, syslog und cron klar kommt - ich habe es trotzdem versucht. Mal sehen was als Antwort kommt.

MfG

Stefan

Benutzeravatar
Tsuran
M-net Support Team
M-net Support Team
Beiträge: 168
Registriert: 25.07.2006, 11:26

Beitragvon Tsuran » 04.05.2007, 12:31

bastard hat geschrieben:Hi Jost,

ich glaube zwar nicht, daß dort jemand ist, der mit den Begriffen fli4l, syslog und cron klar kommt - ich habe es trotzdem versucht. Mal sehen was als Antwort kommt.

MfG

Stefan


Danke für das Kompliment, [ Ticket#: 20070504020 ] wir haben die Anfrage erhalten und schaun uns das mal an.
Viele Grüße aus Augsburg

Robert
M-Net Support

FloScho
Aufsteiger
Aufsteiger
Beiträge: 346
Registriert: 16.04.2007, 00:26

Beitragvon FloScho » 04.05.2007, 12:35

@bastard
how to make friends..........................................

Benutzeravatar
Tsuran
M-net Support Team
M-net Support Team
Beiträge: 168
Registriert: 25.07.2006, 11:26

Beitragvon Tsuran » 04.05.2007, 12:53

Der Grund für die Abbrüche ist auch bereits schon gefunden. Der SNR sowohl im Up/Downstream liegt aktuell im kritischen Bereich von 3 DB, was zu den, auch im Logfile ersichtlichen Conn-Losses, führt. Bei einer TAL Länge von 2 KM auf 0,4 AQS liegt es im Bereich des möglichen, dass die Leitung nicht mehr hergibt.

Auf die sicherlich folgende Frage, warum dies auf einmal auftritt, kann man entweder einen Gerätedefekt, Kabelschaden (interne Verkabelung) oder hohen Beschaltungsgrad angeben.

Mögliche Lösung für dieses Problem:

- Reduzierung der verfügbaren Bandbreite auf 3 MBit [Testweise möglich]
- Tausch des DSL Modems
- Tausch des Splitters / Verkabelung

Wie sollen wir verfahren? Es ist jederzeit möglich die Leitung zu drosseln und somit einen stabileren Zustand herzustellen.
Viele Grüße aus Augsburg



Robert

M-Net Support

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 04.05.2007, 19:17

Hallo Tsuran,

Tsuran hat geschrieben:Wie sollen wir verfahren?


ich habe hier noch 2 Splitter und 3 Modems. Ich werde also in den nächsten Tagen selbst durchtauschen.

MfG

Stefan

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 06.05.2007, 15:34

So, Zwischenstand nach dem Tausch des Splitters und (vor ein paar Stunden) des Modems: Keine Verbesserung.

Ich habe die Gelegenheit genutzt, um Debug-Meldungen vom pppd ins Syslog zu bekommen. Diese Meldungen deuten alle auf ein Problem in der Vermittluingsstelle.

Das Gegenüber hat keine Lust mehr:

Code: Alles auswählen

May  6 02:13:21 wrap pppd[2303]: No response to 5 echo-requests
May  6 02:13:21 wrap pppd[2303]: Serial link appears to be disconnected.
May  6 02:13:21 wrap pppd[2303]: Connect time 22.0 minutes.
May  6 02:13:21 wrap pppd[2303]: Sent 72100 bytes, received 74296 bytes.
May  6 02:13:21 wrap pppd[2303]: Script /etc/ppp/ip-down started (pid 16461)
May  6 02:13:21 wrap pppd[2303]: sent [LCP TermReq id=0x2b "Peer not responding"]
May  6 02:13:24 wrap pppd[2303]: sent [LCP TermReq id=0x2c "Peer not responding"]
May  6 02:13:27 wrap pppd[2303]: Connection terminated.


Daraufhin erfolgt eine Einwahl:

Code: Alles auswählen

May  6 02:13:30 wrap pppd[2303]: Script /etc/ppp/ip-down finished (pid 16461), status = 0x0
May  6 02:13:35 wrap pppd[2303]: Starting link
May  6 02:13:35 wrap pppd[2303]: PADS: Service-Name: ''
May  6 02:13:35 wrap pppd[2303]: PPP session is 3795
May  6 02:13:35 wrap pppd[2303]: using channel 16
May  6 02:13:35 wrap pppd[2303]: Connect: ppp0 <--> eth1
May  6 02:13:35 wrap pppd[2303]: sent [LCP ConfReq id=0x2d <mru 1492> <magic 0x263d570f>]
May  6 02:13:35 wrap pppd[2303]: rcvd [LCP ConfReq id=0x8a <mru 1492> <auth chap MD5> <magic 0x5ae795ed>]
May  6 02:13:35 wrap pppd[2303]: sent [LCP ConfAck id=0x8a <mru 1492> <auth chap MD5> <magic 0x5ae795ed>]
May  6 02:13:35 wrap pppd[2303]: rcvd [LCP ConfAck id=0x2d <mru 1492> <magic 0x263d570f>]
May  6 02:13:35 wrap pppd[2303]: sent [LCP EchoReq id=0x0 magic=0x263d570f]
May  6 02:13:35 wrap pppd[2303]: rcvd [CHAP Challenge id=0xea <f07c848f0e6da4700d6676933274de6bc22e7662f8>, name = "AugustaKom-ERX"]
May  6 02:13:35 wrap pppd[2303]: sent [CHAP Response id=0xea <974f7626cae83baa5dcb99c792c9c08d>, name = "as******@augustakom.net"]
May  6 02:13:35 wrap pppd[2303]: rcvd [LCP EchoRep id=0x0 magic=0x5ae795ed]
May  6 02:13:35 wrap pppd[2303]: rcvd [CHAP Success id=0xea ""]
May  6 02:13:35 wrap pppd[2303]: CHAP authentication succeeded
May  6 02:13:35 wrap pppd[2303]: CHAP authentication succeeded
May  6 02:13:35 wrap pppd[2303]: peer from calling number 00:90:1A:10:03:6D authorized
May  6 02:13:35 wrap pppd[2303]: sent [IPCP ConfReq id=0x1f <addr 62.216.204.201> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
May  6 02:13:35 wrap pppd[2303]: rcvd [IPCP ConfNak id=0x1f <addr 62.216.201.34> <ms-dns1 80.81.6.17> <ms-dns3 80.81.7.3>]
May  6 02:13:35 wrap pppd[2303]: sent [IPCP ConfReq id=0x20 <addr 62.216.201.34> <ms-dns1 80.81.6.17> <ms-dns3 80.81.7.3>]
May  6 02:13:36 wrap pppd[2303]: rcvd [IPCP ConfAck id=0x20 <addr 62.216.201.34> <ms-dns1 80.81.6.17> <ms-dns3 80.81.7.3>]
May  6 02:13:36 wrap pppd[2303]: rcvd [IPCP ConfReq id=0x94 <addr 80.81.4.1>]
May  6 02:13:36 wrap pppd[2303]: sent [IPCP ConfAck id=0x94 <addr 80.81.4.1>]
May  6 02:13:36 wrap pppd[2303]: Local IP address changed to 62.216.201.34
May  6 02:13:37 wrap pppd[2303]: Open UDP 62.216.201.34:1024 -> 80.81.7.3:53
May  6 02:13:37 wrap pppd[2303]: sent [IP data] 45 00 00 40 00 00 40 00 ...


Soweit so gut. Es passieren aber auch Einwahlversuche, die nicht klappen:

Code: Alles auswählen

May  6 08:50:32 wrap pppd[2303]: Starting link
May  6 08:50:32 wrap pppd[2303]: PADS: Service-Name: ''
May  6 08:50:32 wrap pppd[2303]: PPP session is 738
May  6 08:50:32 wrap pppd[2303]: using channel 34
May  6 08:50:32 wrap pppd[2303]: Connect: ppp0 <--> eth1
May  6 08:50:32 wrap pppd[2303]: sent [LCP ConfReq id=0x61 <mru 1492> <magic 0x621ff1d5>]
May  6 08:50:32 wrap pppd[2303]: rcvd [LCP ConfReq id=0xa4 <mru 1492> <auth chap MD5> <magic 0x7ff2301b>]
May  6 08:50:32 wrap pppd[2303]: sent [LCP ConfAck id=0xa4 <mru 1492> <auth chap MD5> <magic 0x7ff2301b>]
May  6 08:50:32 wrap pppd[2303]: rcvd [LCP ConfAck id=0x61 <mru 1492> <magic 0x621ff1d5>]
May  6 08:50:32 wrap pppd[2303]: sent [LCP EchoReq id=0x0 magic=0x621ff1d5]
May  6 08:50:32 wrap pppd[2303]: rcvd [CHAP Challenge id=0xfd <*9935>, name = "AugustaKom-ERX"]
May  6 08:50:32 wrap pppd[2303]: sent [CHAP Response id=0xfd <952951955cfc4fdd712f04d93724916d>, name = "as******@augustakom.net"]
May  6 08:50:32 wrap pppd[2303]: rcvd [LCP EchoRep id=0x0 magic=0x7ff2301b]
May  6 08:50:32 wrap pppd[2303]: rcvd [CHAP Failure id=0xfd ""]

May  6 08:50:32 wrap pppd[2303]: CHAP authentication failed
May  6 08:50:32 wrap pppd[2303]: CHAP authentication failed
May  6 08:50:32 wrap pppd[2303]: sent [LCP TermReq id=0x62 "Failed to authenticate ourselves to peer"]

May  6 08:50:32 wrap pppd[2303]: rcvd [LCP TermReq id=0xa5]
May  6 08:50:32 wrap pppd[2303]: sent [LCP TermAck id=0xa5]
May  6 08:50:32 wrap pppd[2303]: rcvd [LCP TermAck id=0x62]
May  6 08:50:32 wrap pppd[2303]: Connection terminated.


Gleich danach, klappt's aber hervorragend:

Code: Alles auswählen

May  6 08:50:38 wrap pppd[2303]: Starting link
May  6 08:50:38 wrap pppd[2303]: PADS: Service-Name: ''
May  6 08:50:38 wrap pppd[2303]: PPP session is 749
May  6 08:50:38 wrap pppd[2303]: using channel 35
May  6 08:50:38 wrap pppd[2303]: Connect: ppp0 <--> eth1
May  6 08:50:38 wrap pppd[2303]: sent [LCP ConfReq id=0x63 <mru 1492> <magic 0xa6dc7ff1>]
May  6 08:50:38 wrap pppd[2303]: rcvd [LCP ConfReq id=0xa6 <mru 1492> <auth chap MD5> <magic 0x319e1b98>]
May  6 08:50:38 wrap pppd[2303]: sent [LCP ConfAck id=0xa6 <mru 1492> <auth chap MD5> <magic 0x319e1b98>]
May  6 08:50:38 wrap pppd[2303]: rcvd [LCP ConfAck id=0x63 <mru 1492> <magic 0xa6dc7ff1>]
May  6 08:50:38 wrap pppd[2303]: sent [LCP EchoReq id=0x0 magic=0xa6dc7ff1]
May  6 08:50:38 wrap pppd[2303]: rcvd [CHAP Challenge id=0xfe <8837c39ecea284605f8b6867988ad2624c>, name = "AugustaKom-ERX"]
May  6 08:50:38 wrap pppd[2303]: sent [CHAP Response id=0xfe <f9b3f39a4c8b3d842b260c88a7fd15f9>, name = "as******@augustakom.net"]
May  6 08:50:38 wrap pppd[2303]: rcvd [LCP EchoRep id=0x0 magic=0x319e1b98]
May  6 08:50:38 wrap pppd[2303]: rcvd [CHAP Success id=0xfe ""]
May  6 08:50:38 wrap pppd[2303]: CHAP authentication succeeded
May  6 08:50:38 wrap pppd[2303]: CHAP authentication succeeded


Dieser Fehler sollte Euch ebenfalls ermöglichen den Fehler zu lokalisieren:

Code: Alles auswählen

May  6 09:13:51 wrap pppd[2303]: Starting link
May  6 09:13:51 wrap pppd[2303]: PADS: Service-Name: ''
May  6 09:13:51 wrap pppd[2303]: PPP session is 5831
May  6 09:13:51 wrap pppd[2303]: using channel 39
May  6 09:13:51 wrap pppd[2303]: Connect: ppp0 <--> eth1
May  6 09:13:51 wrap pppd[2303]: sent [LCP ConfReq id=0x6f <mru 1492> <magic 0x78fe1b30>]
May  6 09:13:51 wrap pppd[2303]: rcvd [LCP ConfAck id=0x6f <mru 1492> <magic 0x78fe1b30>]
May  6 09:13:54 wrap pppd[2303]: sent [LCP ConfReq id=0x6f <mru 1492> <magic 0x78fe1b30>]
May  6 09:13:54 wrap pppd[2303]: rcvd [LCP ConfAck id=0x6f <mru 1492> <magic 0x78fe1b30>]
May  6 09:13:54 wrap pppd[2303]: rcvd [LCP ConfReq id=0xac <mru 1492> <auth chap MD5> <magic 0x3fca7ce4>]
May  6 09:13:54 wrap pppd[2303]: sent [LCP ConfAck id=0xac <mru 1492> <auth chap MD5> <magic 0x3fca7ce4>]
May  6 09:13:54 wrap pppd[2303]: sent [LCP EchoReq id=0x0 magic=0x78fe1b30]
May  6 09:13:54 wrap pppd[2303]: rcvd [CHAP Challenge id=0x2 <5a968962d0469fcb5977aa8d2eece788e225820f117f8e>, name = "AugustaKom-ERX"]
May  6 09:13:54 wrap pppd[2303]: sent [CHAP Response id=0x2 <b9373fdc6cc6403d7cedfa82b92a80e0>, name = "as******@augustakom.net"]
May  6 09:13:54 wrap pppd[2303]: rcvd [LCP EchoRep id=0x0 magic=0x3fca7ce4]
May  6 09:13:58 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xaa <addr 80.81.4.1>]
May  6 09:13:58 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:01 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xab <addr 80.81.4.1>]
May  6 09:14:01 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:04 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xac <addr 80.81.4.1>]
May  6 09:14:04 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:07 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xad <addr 80.81.4.1>]
May  6 09:14:07 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:10 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xae <addr 80.81.4.1>]
May  6 09:14:10 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:14 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xaf <addr 80.81.4.1>]
May  6 09:14:14 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:17 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb0 <addr 80.81.4.1>]
May  6 09:14:17 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:20 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb1 <addr 80.81.4.1>]
May  6 09:14:20 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:23 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb2 <addr 80.81.4.1>]
May  6 09:14:23 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:24 wrap pppd[2303]: sent [LCP EchoReq id=0x1 magic=0x78fe1b30]
May  6 09:14:24 wrap pppd[2303]: rcvd [LCP EchoRep id=0x1 magic=0x3fca7ce4]
May  6 09:14:41 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb3 <addr 80.81.4.1>]
May  6 09:14:41 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:44 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb4 <addr 80.81.4.1>]
May  6 09:14:44 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:47 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb5 <addr 80.81.4.1>]
May  6 09:14:47 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:50 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb6 <addr 80.81.4.1>]
May  6 09:14:50 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:53 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb7 <addr 80.81.4.1>]
May  6 09:14:53 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:14:54 wrap pppd[2303]: sent [LCP EchoReq id=0x2 magic=0x78fe1b30]
May  6 09:14:54 wrap pppd[2303]: rcvd [LCP EchoRep id=0x2 magic=0x3fca7ce4]
May  6 09:14:57 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb8 <addr 80.81.4.1>]
May  6 09:14:57 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:00 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xb9 <addr 80.81.4.1>]
May  6 09:15:00 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:03 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xba <addr 80.81.4.1>]
May  6 09:15:03 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:06 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xbb <addr 80.81.4.1>]
May  6 09:15:06 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:09 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xbc <addr 80.81.4.1>]
May  6 09:15:09 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:24 wrap pppd[2303]: sent [LCP EchoReq id=0x3 magic=0x78fe1b30]
May  6 09:15:24 wrap pppd[2303]: rcvd [LCP EchoRep id=0x3 magic=0x3fca7ce4]
May  6 09:15:45 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xbe <addr 80.81.4.1>]
May  6 09:15:45 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:48 wrap pppd[2303]: rcvd [IPCP ConfReq id=0xbf <addr 80.81.4.1>]
May  6 09:15:48 wrap pppd[2303]: discarding proto 0x8021 in phase 5
May  6 09:15:51 wrap pppd[2303]: rcvd [LCP TermReq id=0xad]
May  6 09:15:51 wrap pppd[2303]: LCP terminated by peer
May  6 09:15:51 wrap pppd[2303]: sent [LCP TermAck id=0xad]
May  6 09:15:54 wrap pppd[2303]: Connection terminated.
May  6 09:16:02 wrap pppd[2303]: Starting link
May  6 09:16:37 wrap pppd[2303]: Timeout waiting for PADO packets
May  6 09:16:37 wrap pppd[2303]: Unable to complete PPPoE Discovery
May  6 09:16:45 wrap pppd[2303]: Starting link
May  6 09:17:20 wrap pppd[2303]: Timeout waiting for PADO packets
May  6 09:17:20 wrap pppd[2303]: Unable to complete PPPoE Discovery


So. Das war's zunächst mal von meiner Seite. Das selbe maile ich auch noch an den Support, damit es beim Ticket bleibt.

Meine Diagnose bis jetzt deutet auf einen Fehler bei Euch hin. Vielleicht schafft Ihr es ja im laufe des Montags in die Vermittlungstelle zu fahren und dort nach den Komponmenten zu sehen. Viel Erfolg!

MfG

Stefan

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 07.05.2007, 10:57

Hallo Technik,

vielen Dank! Ich war freudig überrascht, daß Ihr gestern (Sonntag) um 16:00 Uhr das Problem lösen konntet.

Darf man erfahren, was in der Vermittlungsstelle faul war?

Und dann tät mich noch interessieren, ob meine Debug-Ausgaben vom pppd hilfreich waren oder nicht.

Jeder der einen 'normalen' Router einsetzt kann ja kaum solche Meldungen bekommen, was macht ihr dann um den Fehler auf die Spur zu kommen?

MfG

Stefan

zaphod
Junior - Member
Junior - Member
Beiträge: 1
Registriert: 07.05.2007, 11:25

Beitragvon zaphod » 07.05.2007, 11:39

Tsuran hat geschrieben:Der Grund für die Abbrüche ist auch bereits schon gefunden. Der SNR sowohl im Up/Downstream liegt aktuell im kritischen Bereich von 3 DB, was zu den, auch im Logfile ersichtlichen Conn-Losses, führt. Bei einer TAL Länge von 2 KM auf 0,4 AQS liegt es im Bereich des möglichen, dass die Leitung nicht mehr hergibt.


Darf ich hier zum Verständnis mal nachfragen? Aus dem Logfile geht ja hervor, dass der pppd keine Antworten auf 5 seiner echo requests bekommen hat. Bei einem Intervall von 30 Sekunden zwischen den Requests heisst das, er hat nach 2,5 Minuten aufgegeben. Eine Neueinwahl ist danach "anscheinend" möglich.

Nun würde mich mal interessieren, was da genau im Hintergrund abläuft:
  • Macht das DSL Modem beim Erkennen von Leitungsproblemen an der Stelle ein zu langes retrainining (neu aushandeln der Leitungsparameter)?
  • Merkt die Gegenseite, dass ein retraining anläuft und beendet den pppd auf ihrer Seite, so daß nach erfolgtem retraining kein pppd auf der Gegenseite mehr da ist?
  • Verwendet die gegenseite ein noch kürzeres LCP intervall und erkennt daher vorher, dass es Probleme gibt?


Oder was ist sonst die Erklärung, dass bis zur nächsten Einwahl niemand mehr da ist, danach aber die Kommunikation bis zum nächsten Problem wieder geht?

MfG,
Zaphod

bastard
Junior - Member
Junior - Member
Beiträge: 31
Registriert: 09.03.2007, 17:21
Kontaktdaten:

Beitragvon bastard » 09.05.2007, 07:42

Hallo,

leider scheinen die Wissenden nicht willens, die noch offenen Fragen zu beantworten ...

MfG

Stefan

WaS
Senior - Member
Senior - Member
Beiträge: 1215
Registriert: 17.08.2006, 15:35
Wohnort: Erlangen

Beitragvon WaS » 09.05.2007, 11:16

Welche Fragen sollen da noch offen sein?

Wenn eine bestimmte Anzahl von LCP echo requests in Folge
unbeantwortet bleiben, dann beendet sich die PPPoE-Verbindung.
Das passiert, wenn zu viele unkorrigierte Übertragungsfehler
auftreten, oder wenn das Modem die Synchronisation gänzlich
verliert.

Ein darauf folgender Einwahlversuch ist erfolgreich, wenn die
Synchronisation noch (oder wieder) besteht und wenn dabei
nicht zu viele unkorrigierte Fehler auftreten. D.h., unmittelbar
nach dem Abbrechen einer PPPoE-Verbindung kann die Leitung
schon wieder "gut genug" sein, dass eine neue Verbindung
zustande kommt -- muss aber nicht.

Christoph Luther
M-net Support Team
M-net Support Team
Beiträge: 506
Registriert: 14.08.2006, 16:37

Beitragvon Christoph Luther » 09.05.2007, 11:26

zaphod hat geschrieben:
  • Macht das DSL Modem beim Erkennen von Leitungsproblemen an der Stelle ein zu langes retrainining (neu aushandeln der Leitungsparameter)?
  • Merkt die Gegenseite, dass ein retraining anläuft und beendet den pppd auf ihrer Seite, so daß nach erfolgtem retraining kein pppd auf der Gegenseite mehr da ist?
  • Verwendet die gegenseite ein noch kürzeres LCP intervall und erkennt daher vorher, dass es Probleme gibt?

- Ob ein retraining stattfindet hängt davon ab, wie gravierend die Störungen sind und hat zunächst nichts mit den LCP keep alives zu tun.
- Die PPP session wird vom AC nach 3 ausbleibenden keep alives terminiert, d. h. ein retraining wird u. U. nicht bemerkt. Eine zweite PPP session mit derselben MAC-Adresse ist jedoch unzulässig und somit muss der subscriber ggf. noch warten bis die session am AC terminiert wurde.
- Das Intervall beträgt 30s.

zaphod hat geschrieben:Oder was ist sonst die Erklärung, dass bis zur nächsten Einwahl niemand mehr da ist, danach aber die Kommunikation bis zum nächsten Problem wieder geht?

MfG,
Zaphod
Bei 5x30s des subscriber Routers ergibt sich ggf. eine Lücke von einer Minute, wenn bitfehlerbendingt nicht nur die LCP echo requests/replies, sondern auch der LCP termination request des AC verloren geht.

Der AC verwendet den LCP keep alive Mechanismus nur, wenn keine Daten übertragen werden.

Mit freundlichen Grüssen

Christoph Luther
M-net Telekommunikations GmbH


Zurück zu „Maxi Komplett / Maxi DSL / Maxi Pur“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste