jonc at haht.com
Thu Jun 28 12:07:42 EDT 2001
Here are some PPP things to check (from the ppp faq), the most likely is
that you need to "set openmode passive" in your ppp.conf file.
10.5. My connection drops after about 3 minutes
The default ppp timeout is 3 minutes. This can be adjusted with the line
set timeout NNN
where NNN is the number of seconds of inactivity before the connection is
closed. If NNN is zero, the connection is never closed due to a timeout. It
is possible to put this command in the ppp.conf file, or to type it at the
prompt in interactive mode. It is also possible to adjust it on the fly
while the line is active by connecting to ppps server socket using telnet(1)
or pppctl(8). Refer to the ppp(8) man page for further details.
10.12. I keep seeing errors about magic being the same
Occasionally, just after connecting, you may see messages in the log that
say ``magic is the same''. Sometimes, these messages are harmless, and
sometimes one side or the other exits. Most ppp implementations cannot
survive this problem, and even if the link seems to come up, you'll see
repeated configure requests and configure acknowledgements in the log file
until ppp eventually gives up and closes the connection.
This normally happens on server machines with slow disks that are spawning a
getty on the port, and executing ppp from a login script or program after
login. I've also heard reports of it happening consistently when using
slirp. The reason is that in the time taken between getty exiting and ppp
starting, the client-side ppp starts sending Line Control Protocol (LCP)
packets. Because ECHO is still switched on for the port on the server, the
client ppp sees these packets ``reflect'' back.
One part of the LCP negotiation is to establish a magic number for each side
of the link so that ``reflections'' can be detected. The protocol says that
when the peer tries to negotiate the same magic number, a NAK should be sent
and a new magic number should be chosen. During the period that the server
port has ECHO turned on, the client ppp sends LCP packets, sees the same
magic in the reflected packet and NAKs it. It also sees the NAK reflect
(which also means ppp must change its magic). This produces a potentially
enormous number of magic number changes, all of which are happily piling
into the server's tty buffer. As soon as ppp starts on the server, it's
flooded with magic number changes and almost immediately decides it's tried
enough to negotiate LCP and gives up. Meanwhile, the client, who no longer
sees the reflections, becomes happy just in time to see a hangup from the
This can be avoided by allowing the peer to start negotiating with the
following line in your ppp.conf file:
set openmode passive
This tells ppp to wait for the server to initiate LCP negotiations. Some
servers however may never initiate negotiations. If this is the case, you
can do something like:
set openmode active 3
This tells ppp to be passive for 3 seconds, and then to start sending LCP
requests. If the peer starts sending requests during this period, ppp will
immediately respond rather than waiting for the full 3 second period.
If that doesn't help, it may be that you are lossing your shell connection
everytime that the server regenerates the encryption keys. I've seen
something similar to that before, but can't remember the fix. But you
should be able to look it up in the ssh faq.
Good luck - Jon Carnes
----- Original Message -----
From: "Uwe Scheffold" <Uwe.Scheffold at waelischmiller.com>
To: <vpn at securityfocus.com>
Sent: Wednesday, June 27, 2001 3:10 AM
Subject: ssh-vpn terminates
> Hi out threre,
> I still have a problem with ssh vpn.
> There is a installation, of a ssh-vpn on a Linux host. This host also
> as firewall with masquerading (ipchains).
> After setup the ssh-vpn everything works fine. But after some time (10 min
> or so) the connetion terminates with:
> Apr 11 11:31:06 c523f pppd: sent [LCP ConfReq id=0x6 <asyncmap 0x0>
> <magic 0x16bd5d1f><pcomp> <accomp>]
> Apr 11 11:31:06 c523f pppd: rcvd [LCP ConfReq id=0x6 <asyncmap 0x0>
> <magic 0x16bd5d1f> <pcomp> <accomp>]
> Apr 11 11:31:06 c523f pppd: sent [LCP ConfNak id=0x6 <magic
> Apr 11 11:31:07 c523f pppd: Modem hangup
> Apr 11 11:31:07 c523f pppd: Connection terminated.
> Apr 11 11:31:07 c523f pppd: Hangup (SIGHUP)
> Apr 11 11:31:07 c523f pppd: Failed to open /dev/ttyp0: Input/output
> Apr 11 11:31:07 c523f last message repeated 8 times
> Apr 11 11:31:07 c523f pppd: Exit.
> Is anybody able to seen the reason for this?
> Best regards: Uwe
> VPN is sponsored by SecurityFocus.com
VPN is sponsored by SecurityFocus.com
More information about the VPN