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:
parent
76101ec770
commit
303a7f0edf
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=1992
1 changed files with 52 additions and 4 deletions
56
FAQ/FAQ.sgml
56
FAQ/FAQ.sgml
|
@ -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='<peter@taronga.com>'></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>
|
||||
|
|
Loading…
Reference in a new issue