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

Standardize on PPP for the protocol and &man.ppp.8; for the program in

Browse source 
the PPP section of the FAQ.

Reviewed by:	nik, Tom Rhodes <darklogik@pittgoth.com>
This commit is contained in:
Giorgos Keramidas 2002-01-15 15:07:09 +00:00
parent 37e03e83cc
commit 38abc2d2da
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=11709
1 changed files with 71 additions and 71 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

142
en_US.ISO8859-1/books/faq/book.sgml
View file

@ -4578,7 +4578,7 @@ IO range check 0x00 activate 0x01</screen>
</listitem>
<listitem>
<para>Break the warnings by installing parallel port
hardware that uses irq 7 and the ppp driver for it (this
hardware that uses irq 7 and the PPP driver for it (this
happens on most systems), and install an ide drive or
other hardware that uses irq 15 and a suitable driver
for it.</para>
@ -6939,7 +6939,7 @@ parse returns: $# uucp-dom $@ <replaceable>your.uucp.relay</replaceab
the rest.</para>
<para>If you have got a dynamically assigned IP number and use a
dialup <application>ppp</application> connection to the
dialup PPP connection to the
Internet, you will probably be given a mailbox on your ISPs
mail server. Lets assume your ISPs domain is
<hostid role="domainname">myISP.com</hostid>, and that your user name is
@ -6951,7 +6951,7 @@ parse returns: $# uucp-dom $@ <replaceable>your.uucp.relay</replaceab
<para>In order to retrieve mail from your mailbox, you will need
to install a retrieval agent. <application>Fetchmail</application> is a good choice as it supports
many different protocols. Usually, POP3 will be provided by
your ISP. If you have chosen to use user-ppp, you can
your ISP. If you have chosen to use user-PPP, you can
automatically fetch your mail when a connection to the 'net is
established with the following entry in
<filename>/etc/ppp/ppp.linkup</filename>:</para>
@ -8829,8 +8829,8 @@ Key F15 A A Menu Workplace Nop</programlisting>
to access the Internet from the Windows95 box through the
FreeBSD box. This is really just a special case of the previous
question.</para> <para>... and the answer is yes! In FreeBSD
3.x, user-mode ppp contains a <option>-nat</option> option. If
you run <application>ppp</application> with the <option>-nat</option>,
3.x, user-mode &man.ppp.8; contains a <option>-nat</option> option. If
you run &man.ppp.8; with the <option>-nat</option>,
set <literal>gateway_enable</literal> to
<emphasis>YES</emphasis> in <filename>/etc/rc.conf</filename>,
and configure your Windows machine correctly, this should work
@ -8841,7 +8841,7 @@ Key F15 A A Menu Workplace Nop</programlisting>
URL="../ppp-primer/index.html">
Pedantic PPP Primer</ulink> by Steve Sims.</para>
<para>If you are using kernel-mode ppp, or have an Ethernet
<para>If you are using kernel-mode PPP, or have an Ethernet
connection to the Internet, you will have to use
&man.natd.8;. Please look at the
<link linkend="natd">natd</link> section of this FAQ.</para>
@ -9730,13 +9730,13 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms</screen>
&man.ppp.8;
man page and the <ulink
URL="../handbook/ppp-and-slip.html#USERPPP">
ppp section of the handbook</ulink>. Enable logging with
PPP section of the handbook</ulink>. Enable logging with
the command</para>
<programlisting>set log Phase Chat Connect Carrier lcp ipcp ccp command</programlisting>
<para>This command may be typed at the
<application>ppp</application> command prompt or it may be
&man.ppp.8; command prompt or it may be
entered in the <filename>/etc/ppp/ppp.conf</filename>
configuration file (the start of the
<literal>default</literal> section is the best
@ -9752,7 +9752,7 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms</screen>
If you need to get help from someone, it may make sense to
them.</para>
<para>If your version of ppp does not understand the
<para>If your version of &man.ppp.8; does not understand the
<command>set log</command> command, you should download the
<ulink URL="http://people.FreeBSD.org/~brian/">
latest version</ulink>. It will build on FreeBSD version
@ -9805,7 +9805,7 @@ default 10.0.0.2 UGSc 0 0 tun0
running an old version of &man.ppp.8;
that does not understand the word <literal>HISADDR</literal>
in the ppp.conf file. If your version of
<application>ppp</application> is from before FreeBSD
&man.ppp.8; is from before FreeBSD
2.2.5, change the</para>
<programlisting>add 0 0 HISADDR</programlisting>
@ -9867,7 +9867,7 @@ add 0 0 HISADDR</programlisting>
</question>
<answer>
<para>The default ppp timeout is 3 minutes. This can be
<para>The default PPP timeout is 3 minutes. This can be
adjusted with the line</para>
<programlisting>set timeout <replaceable>NNN</replaceable></programlisting>
@ -9946,8 +9946,8 @@ add 0 0 HISADDR</programlisting>
does not flash, the problem is local. With an internal modem,
you will need to use the <literal>set server</literal> command in
your <filename>ppp.conf</filename> file. When the hang occurs,
connect to ppp using pppctl. If your network connection
suddenly revives (ppp was revived due to the activity on the
connect to &man.ppp.8; using &man.pppctl.8;. If your network connection
suddenly revives (PPP was revived due to the activity on the
diagnostic socket) or if you cannot connect (assuming the
<literal>set socket</literal> command succeeded at startup
time), the problem is local. If you can connect and things are
@ -9972,10 +9972,10 @@ add 0 0 HISADDR</programlisting>
<para>There is very little you can do about this. Most ISPs
will refuse to help if you are not running a Microsoft OS.
You can <literal>enable lqr</literal> in your
<filename>ppp.conf</filename> file, allowing ppp to detect
<filename>ppp.conf</filename> file, allowing &man.ppp.8; to detect
the remote failure and hang up, but this detection is
relatively slow and therefore not that useful. You may want to
avoid telling your ISP that you are running user-ppp....</para>
avoid telling your ISP that you are running user-PPP...</para>
<para>First, try disabling all local compression by adding the
following to your configuration:</para>
@ -10011,11 +10011,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
</question>
<answer>
<para>Your best bet here is to rebuild ppp by adding
<para>Your best bet here is to rebuild &man.ppp.8; by adding
<literal>CFLAGS+=-g</literal> and <literal>STRIP=</literal>
to the end of the Makefile, then doing a
<command>make clean &amp;&amp; make &amp;&amp; make
install</command>. When ppp hangs, find the ppp process id
install</command>. When &man.ppp.8; hangs, find the &man.ppp.8; process id
with <command>ps ajxww | fgrep ppp</command> and run
<command>gdb ppp <replaceable>PID</replaceable></command>.
From the gdb prompt, you can then use <command>bt</command>
@ -10037,7 +10037,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
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
<application>ppp</application> to initiate the LCP, use the
&man.ppp.8; to initiate the LCP, use the
following line:</para>
<programlisting>set openmode active</programlisting>
@ -10061,20 +10061,20 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<para>Occasionally, just after connecting, you may see messages
in the log that say <quote>magic is the same</quote>.
Sometimes, these messages are harmless, and sometimes one side
or the other exits. Most ppp implementations cannot survive
or the other exits. Most PPP implementations cannot survive
this problem, and even if the link seems to come up, you will see
repeated configure requests and configure acknowledgments in
the log file until ppp eventually gives up and closes the
connection.</para>
the log file until &man.ppp.8; eventually gives up and closes the
connection.</para>
<para>This normally happens on server machines with slow disks
that are spawning a getty on the port, and executing ppp from
that are spawning a getty on the port, and executing &man.ppp.8; from
a login script or program after login. I have 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)
that in the time taken between &man.getty.8; exiting and &man.ppp.8; starting,
the client-side &man.ppp.8; 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
the server, the client &man.ppp.8; sees these packets
<quote>reflect</quote> back.</para>
<para>One part of the LCP negotiation is to establish a magic
@ -10083,12 +10083,12 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
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
client &man.ppp.8; 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
(which also means &man.ppp.8; must change its magic). This produces a
potentially enormous number of magic number changes, all of
which are happily piling into the server's tty buffer. As soon
as ppp starts on the server, it is flooded with magic number
as &man.ppp.8; starts on the server, it is flooded with magic number
changes and almost immediately decides it has tried enough to
negotiate LCP and gives up. Meanwhile, the client, who no
longer sees the reflections, becomes happy just in time to see
@ -10100,17 +10100,17 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<programlisting>set openmode passive</programlisting>
<para>This tells ppp to wait for the server to initiate LCP
<para>This tells &man.ppp.8; 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:</para>
<programlisting>set openmode active 3</programlisting>
<para>This tells ppp to be passive for 3 seconds, and then to
<para>This tells &man.ppp.8; 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.</para>
requests during this period, &man.ppp.8; will immediately respond
rather than waiting for the full 3 second period.</para>
</answer>
</qandaentry>
@ -10122,9 +10122,9 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<answer>
<para>There is currently an implementation mis-feature in
<application>ppp</application> where it does not associate
&man.ppp.8; where it does not associate
LCP, CCP &amp; IPCP responses with their original requests. As
a result, if one <application>ppp</application>
a result, if one 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.</para>
@ -10179,7 +10179,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<programlisting>set stopped N</programlisting>
<para>command to limit the amount of time that
<application>ppp</application> waits for the peer to begin
&man.ppp.8; waits for the peer to begin
negotiations. Alternatively, the</para>
<programlisting>set openmode active N</programlisting>
@ -10198,11 +10198,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<answer>
<para>Prior to version 2.2.5 of FreeBSD, it was possible that
your link was disabled shortly after connection due to
<application>ppp</application> mis-handling Predictor1
&man.ppp.8; 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 are still
running an old version of <application>ppp</application>,
running an old version of &man.ppp.8;
the problem can be circumvented with the line</para>
<programlisting>disable pred1</programlisting>
@ -10216,18 +10216,18 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<answer>
<para>When you execute the <command>shell</command> or
<command>!</command> command, <application>ppp</application> executes a
<command>!</command> command, &man.ppp.8; executes a
shell (or if you have passed any arguments,
<application>ppp</application> will execute those arguments). Ppp will
&man.ppp.8; will execute those arguments). Ppp will
wait for the command to complete before continuing. If you
attempt to use the ppp link while running the command, the link
attempt to use the PPP link while running the command, the link
will appear to have frozen. This is because
<application>ppp</application> is waiting for the command to
&man.ppp.8; is waiting for the command to
complete.</para>
<para>If you wish to execute commands like this, use the
<command>!bg</command> command instead. This will execute
the given command in the background, and ppp can continue to
the given command in the background, and &man.ppp.8; can continue to
service the link.</para>
</answer>
</qandaentry>
@ -10238,7 +10238,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
</question>
<answer>
<para>There is no way for <application>ppp</application> to
<para>There is no way for &man.ppp.8; 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,
@ -10255,7 +10255,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<para>Why does &man.ppp.8; dial for no reason in -auto mode?</para>
</question><answer>
<para>If <application>ppp</application> is dialing
<para>If &man.ppp.8; is dialing
unexpectedly, you must determine the cause, and set up Dial
filters (dfilters) to prevent such dialing.</para>
@ -10271,7 +10271,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
Usually, this sort of problem arises due to DNS lookups. To
prevent DNS lookups from establishing a connection (this will
<emphasis>not</emphasis> prevent
<application>ppp</application> from passing the packets
&man.ppp.8; from passing the packets
through an established connection), use the following:</para>
<programlisting>set dfilter 1 deny udp src eq 53
@ -10313,7 +10313,7 @@ set dfilter 3 permit 0/0 0/0</programlisting>
<programlisting>CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
<para>This is because ppp is trying to negotiate Predictor1
<para>This is because &man.ppp.8; is trying to negotiate Predictor1
compression, and the peer does not want to negotiate any
compression at all. The messages are harmless, but if you
wish to remove them, you can disable Predictor1 compression
@ -10336,7 +10336,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
greater than the MTU size results in an IO error being logged
via syslogd.</para>
<para>The ppp specification says that an MRU of 1500 should
<para>The PPP specification says that an MRU of 1500 should
<emphasis>always</emphasis> be accepted as a minimum,
despite any LCP negotiations, therefore it is possible that
should you decrease the MTU to less than 1500, your ISP will
@ -10369,14 +10369,14 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
or CHAP (and therefore do not have anything to
<quote>chat</quote> after the CONNECT in the dial script - no
<literal>set login</literal> script), you must make sure that
you instruct ppp to <quote>expect</quote> the whole CONNECT
you instruct &man.ppp.8; to <quote>expect</quote> the whole CONNECT
line, something like this:</para>
<programlisting>set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
\"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"</programlisting>
<para>Here, we get our CONNECT, send nothing, then expect a
line-feed, forcing <application>ppp</application> to read
line-feed, forcing &man.ppp.8; to read
the whole CONNECT response.</para>
</answer>
@ -10438,9 +10438,9 @@ ATDT1234567</programlisting>
<answer>
<para>Ppp (or any other program for that matter) should never
dump core. Because ppp runs with an effective user id of 0,
the operating system will not write ppp's core image to disk
before terminating it. If, however ppp
dump core. Because &man.ppp.8; runs with an effective user id of 0,
the operating system will not write &man.ppp.8;'s core image to disk
before terminating it. If, however &man.ppp.8;
is actually terminating due to a
segmentation violation or some other signal that normally
causes core to be dumped, <emphasis>and</emphasis>
@ -10456,12 +10456,12 @@ ATDT1234567</programlisting>
&prompt.root; <userinput>make install</userinput>
&prompt.root; <userinput>chmod 555 /usr/sbin/ppp</userinput></screen>
<para>You will now have a debuggable version of ppp installed.
You will have to be <username>root</username> to run ppp as all of its privileges
have been revoked. When you start ppp, take a careful note
<para>You will now have a debuggable version of &man.ppp.8; installed.
You will have to be <username>root</username> to run &man.ppp.8; as all of its privileges
have been revoked. When you start &man.ppp.8;, take a careful note
of what your current directory was at the time.</para>
<para>Now, if and when ppp receives the segmentation violation,
<para>Now, if and when &man.ppp.8; receives the segmentation violation,
it will dump a core file called <filename>ppp.core</filename>. You should then do
the following:</para>
@ -10493,7 +10493,7 @@ ATDT1234567</programlisting>
<answer>
<para>This was a known problem with
<application>ppp</application> set up to negotiate a
&man.ppp.8; set up to negotiate a
dynamic local IP number with the peer in auto mode. It is
fixed in the latest version - search the man page for
<literal>iface</literal>.</para>
@ -10502,9 +10502,9 @@ ATDT1234567</programlisting>
&man.connect.2;, the IP number of the tun interface is assigned
to the socket endpoint. The kernel creates the first outgoing
packet and writes it to the tun device.
<application>ppp</application> then reads the packet and
&man.ppp.8; then reads the packet and
establishes a connection. If, as a result of
<application>ppp</application>'s dynamic IP assignment, the
&man.ppp.8;'s dynamic IP assignment, the
interface address is changed, the original socket endpoint will
be invalid. Any subsequent packets sent to the peer will
usually be dropped. Even if they are not, any responses will
@ -10514,7 +10514,7 @@ ATDT1234567</programlisting>
<para>There are several theoretical ways to approach this
problem. It would be nicest if the peer would re-assign the
same IP number if possible <literal>:-)</literal>
The current version of <application>ppp</application> does
The current version of &man.ppp.8; does
this, but most other implementations do not.</para>
<para>The easiest method from our side would be to never change
@ -10522,15 +10522,15 @@ ATDT1234567</programlisting>
packets so that the source IP number is changed from the
interface IP to the negotiated IP on the fly. This is
essentially what the <literal>iface-alias</literal> option in
the latest version of <application>ppp</application> is
the latest version of &man.ppp.8; is
doing (with the help of
&man.libalias.3; and ppp's <option>-nat</option> switch) -
&man.libalias.3; and &man.ppp.8;'s <option>-nat</option> switch) -
it is maintaining all previous interface addresses and NATing
them to the last negotiated address.</para>
<para>Another alternative (and probably the most reliable) would
be to implement a system call that changes all bound sockets
from one IP to another. <application>ppp</application> would
from one IP to another. &man.ppp.8; would
use this call to modify the sockets of all existing programs
when a new IP number is negotiated. The same system call could
be used by dhcp clients when they are forced to re-bind() their
@ -10540,7 +10540,7 @@ ATDT1234567</programlisting>
brought up without an IP number. Outgoing packets would be
given an IP number of 255.255.255.255 up until the first
SIOCAIFADDR ioctl is done. This would result in fully binding
the socket. It would be up to <application>ppp</application>
the socket. It would be up to &man.ppp.8;
to change the source IP number, but only if it is set to
255.255.255.255, and only the IP number and IP checksum would
need to change. This, however is a bit of a hack as the kernel
@ -10565,7 +10565,7 @@ ATDT1234567</programlisting>
<para>To make things work, make sure that the only thing
running is the software that you are having problems with, then
either run tcpdump on the tun interface of the gateway or
enable ppp tcp/ip logging (<literal>set log +tcp/ip</literal>)
enable &man.ppp.8; tcp/ip logging (<literal>set log +tcp/ip</literal>)
on the gateway.</para>
<para>When you start the offending software, you should see
@ -10723,7 +10723,7 @@ ATDT1234567</programlisting>
<answer>
<para>FCS stands for <literal>F</literal>rame
<literal>C</literal>heck
<literal>S</literal>equence. Each ppp packet
<literal>S</literal>equence. Each PPP packet
has a checksum attached to ensure that the data being
received is the data being sent. If the FCS of an incoming
packet is incorrect, the packet is dropped and the HDLC FCS
@ -10743,7 +10743,7 @@ ATDT1234567</programlisting>
flow control (XON/XOFF). If your datalink
<emphasis>must</emphasis> use software flow control, use the
command <literal>set accmap 0x000a0000</literal> to tell
<application>ppp</application> to escape the <literal>^Q</literal> and
&man.ppp.8; to escape the <literal>^Q</literal> and
<literal>^S</literal> characters.</para>
<para>Another reason for seeing too many FCS errors may be that
@ -10751,7 +10751,7 @@ ATDT1234567</programlisting>
may want to enable <literal>async</literal> logging at this
point to determine if the incoming data is actually a login or
shell prompt. If you have a shell prompt at the remote end,
it is possible to terminate ppp without dropping the line by
it is possible to terminate &man.ppp.8; without dropping the line by
using the <literal>close lcp</literal> command (a following
<literal>term</literal> command will reconnect you to the shell
on the remote machine.</para>
@ -10828,11 +10828,11 @@ ATDT1234567</programlisting>
<literal>Save as Auto Configure</literal>, and click
<literal>Make Active</literal>.</para>
<para>The latest version of <application>ppp</application>
<para>The latest version of &man.ppp.8;
(2.3 or greater) has an <command>enable tcpmssfixup</command>
command that will automatically adjust the MSS to an appropriate
value. This facility is enabled by default. If you are stuck
with an older version of <application>ppp</application>, you
with an older version of &man.ppp.8;, you
may want to look at the <application>tcpmssd</application>
port.</para>
</answer>
@ -10846,7 +10846,7 @@ ATDT1234567</programlisting>
<answer>
<para>If all else fails, send as much information as you can,
including your config files, how you are starting
<application>ppp</application>, the relevant parts of your
&man.ppp.8;, the relevant parts of your
log file and the output of the <command>netstat -rn</command>
command (before and after connecting) to the &a.questions; or
the <ulink URL="news:comp.unix.bsd.freebsd.misc">