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

Add a section describing what happens when the peer takes

Browse source 
more than 6 seconds to start up !!!  Yeuch !
Change <tt/ppp/ to <bf/ppp/.
This commit is contained in:
Brian Somers 1998-03-05 22:21:57 +00:00
parent 0de78c9a7b
commit 644afc89be
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=2509
1 changed files with 75 additions and 14 deletions

89
FAQ/network.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: network.sgml,v 1.7 1998-01-29 00:40:02 brian Exp $ -->
<!-- $Id: network.sgml,v 1.8 1998-03-05 22:21:57 brian Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -148,7 +148,7 @@
set log Phase Chat Connect Carrier lcp ipcp ccp command
</verb>
<p>This command may be typed at the <tt/ppp/ command prompt or
<p>This command may be typed at the <bf/ppp/ command prompt or
it may be entered in the <tt>/etc/ppp/ppp.conf</tt> configuration file
(the start of the <bf>default</bf> section is the best place to put it).
Make sure that <htmlurl
@ -190,7 +190,7 @@ default 10.0.0.2 UGSc 0 0 tun0
url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> that doesn't understand the
word <tt/HISADDR/ in the ppp.conf file. If your version of
<tt/ppp/ is from before FreeBSD 2.2.5, change the
<bf/ppp/ is from before FreeBSD 2.2.5, change the
<verb>
add 0 0 HISADDR
@ -258,7 +258,7 @@ default 10.0.0.2 UGSc 0 0 tun0
never closed due to a timeout. It is possible to put this command in
the <tt>ppp.conf</tt> file, or to type it at the prompt in
interactive mode. It is also possible to adjust it on the fly while
the line is active by connecting to <tt/ppp/s server socket using
the line is active by connecting to <bf/ppp/s server socket using
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet">
or <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
name="pppctl">. Refer to the
@ -305,7 +305,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> would wait for the peer to initiate the Line Control
Protocol (LCP). Many ISPs will not initiate negotiations and
expect the client to do so. To force <tt/ppp/ to initiate
expect the client to do so. To force <bf/ppp/ to initiate
the LCP, use the following line:
<verb>
@ -372,16 +372,77 @@ default 10.0.0.2 UGSc 0 0 tun0
this period, ppp will immediately respond rather than waiting for
the full 3 second period.
<sect2>
<heading>
LCP negotiations continue 'till the connection is closed
</heading>
<p>There is currently an implementation mis-feature in <bf/ppp/
where it doesn't associate LCP, CCP &amp; IPCP responses with
their original requests. As a result, if one <bf/ppp/
implementation is more than 6 seconds slower than the other side,
the other side will send two additional LCP configuration requests.
This is fatal.
Consider two implementations, <bf/A/ and <bf/B/. <bf/A/ starts
sending LCP requests immediately after connecting and <bf/B/ takes
7 seconds to start. When <bf/B/ starts, <bf/A/ has sent 3 LCP
REQs. We're assuming the line has ECHO switched off, otherwise
we'd see magic number problems as described in the previous section.
<bf/B/ sends a REQ, then an ACK to the first of <bf/A/'s REQs.
This results in <bf/A/ entering the <bf/OPENED/ state and sending
and ACK (the first) back to <bf/B/. In the meantime, <bf/B/ sends
back two more ACKs in response to the two additional REQs sent by
<bf/A/ before <bf/B/ started up. <bf/B/ then receives the first
ACK from <bf/A/ and enters the <bf/OPENED/ state. <bf/A/ receives
the second ACK from <bf/B/ and goes back to the <bf/REQ-SENT/ state,
sending another (forth) REQ as per the RFC. It then receives the
third ACK and enters the <bf/OPENED/ state. In the meantime,
<bf/B/ receives the forth REQ from <bf/A/, resulting in it reverting
to the <bf/ACK-SENT/ state and sending another (second) REQ and
(forth) ACK as per the RFC. <bf/A/ gets the REQ, goes into
<bf/REQ-SENT/ and sends another REQ. It immediately receives the
following ACK and enters <bf/OPENED/.
<p>This goes on 'till one side figures out that they're getting
nowhere and gives up.
<p>The best way to avoid this is to configure one side to be
<bf/passive/ - that is, make one side wait for the other to start
negotiating. This can be done with the
<verb>
set openmode passive
</verb>
command. Care should be taken with this option. You should also
use the
<verb>
set stopped N
</verb>
command to limit the amount of time that <bf/ppp/ waits for the peer
to begin negotiations. Alternatively, the
<verb>
set openmode active N
</verb>
command (where <bf/N/ is the number of seconds to wait before
starting negotiations) can be used. Check the manual page for
details.
<sect2>
<heading>Ppp locks up shortly after connecting</heading>
<p>Prior to version 2.2.5 of FreeBSD, it was possible that your
link was disabled shortly after connection due to <tt/ppp/
link was disabled shortly after connection due to <bf/ppp/
mis-handling Predictor1 compression negotiation. This would
only happen if both sides tried to negotiate different
Compression Control Protocols (CCP). This problem is now
corrected, but if you're still running an old version of
<tt/ppp/, the problem can be circumvented with the line
<bf/ppp/, the problem can be circumvented with the line
<verb>
disable pred1
@ -390,12 +451,12 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>Ppp locks up when I shell out to test it</heading>
<p>When you execute the <tt/shell/ or <tt/!/ command, <tt/ppp/
executes a shell (or if you've passed any arguements, <tt/ppp/
<p>When you execute the <tt/shell/ or <tt/!/ command, <bf/ppp/
executes a shell (or if you've passed any arguements, <bf/ppp/
will execute those arguements). Ppp will wait for the command
to complete before continuing. If you attempt to use the
ppp link while running the command, the link will appear to have
frozen. This is because <tt/ppp/ is waiting for the command
frozen. This is because <bf/ppp/ is waiting for the command
to complete.
<p>If you wish to execute commands like this, use the
@ -405,7 +466,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>Ppp over a null-modem cable never exits</heading>
<p>There is no way for <tt/ppp/ to automatically determine that
<p>There is no way for <bf/ppp/ to automatically determine that
a direct connection has been dropped. This is due to the
lines that are used in a null-modem serial cable. When using
this sort of connection, LQR should always be enabled with
@ -420,7 +481,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>Why does ppp dial for no reason in -auto mode</heading>
<p>If <tt/ppp/ is dialing unexpectedly, you must determine the
<p>If <bf/ppp/ is dialing unexpectedly, you must determine the
cause, and set up Dial filters (dfilters) to prevent such dialing.
<p>To determine the cause, use the following line:
@ -436,7 +497,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>You can now disable dialing under these circumstances. Usually,
this sort of problem arises due to DNS lookups. To prevent
DNS lookups from establishing a connection (this will <bf/not/
prevent <tt/ppp/ from passing the packets through an established
prevent <bf/ppp/ from passing the packets through an established
connection), use the following:
<verb>
@ -682,7 +743,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<heading>None of this helps - I'm desperate !</heading>
<p>If all else fails, send as much information as you can,
including your config files, how you're starting <tt/ppp/,
including your config files, how you're starting <bf/ppp/,
the relevent parts of your log file and the output of the
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
name="netstat -rn"> command (before and after connecting) to the