[pptp-server] Assigned IP addresses, and dropping the connection

[Ron Cresswell]

The latest info - 

The problem is in fact at the server end. I can seem to clean up the
client alright, but the server doesn't seem to tidy up after itself
after it drops the connection (pppd drops the line, but pptpd is still
running). I might start this question again as a new thread as I think
the client end is alright (for the moment!). Your summary of closing the
client was correct - thanks for that!

Cheers

Ron

Steve Sarette wrote:
> 
> Ron Cresswell wrote:
> 
> > Thanks for that Steve - your memory is good! I am writing a script to
> > restart the connection if it drops, which is why "reboot" isn't a good
> > option!
> >
> > A couple of other questions arising. I did what you suggested and
> > everything was fine - but I still couldn't reconnect. The pptp client
> > responds with the following message:
> >
> > [root at jabba scripts]# pptp-up
> > warn[open_inetsock:pptp_callmgr.c:287]: connect: Connection refused
> > fatal[callmgr_main:pptp_callmgr.c:122]: Could not open control
> > connection to 203.7.194.163
> > fatal[launch_callmgr:pptp.c:213]: Call manager exited with error 256
> 
> Um, what do your routes look like?  I've never tried setting my default
> route across the pptp connection and then dropping the connection (and I
> don't know if that's what you're doing or not).  Is is possible that you
> can't find a route to 203.7.194.163?  Can you ping it?
> 
> Also, look over your firewall rules before and after the connection and
> make sure you can still move the pptp packets through.  Maybe something
> is getting reset there on the ppp shutdown?
> 
> Other than that, I'll have to go through this again tonight and see if I
> missed anything in my restart sequence. It sure feels like you still
> have the call manager thread running.
> 
> >
> > there are no files left in /var/run/pptp, "ps -ef | grep -i pp" returns
> > no relevant processes (so there are no pptp or ppp processes left). And
> > ifconfig shows only eth0 and lo. So what else could there be? There are
> > no entries in /var/log/messages, so the pptp client isn't even getting
> > as far as trying to contact the server at the far end. Any ideas?
> >
> > One other thing - any idea how to set (or unset) the timeout on the
> > pptpd server? I don't really want it dropping the connection ever,
> > certainly not by choice! Is it an option that can be added in
> > /etc/pptpd.conf?
> 
> No idea, I've never tried to use pptpd.  I was just playing with the
> client end of things.  Which I never really got to work, I should add.
> I could authenticate in and ping the network but all my other tcp/ip
> activity hangs.  I've pretty much given up on this for now.  I'm just
> hanging out on this list hoping that someone will say something one of
> these days that makes me go "D'oh!  Didn't try that..."
> 
> - Steve
> 
> >
> > Thanks again
> >
> > Cheers
> >
> > Ron
> >
> > Steve Sarette wrote:
> >
> >> Ron Cresswell wrote:
> >>
> >> <snippage (because I don't know the answer)>
> >>
> >>> Also, is there a way to cleanly drop this connection?
> >>
> >> become root
> >> ifconfig ppp0 down
> >> kill -HUP `cat /var/run/ppp0.pid`  (not sure of the exact file name, but
> >> it's something like that)
> >> rm /var/run/pptp/<the ip that you connected to>
> >>
> >> I think you also have to kill an additional pptp process.  The FAQ says
> >> that killing the ppp process should kill off the pptp processes too but
> >> I always see one hanging around.  Just do:
> >>
> >> ps -ef | grep pptp
> >>
> >> and kill the process that you see.
> >>
> >> Sorry that I can't be more explicit but I'm on a machine that doesn't
> >> have all this stuff configured so I'm writing this from memory.  Also,
> >> probably there's a cleaner way to go about dropping the connection but I
> >> haven't found it yet.
> >>
> >> Good luck.
> >>
> >> - Steve
> >>
> >> The only way I can
> >>
> >>> clean the thing out to start a new connection is to reboot!
> >>>   It seems that the server times out, and drops the PPP interface, but
> >>> that interface is still hanging around on the client, even though the
> >>> log file says:
> >>>
> >>> 1 14:15:50 jabba pppd[709]: Connect: ppp0 <--> /dev/ttya0
> >>> Nov  1 14:15:54 jabba pppd[709]: Remote message: Welcome to ghost.
> >>> Nov  1 14:15:54 jabba kernel: PPP BSD Compression module registered
> >>> Nov  1 14:15:54 jabba kernel: PPP Deflate Compression module registered
> >>> Nov  1 14:15:55 jabba pppd[709]: Deflate (15) compression enabled
> >>> Nov  1 14:15:57 jabba pppd[709]: Cannot determine ethernet address for
> >>> proxy ARP
> >>> Nov  1 14:15:57 jabba pppd[709]: local  IP address 203.7.194.34
> >>> Nov  1 14:15:57 jabba pppd[709]: remote IP address 203.7.194.159
> >>> Nov  1 14:21:20 jabba (unknown)[706]:
> >>> log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:671]: Call closed (NTFY) (call
> >>> id 0)
> >>> Nov  1 14:27:57 jabba inetd[503]: pid 753: exit status 1
> >>>
> >>> The log file at the server end says this:
> >>>
> >>> Nov  1 14:15:10 ghost pppd[709]: Connect: ppp0 <--> /dev/pts/0
> >>> Nov  1 14:15:12 ghost pptpd[708]: GRE: Discarding duplicate packet
> >>> Nov  1 14:15:14 ghost kernel: PPP BSD Compression module registered
> >>> Nov  1 14:15:14 ghost kernel: PPP Deflate Compression module registered
> >>> Nov  1 14:15:14 ghost pppd[709]: CHAP peer authentication succeeded for
> >>> ron
> >>> Nov  1 14:15:14 ghost pppd[709]: Deflate (15) compression enabled
> >>> Nov  1 14:15:16 ghost pppd[709]: Cannot determine ethernet address for
> >>> proxy ARP
> >>> Nov  1 14:15:16 ghost pppd[709]: local  IP address 203.7.194.128
> >>> Nov  1 14:15:16 ghost pppd[709]: remote IP address 203.7.194.1
> >>> Nov  1 14:15:24 ghost PAM_pwdb[748]: (login) session opened for user ron
> >>> by (uid=0)
> >>> Nov  1 14:15:34 ghost PAM_pwdb[769]: (su) session opened for user root
> >>> by ron(uid=500)
> >>> Nov  1 14:20:30 ghost pptpd[708]: CTRL: Session timed out, ending call
> >>> Nov  1 14:20:30 ghost pptpd[708]: CTRL: Client 203.7.194.33 control
> >>> connection finished
> >>> Nov  1 14:20:30 ghost pppd[709]: Modem hangup
> >>> Nov  1 14:20:30 ghost pppd[709]: Connection terminated.
> >>> Nov  1 14:20:30 ghost pppd[709]: Connect time 5.4 minutes.
> >>> Nov  1 14:20:30 ghost pppd[709]: Sent 562 bytes, received 669 bytes.
> >>> Nov  1 14:20:30 ghost pppd[709]: Exit.
> >>> Nov  1 14:30:00 ghost kernel: PPP: ppp line discipline successfully
> >>> unregistered
> >>
> >> _______________________________________________
> >> pptp-server maillist  -  pptp-server at lists.schulte.org
> >> http://lists.schulte.org/mailman/listinfo/pptp-server
> >> List services provided by www.schulteconsulting.com!

-- 
Ron Cresswell---CFD&EM Manager---Compumod Pty Ltd
Level 7---271 William St---Melbourne---Australia
---Ph.+61 3 9642 0333---Fax +61 3 9642 0330---