os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Mention the openmode delay option in ppp for defeating duplicate

Browse source 
magic number problems.
This commit is contained in:
Brian Somers 1998-01-20 22:48:19 +00:00
parent 9ac04d647b
commit a7dd79a0a7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=2381
1 changed files with 22 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
FAQ/network.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: network.sgml,v 1.5 1998-01-17 14:12:59 brian Exp $ -->
<!-- $Id: network.sgml,v 1.6 1998-01-20 22:48:19 brian Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -322,12 +322,16 @@ default 10.0.0.2 UGSc 0 0 tun0
<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.
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.
<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
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.
@ -348,18 +352,25 @@ default 10.0.0.2 UGSc 0 0 tun0
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:
<p>This can be avoided by allowing the peer to start negotiating
with the following line in your ppp.conf file:
<verb>
set openmode passive
</verb>
<p>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.
<p>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:
<verb>
set openmode active 3
</verb>
<p>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.
<sect2>
<heading>Ppp locks up shortly after connecting</heading>