From 303a7f0edf601211028cca87a2b1bc5f03e3df75 Mon Sep 17 00:00:00 2001 From: Brian Somers Date: Tue, 23 Sep 1997 23:48:27 +0000 Subject: 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 :-( --- FAQ/FAQ.sgml | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 4 deletions(-) (limited to 'FAQ/FAQ.sgml') diff --git a/FAQ/FAQ.sgml b/FAQ/FAQ.sgml index de347ab5e6..865661f158 100644 --- a/FAQ/FAQ.sgml +++ b/FAQ/FAQ.sgml @@ -1,12 +1,12 @@ - +
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> -- cgit v1.3