Thread Info
  • State Not Answered
  • Replies 41 replies
  • Subscribers 0 subscribers
  • Views 19415 views
  • Users 0 members are here
Options
Suggested

PPTP Patch

oliver.desch
Dear Astaro Users,

first of all I want to apologize for the long waiting time but this error
was a  tough one and it took us a longer to solve the problem.

Don't worry this won't become the standard way to publish patches [;)]
but the PPTP error became such a substantial problem that we think it might
be useful to publish it before the next schedulded up2date will be released.

Note, this is not an official release!

README
http://www.n-zsolt.de/downloads/readme_pptp_patch.txt

PATCH
http://www.n-zsolt.de/downloads/pptp_patch.tar.gz

Your feedback about its functionality is really appreciated.

read you
o|iver
    
  • 0 in reply to Hubinger
    Hubinger,

    makes sense - only configs and patterns will be exchanged. The slave machine cannot 
    determine replaced software pieces.

    read u
    o|iver  
  • 0 in reply to oliver.desch
    Hi Oliver,
    I just have implemented the PPTP-Patch to my homesystem where i was running the dyndns tool too.
    It seems that after the pptp-Patch the dyndns isn't running
    any longer.
    couldt you confirm that or did i made a mistake?
    I come to the pptp-patch on Monday to my HA-Solution ;-)

    Cheers Joachim  
  • 0 in reply to Hubinger
    Hallo Joachim,

    the dyndns client shouldn't be affected at all. Pleases check if it is running 'ps axwfu | grep -i ez'.
    If yes you could try to access an HTTP server with the WebAdmin Connection tool. What happened
    to me was that I turned of the HTTP proxy and the dyndns client couldn't reach the dyndns server
    anymore. Since I was too lazy to sniff to which server the client is connecting to I configured a rule
    that my external interface is allowed to access ANY via HTTP.


    read u
    o|iver  
  • 0 in reply to oliver.desch
    Ok Oliver,
    thanks and i will chekc that this afternoon.

    Cheers Joachim  
  • 0 in reply to oliver.desch
    Hi Oliver,

    sorry for beeing quite for so long, but business eats time...

    OK, it seems that with the upgrade 4.008 -> 4.009 -> 4.010
    the dyndns was deleted?
    Anyhow, i just reimplemented it and now it works ;-)
    CHeers 

    Joachim   
  • 0
    Hi,

    This may seem like a silly question but what issue does this address?

    I've a couple of PPTP isses. For example, a pptp client at home (win2000) cannot connect to an Astaro pptp server when trying to connect through a NATing ADSL router - but is OK when dialing up to the internet via modem . The odd thing is that the ADSL router has passthru and the same Win2000 box can connect to an NT RRAS/PPTP server thru the same ADSL router.  
  • 0 in reply to norwich
    For further info, the errors I'm getting are, on the client
    619: The specified port is not connected

    and in the ASL log (4.010)

    Aug 28 14:49:37 (none) pptpd[6253]: MGR: Launching /usr/local/sbin/pptpctrl to handle client
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: local address = 10.146.5.1
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: remote address = 10.146.5.2
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: pppd options file = /etc/ppp/options
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Client 195.153.124.200 control connection started
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Received PPTP Control Message (type: 1)
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Made a START CTRL CONN RPLY packet
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: I wrote 156 bytes to the client.
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Sent packet to client
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Received PPTP Control Message (type: 7)
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Set parameters to 1525 maxbps, 64 window size
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Made a OUT CALL RPLY packet
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Starting call (launching pppd, opening GRE)
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: pty_fd = 5
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: tty_fd = 6
    Aug 28 14:49:37 (none) pptpd[6254]: CTRL (PPPD Launcher): Connection speed = 115200
    Aug 28 14:49:37 (none) pptpd[6254]: CTRL (PPPD Launcher): local address = 10.146.5.1
    Aug 28 14:49:37 (none) pptpd[6254]: CTRL (PPPD Launcher): remote address = 10.146.5.2
    Aug 28 14:49:37 (none) pppd[6254]: pppd 2.4.2b1 started by (unknown), uid 0
    Aug 28 14:49:37 (none) pppd[6254]: using channel 7
    Aug 28 14:49:37 (none) pppd[6254]: Starting negotiation on /dev/ttyp0
    Aug 28 14:49:37 (none) pppd[6254]: sent [LCP ConfReq id=0x1        ]
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: I wrote 32 bytes to the client.
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Sent packet to client
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Received PPTP Control Message (type: 15)
    Aug 28 14:49:37 (none) pptpd[6253]: CTRL: Got a SET LINK INFO packet with standard ACCMs
    Aug 28 14:49:40 (none) pppd[6254]: sent [LCP ConfReq id=0x1        ]
    Aug 28 14:50:07 (none) pptpd[6253]: GRE: read(fd=5,buffer=804dbe0,len=8196) from PTY failed: status = -1 error = Input/output error
    Aug 28 14:50:07 (none) pptpd[6253]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
    Aug 28 14:50:07 (none) pptpd[6253]: CTRL: Closing child ppp with pid 6254
    Aug 28 14:50:07 (none) pptpd[6253]: CTRL: Client 195.153.124.200 control connection finished
    Aug 28 14:50:07 (none) pptpd[6253]: CTRL: Exiting now
    Aug 28 14:50:07 (none) pptpd[6021]: MGR: Reaped child 6253
    Aug 28 14:50:07 (none) pppd[6254]: LCP: timeout sending Config-Requests 
    Aug 28 14:50:07 (none) pppd[6254]: Connection terminated.
    Aug 28 14:50:07 (none) pppd[6254]: Exit. 
  • 0 in reply to norwich
    Hi norwich,

    your log file looks as if  you are experiencing the issue that is solved with the patch.
    So it's a good idea to apply the patch. If this doesn't help, please enable extensive logging and post the log again.

    Regards,
    Stephan
       
  • 0 in reply to Stephan_Scholz
    Thanks, out of interest, what was the issue? 
  • 0 in reply to norwich
    Hi norwich,

    the patch solves a problem which occurrs exactly in the way that you describe it: Error 619 ("The specified port is not connected") on the Windows Client, and the entry "GRE: read(...) from PTY failed: status = -1 error = Input/output error" on ASL. However, there can be several reasons for this error to occurr, including misconfigurations (what's in common: in all cases the GRE return packets don't reach the PPP daemon). The exact reason can only be located when extensive logging is enabled.

    Stephan
        
Cookie Information Banner