PPTP Server auf der Fritzbox funktioniert

[cuma]

Auf meiner 3020 Testbox klappt es problemlos
Der Fehler ist nicht unbekannt. Hast du

Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs

beachtet? Die Config-Dateien befinden sich jetzt an einer anderen Stelle...

 

[AndreR]

Also die Config ist an der richtigen Stelle vorhanden (/etc/ppp/options.pptp) vorhanden...

Vielleicht ist interessant: ich kann den daemon nicht übers WebIF (Dienste) neustarten, es steht stets "Stopping pptpd ...failed." oder ausführlicher
"Stopping pptpd ...sh: you need to specify whom to kill
failed."
Bei mir arbeitet die Box als IP Client, vielleicht ist das wichtig?

Hier noch die Debug Meldungen etwas ausführlicher:

Mar 25 16:27:03 fritz daemon.debug pptpd[872]: MGR: Launching /usr/sbin/pptpctrl to handle client
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: local address = 192.168.1.2
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: remote address = 192.168.1.210
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: pppd options file = /etc/ppp/options.pptpd
Mar 25 16:27:03 fritz daemon.info pptpd[872]: CTRL: Client xxx.xxx.xxx.xxx control connection started
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Received PPTP Control Message (type: 1)
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Made a START CTRL CONN RPLY packet
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: I wrote 156 bytes to the client.
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Sent packet to client
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Received PPTP Control Message (type: 7)
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Made a OUT CALL RPLY packet
Mar 25 16:27:03 fritz daemon.info pptpd[872]: CTRL: Starting call (launching pppd, opening GRE)
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: pty_fd = 7
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: tty_fd = 8
Mar 25 16:27:03 fritz daemon.debug pptpd[873]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Mar 25 16:27:03 fritz daemon.debug pptpd[873]: CTRL (PPPD Launcher): local address = 192.168.1.2
Mar 25 16:27:03 fritz daemon.debug pptpd[873]: CTRL (PPPD Launcher): remote address = 192.168.1.210
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: I wrote 32 bytes to the client.
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Sent packet to client
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Received PPTP Control Message (type: 15)
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Mar 25 16:27:03 fritz daemon.notice pppd[873]: pppd 2.4.3 started by root, uid 0
Mar 25 16:27:03 fritz daemon.err pppd[873]: Fatal signal 10
Mar 25 16:27:03 fritz daemon.info pppd[873]: Exit.
Mar 25 16:27:03 fritz daemon.err pptpd[872]: GRE: read(fd=7,buffer=4219fc,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Mar 25 16:27:03 fritz daemon.err pptpd[872]: CTRL: PTY read or GRE write failed (pty,gre)=(7,8)
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Reaping child PPP[873]
Mar 25 16:27:03 fritz daemon.info pptpd[872]: CTRL: Client xxx.xxx.xxx.xxx control connection finished
Mar 25 16:27:03 fritz daemon.debug pptpd[872]: CTRL: Exiting now
Mar 25 16:27:03 fritz daemon.debug pptpd[799]: MGR: Reaped child 872

Das Problem ist offensichtlich das Fatal Signal 10...da gibt Google recht wenig zu aus.
und die Logdatei (hab sie mal erstellt)

using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x0 <callback CBCP>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x1 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x2 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x3 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x4 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x4 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x5 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x5 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x6 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x6 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x7 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x7 <callback CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8f9daffb> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x8 <mru 1400> <magic 0x77f47fd2> <pcomp> <accomp> <callback CBCP>]
sent [LCP ConfRej id=0x8 <callback CBCP>]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup

 

[RalfFriedl]

Signal 10 ist schlecht. Kannst Du einen core-dump erstellen lassen, aus dem hervorgeht, wo genau dieser Fehler auftritt?

 

[AndreR]

Wenn du mir sagst wie

 

[RalfFriedl]

Wichtig ist zunächst, daß pppd in einem beschreibbaren Verzeichnis ausgeführt wird. Wenn Du NFS-Root oder USB-Root verwendest, sollte das überall der Fall sein. Sonst kannst Du in ein beschreibbares Verzeichnis wechseln und hoffen, daß pptpd und pppd nicht das Verzeichnis wechseln.
Dann mit "ulimit -c unlimited" die Größe von core-dumps auf unbegrenzt einstellen.

Aus der Shell mit richtigem Verzeichnis und unbegrenzten core-dumps dann pptpd aufrufen und den Fehler reproduzieren.

Es sollte dann eine Datei "core" erstellt werden. Diese kann dann mit gdb untersucht werden.

Wenn Du Dich mit gdb nicht auskennst, kannst Du auch die Datei core, pppd und alle Libraries, die pppd verwendet, hier als Anhang posten.

Nachtrag:
Das Protokoll oben sieht danach aus, als würden die Ausgehenden Pakete bei der Gegenstelle nicht ankommen, zumindest kommt keine Antwort auf die gesendeten Pakete. Es werden aber von der Gegenstelle Pakete empfangen.

Vermutlich ist das das Hauptproblem, und das andere nur eine Folge davon. Trotzdem sollte es nicht passieren.

 

[AndreR]

Puh...
vorweg: ich verwende weder NFS noch USB Root.

Ich habe alle notwendigen Binarys und Config-Files nach /var/tmp/pptp verschoben und die Config auf die neuen Pfade hin abgepasst.
Dann

ulimit -c unlimited

auf der Konsole ausgeführt.
Starten tut der pptpd auch, eine core Datei wird allerdings nicht erstellt. Wahrscheinlich ists n ganz simpler (Denk-)Fehler

 

[RalfFriedl]

Es kommt nicht darauf an, in welchem Verzeichnis sich die Binaries oder deren Config-Dateien befinden, sondern auf das aktuelle Arbeitsverzeichnis zu dem Zeitpunkt, wo der Fehler auftritt.

Wenn Du Glück hast, behält pptpd und pppd das Arbeitsverzeichnis, aus dem sie gestartet wurden. Wenn aber eines dieser Programme oder das Start-Skript in ein nicht beschreibbares Verzeichnis wechselt, dann ist es schwierig.

Ansonsten kannst Du versuchen, dem oben als Nachtrag erwähnten Verbindungs-Problem nachzugehen. Den Grund für das Signal 10 zu finden, ist sicher auch sinnvoll, wird aber vermutlich nur zu einer deutlicheren Fehlermeldung führen und nicht das zugrunde liegende Problem lösen.

 

[arved85]

Hallo,
hab PPTPD und PPTP bei mir auch aktiviert und neugebaut. Nach dem Update fuhr meine Box leider nicht mehr hoch. Nach längerem Probieren hab ich herausgefunden, dass sobald bei mir PPTPD aktiviert ist(in make menuconfig) meine Box, nach einem Firmwareupdate, nicht mehr automatisch hochfährt. Wenn ich nach dem Update die Box aber vom Strom trenne und noch mal neu hochfahren lasse, bootet sie wieder normal. Kommt mir so vor als die Box nicht automatisch neugestartet wird nach nem Update o.ä.. Strom trenn ich erst sobald die Power-LED Dauer leuchtet.

Vielleicht einer ne Idee oder en Tipp?

 

[cuma]

Hast du dieses Problem?

 

[arved85]

Vielen Dank für den Link. Man könnte fast ja sagen, das Phänomen tritt bei mir aber nur bei aktiviertem PPTPD auf.

 

[cuma]

Dort stehen bis jetzt nur Vermutungen, vielleicht liegts ja am pptpd.
Du hast also nur pptpd aktiviert und danach gibg es nicht mehr? Hattest du vorher auch replaced kernel gehabt? Falls ja dann schilder deine Beobachtungen dort doch mal.

 

[wonderdoc]

Wenn ich mich nocht recht erinnere, hatte ich damals zum Test ein Image mit und ohne Replace Kernel gebaut.
Bei beiden war kein PPTPD und PPTP enthalten.
Auch dort war die Box mit replace Kernel nach dem Flashen nicht rebootet.
Vielleicht kann dieses ja mal jemand noch verifizieren.

mfg
Wonderdoc

 

[Silent-Tears]

Das PRoblem mit dem "Nicht-Rebooten" der Box nach dem Flashen mit REPLACE_KERNEL-Images ist bekannt. Dazu gibt es schon ein Ticket im Trac.

Geflashed wird trotzdem korrekt, das Image funktioniert. Somit nur für Leute, die REmote ein Image flashen von wirklicher Relevanz, aber es ist auch dort lösbar.

LG

c.

 

[arved85]

Funktionieren tut alles, da hast recht =)
Ist halt nur bissel mühselig für mich, da ich jetzt immer nach dem Flashen extra in schuppen gehen darf und die Box neustarten muss.
Hab extra ein Image mit Replace-Kernel und ohne PPTPD gebaut, da tritt bei mir der Fehler nicht auf.

 

[Whoopie]

@cuma:
Oliver hat ja Deinen Patch eingecheckt. Ich hätte da eine Frage.

Index: /trunk/make/pptp/files/root/etc/init.d/rc.pptp
===================================================================
--- /trunk/make/pptp/files/root/etc/init.d/rc.pptp (revision 1981)
+++ /trunk/make/pptp/files/root/etc/init.d/rc.pptp (revision 2044)
@@ -44,4 +44,11 @@
 	modprobe ppp_deflate
 	modprobe ppp_mppe_mppc
+
+	if [ ! -z "$PPTP_PRECONN" ]; then
+		echo "$PPTP_PRECONN" > /tmp/pptp_preconn
+		chmod +x /tmp/pptp_preconn
+		/tmp/pptp_preconn
+		rm /tmp/pptp_preconn
+	fi
 
 	$PPPD call pptp $PPTP_OPTIONS

Warum gehst Du den Umweg über ein temp-File? Warum reicht da nicht nur ein $PPTP_PRECONN, da in dem Feld doch ein Programm hinterlegt wird?

Beste Grüße,
Whoopie

 

[cuma]

Hallo,
das hatte ich zuerst auch versucht, allerdings gabs da ein paar Probleme bei manchen Befehlen, zB diesem

echo "Aaa" >> /tmp/x;echo "Bbb" >> /tmp/x;

Weshalb sich dies so verhält kann ich aber nicht sagen

 

[newland]

pptp-1.7.1
not founduild/modified/filesystem/usr/lib/cgi-bin/pptp.cgi
pptpd-1.3.4
not founduild/modified/filesystem/usr/lib/cgi-bin/pptpd.cgi

Hallo ist das schon behoben?

 

[cuma]

Eigentlich seit 1 Woche. Wo hast du das her?
EDIT: Ach ja, das dirclean...

 

[olistudent]

make pptp-dirclean
make pptpd-dirclean

MfG Oliver

 

[newland]

Ich habe die REV 2086 auf mein NAS sollte eigendlich sein .

make dirclean all

Muss mal unter mein file log schauen