automatische Verbindungstrennung bei Inode, Problem VoIP ?!?

[marvin42]

18:57:47 um
19:35:59 und um
20:11:17 nach 8,1min getrennt.

jup, da hat's jeweils die dsl-leitung gebirnt (ca 5 minuten isses daneben):

Der pptp-client versuchts noch 5 mal mit dem Echo (in jeweils einer Minute Abstand), daher die 5 minütige Verspätung beim Auflegen.

Da das ja nun anscheinend ein Problem mit der Infrastruktur ist, würde ich mich ausklinken.

MfG,
marvin

[lahe]

Der pptp-client versuchts noch 5 mal mit dem Echo (in jeweils einer Minute Abstand), daher die 5 minütige Verspätung beim Auflegen.

Da das ja nun anscheinend ein Problem mit der Infrastruktur ist, würde ich mich ausklinken.

MfG,
marvin

[dfx]

Eine Störmeldung gab es in diesem Zusammenhang noch keine.

dann würd ich mal dort ansetzen. wenn du nix dagegen hast, werd ich das veranlassen, dann werden die kollegen die sache mal genauer unter die lupe nehmen und (hoffentlich) rausfinden, warum die leitung nicht synchron bleibt...

[lahe]

Eine Störmeldung gab es in diesem Zusammenhang noch keine.

dann würd ich mal dort ansetzen. wenn du nix dagegen hast, werd ich das veranlassen, dann werden die kollegen die sache mal genauer unter die lupe nehmen und (hoffentlich) rausfinden, warum die leitung nicht synchron bleibt...

Ja bitte, das wäre super von Dir wenn Du Dich der Sache annehmen könntest. Sollten irgendwelche Logfiles von mir benötigt werden dann sag mir bitte Bescheid. Nach durchsicht der Logfiles ist es aber immer der selbe Fehler, dass der pptp Client auf ein Echo wartet und nach 5 Minuten auflegt.

Sep 26 20:08:17 Server syslog: pptp-client log[pptp_handle_timer:pptp_ctrl.c:1042]: missing echo reply, 3 left until closing down connection
Sep 26 20:08:17 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:246]: Sent control packet type is 5 'Echo-Request'
Sep 26 20:09:17 Server syslog: pptp-client log[pptp_handle_timer:pptp_ctrl.c:1042]: missing echo reply, 2 left until closing down connection
Sep 26 20:09:17 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:246]: Sent control packet type is 5 'Echo-Request'
Sep 26 20:09:55 Server kernel: fw-input-reject IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:a0:c5:81:5c:e6:08:00 SRC=10.202.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=1405 PROTO=2
Sep 26 20:10:17 Server syslog: pptp-client log[pptp_handle_timer:pptp_ctrl.c:1042]: missing echo reply, 1 left until closing down connection
Sep 26 20:10:17 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:246]: Sent control packet type is 5 'Echo-Request'
Sep 26 20:11:17 Server syslog: pptp-client log[pptp_handle_timer:pptp_ctrl.c:1042]: missing echo reply, 0 left until closing down connection
Sep 26 20:11:17 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:246]: Sent control packet type is 12 'Call-Clear-Request'
Sep 26 20:11:17 Server syslog: pptp-client log[pptp_conn_close:pptp_ctrl.c:428]: Closing PPTP connection
Sep 26 20:11:17 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:246]: Sent control packet type is 3 'Stop-Control-Connection-Request'
Sep 26 20:11:17 Server syslog: pptp-client log[call_callback:pptp_callmgr.c:77]: Closing connection
Sep 26 20:11:17 Server pppd[1305]: Script pptp-client 10.0.0.138 --nolaunchpppd --sync --ignorebuffer --loglevel 2 --logstring pptp-client finished (pid 3173), status = 0x0
Sep 26 20:11:17 Server pppd[1305]: Modem hangup
Sep 26 20:11:17 Server pppd[1305]: Script /etc/ppp/ip-down started (pid 3306)
Sep 26 20:11:17 Server pppd[1305]: Connection terminated.
Sep 26 20:11:17 Server pppd[1305]: Connect time 8.1 minutes.

PS: vielleicht löst das ganze auch das Problem mit VoIP !
http://xDSL.at/phpbb2/viewtopic.php?p=1 ... ht=#157390

Danke

lahe (106360)

[SeniorErklärbär]

Wa bitte, das wäre super von Dir wenn Du Dich der Sache annehmen könntest.

Hab eine Störung aufgenommen, werden sich die entsprechenden Mitarbeiter ansehen und sich bei Fragen bzw. Problembehebung bei dir melden.

LG, SeniorErklärbär

[Andreas2000]

So und jetzt mal die prinzipielle Frage:

ich habe vor meinen FLI4L von 2.1.7 auf 2.1.8 upzudaten. Brauche ich nun den pptp Patch oder nicht?

Habe mit meinem 2.1.7er keinerlei Verbindungsabbrüche oder ähnliches - auch VoIP funktioniert tadellos.

Liegt das Problem von lahe nun an der 2.1.8er von FLI4L oder an der Leitungsinfrastruktur?

Bitte um Aufklärung

[marvin42]

Liegt das Problem von lahe nun an der 2.1.8er von FLI4L oder an der Leitungsinfrastruktur?

Ich kann mir nicht vorstellen, daß fli4l irgendeinen Einfluß auf die Stabilität der dsl Leitung hat Das Problem war eigentlich hier nur, daß der pptp-client wegen eines fehlenden echo replies aufgelegt hat, aber keinen Ton über die Ursache hat verlauten lassen. Wenn da gestanden hätte, daß die Gegenseite nicht mehr reagiert, hätte man vielelicht gleich nach einem Leitungsproblem suchen können.

Mfg,
Marvin

[dfx]

also das erste beschriebene problem (hier) war schon ein problem des pptp clients im fli4l. nachdem dieses behoben war, gab's halt noch andere troubles, aber das ist ne andere geschichte.

[marvin42]

also das erste beschriebene problem (hier) war schon ein problem des pptp clients im fli4l. nachdem dieses behoben war, gab's halt noch andere troubles, aber das ist ne andere geschichte.

Hier würde mich mal der Code pfad interessieren, der dazu führen sollte, daß bei excessiv gedroppten gre paketen die Verbindung geschlossen wird. Alles was ich beim Lesen des Codes gesehen habe, deutete darauf hin, daß es die ganze Zeit ein ausstehendes echo reply war, das zum Schliessen der Verbindung geführt hat. Alle anderen pptp_conn_close Aufrufe waren im Verbindungsaufbau oder bei Erhalt eines nicht interpretierbaren Control-Paketes. Letzteres wäre gelogged worden, im hier geposteten Log stand nichts drin.

Und Nochmal: Der pptp-client hat nie hingeschrieben, daß er die Verbindung wegen eines ausstehenden Echo replies geschlossen hat, das fehlte einfach im Code. Es kann also durchaus die ganze Zeit ein und dieselbe Ursache gewesen sein. Ich würde es zumindest sehr seltsam finden, wenn nach Einbau der "auf keinen Fall puffern" option plötzlich die DSL-Leitung instabil wird und zu exact den selben Symptomen führt.

MfG,
Marvin

[dfx]

Alles was ich beim Lesen des Codes gesehen habe, deutete darauf hin, daß es die ganze Zeit ein ausstehendes echo reply war, das zum Schliessen der Verbindung geführt hat.

im endeffekt war natürlich das der grund (allerdings lcp echo replies, nicht pptp echo replies), aber (im ersten fehlerfall dieses threads) war die eigentliche ursache eine andere: der pptp-client in der standardversion schenkt den sequence numbers der gre-encapsulation zu viel beachtung.

beispiel: pptp-client empfängt paket mit seqnum 10. somit erwartet er als nächstes ein paket mit der nummer 11. dieses geht nun aber verloren, und der pptp-client empfängt statt dessen nur das übernächste paket mit der nummer 12. der pptp-client geht nun davon aus, daß das paket mit der nummer 11 irgendwann später eintrifft, puffert das paket 12 und leitet es (erstmal) nicht an die oberen layers (pppd) weiter. ebenso behandelt er die weiteren pakete 13, 14 usw. erst wenn er das fehlende paket 11 bekommen würde oder ein timeout der puffers zuschlägt, würde er die gepufferten pakete allesammt an die oberen layers weiterleiten.

ebenso, und teilweise mit gravierenderen auswirkungen, behandelt der pptp-client andere situation, in denen die sequence numbers nicht regelmäßig ansteigend eintreffen. im endeffekt erhält der pppd keine lcp echo requests (oder sonstigen pakete) mehr für längere zeit, wodurch er irgendann die connection beendet.

aber die pptp rfc sagt ausdrücklich, daß die sequence numbers nur zur "congestion control" verwendet werden dürfen und u.u. zum reordering der pakete, ein peer aber nie verlorene gre-pakete neu verschickt (wie zb tcp es macht). somit ist diese ganze pufferung von paketen zwar ganz nett, wenn dauerhaft genau 0.0% packet loss existieren; sie wirkt sich aber teilw. katastrophal aus, wenn pakete verlorengehen (was automatisch der fall ist, sobald die leitung belastet ist, wie zb bei downloads oder uploads).

[marvin42]

Alles was ich beim Lesen des Codes gesehen habe, deutete darauf hin, daß es die ganze Zeit ein ausstehendes echo reply war, das zum Schliessen der Verbindung geführt hat.

im endeffekt war natürlich das der grund (allerdings lcp echo replies, nicht pptp echo replies),

Ich meine wirklich pptp echo replies, also die hier beschriebenen: http://xdsl.at/phpbb2/viewtopic.php?t=26001&start=19.

3.1.4 Keep Alives and Timers

A control connection SHOULD be closed by closing the underlying TCP connection under the following circumstances:
...
2 If a peer's control connection is in the established state and has not received a control message for 60 seconds, it SHOULD send a Echo-Request message. If an Echo-Reply is not received 60 seconds after the Echo-Request message transmission, the control connection SHOULD be closed.

Und da die Controlmessages des pptp-clients ja über eine tcp-Verbindung gehen, muß schon einiges passieren, daß das echo reply nicht innerhalb von 60 Sekunden eintrifft, was dann zum auflegen des pptp-clients führt.

ebenso, und teilweise mit gravierenderen auswirkungen, behandelt der pptp-client andere situation, in denen die sequence numbers nicht regelmäßig ansteigend eintreffen. im endeffekt erhält der pppd keine lcp echo requests (oder sonstigen pakete) mehr für längere zeit, wodurch er irgendann die connection beendet.

Das Log zeigte aber, daß der pptp-client den Verbindungsabbau initiierte und nicht der pppd aufgrund ausstehender lcp echo replies:

Code: Alles auswählen

Sep 19 23:28:43 Server syslog: pptp-client log[pptp_conn_close:pptp_ctrl.c:425]: Closing PPTP connection
Sep 19 23:28:43 Server syslog: pptp-client log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 3 'Stop-Control-Connection-Request'
Sep 19 23:28:43 Server syslog: pptp-client log[call_callback:pptp_callmgr.c:77]: Closing connection
Sep 19 23:28:43 Server pppd[2037]: Modem hangup


Diese Sequenz war immer dieselbe, der pptp-client baut die Vervindung ab, beendet sich und danach sagt der pppd, das Modem hätte aufgelegt.

Ich denke immer noch, daß wir hier die ganze Zeit ein und denselben Fehler gesehen haben.

MfG,
Marvin

[dfx]

Ich denke immer noch, daß wir hier die ganze Zeit ein und denselben Fehler gesehen haben.

schon möglich. das problem mit den sequence numbers ist jedenfalls real und der angesprochene patch schafft auch abhilfe. ob in diesem fall das je ein problem war, kann ich nicht sagen, es ist aber jedenfalls eine weitere fehlerquelle eliminiert.

[lahe]

... ein Log von einem Tag

http://members.inode.at/b.aichberger/Log2728.txt

Auszug:

Sep 27 12:13:48 Server pppd[1306]: Modem hangup
Sep 27 18:58:13 Server pppd[1306]: Modem hangup
Sep 27 19:26:23 Server pppd[1306]: Modem hangup
Sep 27 20:25:39 Server pppd[1306]: Modem hangup
Sep 27 20:38:10 Server pppd[1306]: Modem hangup
Sep 27 22:46:39 Server pppd[1306]: Modem hangup
Sep 27 23:53:56 Server pppd[1306]: Modem hangup
Sep 28 00:02:00 Server pppd[1306]: Modem hangup
Sep 28 00:26:26 Server pppd[1306]: Modem hangup
Sep 28 00:33:54 Server pppd[1306]: Modem hangup
Sep 28 00:39:45 Server pppd[1306]: Modem hangup
Sep 28 01:15:24 Server pppd[1306]: Modem hangup
Sep 28 01:45:37 Server pppd[1306]: Modem hangup
Sep 28 01:51:53 Server pppd[1306]: Modem hangup
Sep 28 02:02:26 Server pppd[1306]: Modem hangup
Sep 28 02:21:56 Server pppd[1306]: Modem hangup
Sep 28 04:29:39 Server pppd[1306]: Modem hangup
Sep 28 04:57:15 Server pppd[1306]: Modem hangup
Sep 28 05:16:26 Server pppd[1306]: Modem hangup


lahe

[Andreas2000]

@lahe:

Hast Du schon mal den 2.1.7er FLI4L probiert? Wäre interessant, ob dort die gleichen Troubles auftreten oder nicht - wie gesagt, bei mir läuft die 2.1.7er stabil seitdem ich INODE habe (also Mai) und momentan bin ich aufgrund deiner Troubles noch ein wenig in Abwartestellung was bei mir eine Umstellung auf 2.1.8 betrifft. Obwohl der neue Paketfilter der 2.1.8 mir das Leben schon um einiges erleichtern würde...

Solltest Du das mit der 2.1.7er probieren wollen, kann ich dir gerne die letzte Version mit Patch zukommen lassen - musst nur sagen, was Du alles brauchen würdest.

lg
Andreas.

[lahe]

@lahe:

Hast Du schon mal den 2.1.7er FLI4L probiert? Wäre interessant, ob dort die gleichen Troubles auftreten oder nicht - wie gesagt, bei mir läuft die 2.1.7er stabil seitdem ich INODE habe (also Mai) und momentan bin ich aufgrund deiner Troubles noch ein wenig in Abwartestellung was bei mir eine Umstellung auf 2.1.8 betrifft. Obwohl der neue Paketfilter der 2.1.8 mir das Leben schon um einiges erleichtern würde...

Solltest Du das mit der 2.1.7er probieren wollen, kann ich dir gerne die letzte Version mit Patch zukommen lassen - musst nur sagen, was Du alles brauchen würdest.

lg
Andreas.

@Andreas

hatte die 2.1.7 zuerst mit Aon im Einsatz. Hatte nie ein Problem.
Bin dann am 02.09 entbündelt worden und habe nur im dsl Paket die Benutzerdaten und den Modemtyp bzw. in der Base die DNS Server geändert. Hat auf anhieb funktioniert. Habe damals aber auch schon die Verbindungstrennungen gehabt.

Also, meiner Meinung nach kannst du 2.1.8 ruhig installieren.

lahe