Say a few words about ECHO reflections and magic being

the same.
I really think the ppp rfc should say that the server *must*
initiate LCP negotiations - otherwise things like this happen :-(
This commit is contained in:
Brian Somers 1997-09-23 23:48:27 +00:00
parent 76101ec770
commit 303a7f0edf
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=1992

View file

@ -1,12 +1,12 @@
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
<!-- $Id: FAQ.sgml,v 1.73 1997-09-21 12:35:36 brian Exp $ -->
<!-- $Id: FAQ.sgml,v 1.74 1997-09-23 23:48:27 brian Exp $ -->
<article>
<title>Frequently Asked Questions for FreeBSD 2.X
<author>Maintainer: Peter da Silva <tt><htmlurl url='mailto:peter@taronga.com'
name='&lt;peter@taronga.com&gt;'></tt>
<date>$Date: 1997-09-21 12:35:36 $</date>
<date>$Date: 1997-09-23 23:48:27 $</date>
<abstract>
This is the FAQ for FreeBSD systems version 2.X All entries are
@ -3329,8 +3329,56 @@ MYADDR:
<verb>
set openmode active
</verb>
<bf/Note/: It does no harm if both sides initiate negotiation,
so openmode is now active by default.
<bf/Note/: It usually does no harm if both sides initiate
negotiation, so openmode is now active by default. However,
the next section explains when it <bf/does/ do some harm.
<sect2>
<heading>I keep seeing errors about magic being the same</heading>
<p>
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.
<p>
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. 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.
<p>
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 servers 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 server.
<p>
The only way to circumvent this is to put the following line
in your ppp.conf file:
<verb>
set openmode passive
</verb>
This tells ppp to wait for the server to initiate LCP
negotiations. Some servers may never initiate negotiations.
If this is the case, please report it as a bug (using send-pr).
Ppp will need to be adjusted so that the user can configure a
variable delay before initiating LCP negotiations.
<sect2>
<heading>Ppp locks up shortly after connecting</heading>