>From the look of it, it seem to me that it might be a password issue. I usually get those l2tpd messages when I get the password wrong which is easy to find out (always is when you know!).
To debug further pppd add the following lines in /etc/syslog.conf # logging for pppd daemon.*;local2.* /var/log/ppplog then restart syslog. if you get something like "chap authentication failed" it's definitely a username/password issue. You may post your /var/log/ppplog if you want or aren't too sure. Dom -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 05 February 2003 09:00 To: [EMAIL PROTECTED] Subject: Re: rp-l2tpd is closing down Cressatti, Dominique wrote: >am not too sure why it disconnects but >you may want to try l2tpd as I fixed >the packet echo problem (W2K complaining >about loopback detected). > >Dom > > > I've had already tested it and l2tpd (pty.c patched) closes down faster than rp-l2tp after connection has been successfully established : start_pppd: I'm running: "/usr/sbin/pppd" "passive" "-detach" "X.Y.Z.T:A.B.C.D" "file" "/etc/ppp/options" control_finish: Call established with 192.168.0.2, Local: 20076, Remote: 1, Serial: 0 check_control: control, cid = 0, Ns = 4, Nr = 2 ^Hcontrol_xmit: Maximum retries exceeded for tunnel 4092. Closing. call_close : Connection 101 closed to 192.168.0.2, port 1701 (Timeout) check_control: control, cid = 0, Ns = 4, Nr = 2 handle_avps: handling avp's for tunnel 4092, call 0 message_type_avp: message type 6 (Hello) control_xmit: Unable to deliver closing message for tunnel 4092. Destroying anyway.get_call:can't find tunnel 4092 network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 4092 Dumping. get_call:can't find tunnel 4092 network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 4092 Dumping. I'm wondering wether it could be come from peer's IP address : VPN client is getting access on the Internet through an adsl router which is performing NAT; so the LNS is knowing the private address of the client (192.168.0.2) but in fact he's talking with another IP, which is public. Regards, -- BD
