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 --> <!-- The FreeBSD Documentation Project -->
<sect> <sect>
@ -322,12 +322,16 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>Occasionally, just after connecting, you may see messages in <p>Occasionally, just after connecting, you may see messages in
the log that say "magic is the same". Sometimes, these the log that say "magic is the same". Sometimes, these
messages are harmless, and sometimes one side or the other 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 <p>This normally happens on server machines with slow disks that
are spawning a getty on the port, and executing ppp from a are spawning a getty on the port, and executing ppp from a
login script or program after login. The reason is that in login script or program after login. I've also heard reports
the time taken between getty exiting and ppp starting, the 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) client-side ppp starts sending Line Control Protocol (LCP)
packets. Because ECHO is still switched on for the port on packets. Because ECHO is still switched on for the port on
the server, the client ppp sees these packets "reflect" back. 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, Meanwhile, the client, who no longer sees the reflections,
becomes happy just in time to see a hangup from the server. 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 <p>This can be avoided by allowing the peer to start negotiating
in your ppp.conf file: with the following line in your ppp.conf file:
<verb> <verb>
set openmode passive set openmode passive
</verb> </verb>
<p>This tells ppp to wait for the server to initiate LCP negotiations. <p>This tells ppp to wait for the server to initiate LCP
Some servers may never initiate negotiations. If this is the case, negotiations. Some servers however may never initiate negotiations.
please report it as a bug (using send-pr). Ppp will need to be If this is the case, you can do something like:
adjusted so that the user can configure a variable delay before
initiating LCP negotiations. <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> <sect2>
<heading>Ppp locks up shortly after connecting</heading> <heading>Ppp locks up shortly after connecting</heading>