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

Say a few words about ppp.

Browse source
This commit is contained in:
Brian Somers 1997-09-21 12:35:36 +00:00
parent 98397d4e27
commit e6cbeb4ebb
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=1977
1 changed files with 266 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

293
FAQ/FAQ.sgml
View file

@ -1,12 +1,12 @@
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
<!-- $Id: FAQ.sgml,v 1.72 1997-09-10 11:50:51 pds Exp $ -->
<!-- $Id: FAQ.sgml,v 1.73 1997-09-21 12:35:36 brian Exp $ -->
<article>
<title>Frequently Asked Questions for FreeBSD 2.X
<author>Maintainer: Peter da Silva <tt><htmlurl url='mailto:peter@taronga.com'
name='&lt;peter@taronga.com&gt;'></tt>
<date>$Date: 1997-09-10 11:50:51 $</date>
<date>$Date: 1997-09-21 12:35:36 $</date>
<abstract>
This is the FAQ for FreeBSD systems version 2.X All entries are
@ -3160,43 +3160,282 @@ vnconfig -ce /dev/vn0c /usr/swap0 swap
<heading>Does FreeBSD support SLIP and PPP?</heading>
<p>
Yes. See the man pages for <tt/slattach(8)/ and/or <tt/pppd(8)/
if you're using FreeBSD to connect to another site. If you're
using FreeBSD as a server for other machines, look at the man
page for <tt/sliplogin(8)/.
Yes. See the man pages for <tt/slattach(8)/, <tt/sliplogin(8)/,
<tt/pppd(8)/ and <tt/ppp(8)/. <tt/pppd/ and <tt/ppp/ provide
support for both incoming and outgoing connections.
<tt/Sliplogin/ deals exclusively with incoming connections and
<tt/slattach/ deals exclusively with outgoing connections.
You can also have a look at the SLIP/PPP/Use PPP sections of the
handbook in <tt>/usr/share/doc/handbook</tt> or use the following
links:
These programs are described in the following sections of the
<url url="../handbook/handbook.html" name="handbook">:
<url url="../handbook/slips.html"
<p><url url="../handbook/slips.html"
name="Handbook entry on SLIP (server side)">
<url url="../handbook/slipc.html"
<p><url url="../handbook/slipc.html"
name="Handbook entry on SLIP (client side)">
<url url="../handbook/ppp.html"
<p><url url="../handbook/ppp.html"
name="Handbook entry on PPP (kernel version)">
<url url="../handbook/userppp.html"
<p><url url="../handbook/userppp.html"
name="Handbook entry on PPP (user-mode version)">
All these of course require that you can create a subnet for
your new network interfaces.
If you can't get the IP address assigned, try the <tt/slirp/
package.
<p>
If you only have access to the Internet through a "shell
account", you may want to have a look at the <tt/slirp/
package. It can provide you with (limited) access to services
such as ftp and http direct from your local machine.
<sect1>
<heading>I can connect with IJPPP but it doesn't work right!</heading>
<heading>Does FreeBSD support NAT or Masquerading</heading>
<p>
A possible cause for this is IJPPPs' use of predictor1
compression. One way of determining if you have this problem
is to look at your log and if you have protocol errors then this is
most likely it.
These can be shut off with:
<p>
If you have a subnet (one or more local machines), but have
been allocated only a single IP number from your Internet
provider, you may want to look at the <tt/natd(8)/ program.
<tt/Natd/ allows you to connect an entire subnet to the internet
using only a single IP number.
<p>
The <tt/ppp(8)/ program has similar functionality built in via
the <tt/-alias/ switch.
<sect1>
<heading>I can't make <tt/ppp/ work. What am I doing wrong ?</heading>
<p>
You should first read the <tt/ppp(8)/ manual page and
the <url url="../handbook/userppp.html"
name="ppp section of the handbook">. Enable logging
with the command
<verb>
deny pred1
disable pred1
set log Phase Chat Connect Carrier lcp ipcp ccp command
</verb>
Use these two before you dial out and it should work.
This command may be typed at the <tt/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
<tt>/etc/syslog.conf</tt> contains the lines
<verb>
!ppp
*.* /var/log/ppp.log
</verb>
and that the file <tt>/var/log/ppp.log</tt> exists. You can
now find out a lot about what's going on from the log file.
Don't worry if it doesn't all make sense. If you need to
get help from someone, it may make sense to them.
<sect2>
<heading>Ppp won't dial in -auto mode</heading>
<p>
First, check that you've got a default route. By
running <tt/netstat -rn/, you should see two entries
like this:
<verb>
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.2 UGSc 0 0 tun0
10.0.0.2 10.0.0.1 UH 0 0 tun0
</verb>
This is assuming that you've used the addresses from the
handbook, the man page or from the ppp.conf.sample file.
If you haven't got a default route, it may be because you're
running an old version of <tt/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
<verb>
add 0 0 HISADDR
</verb>
line to one saying
<verb>
add 0 0 10.0.0.2
</verb>
Another reason for the default route line being missing is that
you have mistakenly set up a default router in your
<tt>/etc/rc.conf</tt> file (this file was called
<tt>/etc/sysconfig</tt> prior to release 2.2.2), and you have
omitted the line saying
<verb>
delete ALL
</verb>
from <tt>ppp.conf</tt>. If this is the case, go back to the
<url url="../handbook/userppp:final.html"
name="Final system configuration"> section of the handbook.
<sect2>
<heading>What does "No route to host" mean</heading>
<p>
This error is usually due to a missing
<verb>
MYADDR:
delete ALL
add 0 0 HISADDR
</verb>
section in your <tt>/etc/ppp/ppp.linkup</tt> file. This is
only necessary if you have a dynamic IP address or don't
know the address of your gateway. If you're using
interactive mode, you can type the following after entering
<tt/packet mode/ (packet mode is indicated by the capitalized
<bf/PPP/ in the prompt):
<verb>
delete ALL
add 0 0 HISADDR
</verb>
Refer to the <url url="../handbook/userppp:dynamicIP.html"
name="PPP and Dynamic IP addresses"> section of the handbook
for further details.
<sect2>
<heading>My connection drops after about 3 minutes</heading>
<p>
The default ppp timeout is 3 minutes. This can be adjusted
with the line
<verb>
set timeout NNN
</verb>
where NNN is the number of seconds of inactivity before the
connection is closed. If NNN is zero, the connection is
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
<tt/telnet(1)/ or <tt/pppctl(8)/. Refer to the <tt/ppp(8)/
man page for further details.
<sect2>
<heading>My connection drops under heavy load</heading>
<p>
If you have Link Quality Reporting (LQR) configured, it is
possible that too many LQR packets are lost between your
machine and the peer. Ppp deduces that the line must therefore
be bad, and disconnects. Prior to FreeBSD version 2.2.5,
LQR was enabled by default. It is now disabled by default.
LQR can be disabled with the line
<verb>
disable lqr
</verb>
<sect2>
<heading>Nothing happens after the Login OK! message</heading>
<p>
Prior to FreeBSD version 2.2.5, once the link was established,
<tt/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
the LCP, use the following line:
<verb>
set openmode active
</verb>
<bf/Note/: It does no harm if both sides initiate negotiation,
so openmode is now active by default.
<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/
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
<verb>
disable pred1
</verb>
<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/
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
to complete.
<p>
If you wish to execute commands like this, use the
<tt/!bg/ command instead. This will execute the given command
in the background, and ppp can continue to service the link.
<sect2>
<heading>Ppp over a null-modem cable never exits</heading>
<p>
There is no way for <tt/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
the line
<verb>
enable lqr
</verb>
LQR is accepted by default if negotiated by the peer.
<sect2>
<heading>Why does ppp dial for no reason in -auto mode</heading>
<p>
If <tt/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:
<verb>
set log +tcp/ip
</verb>
This will log all traffic through the connection. The next
time the line comes up unexpectedly, you will see the reason
logged with a convenient timestamp next to it.
<p>
You can now disable dialing under these circumstances. Usually,
this sort of problem arrises 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
connection), use the following:
<verb>
set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0
</verb>
<sect2>
<heading>What do these CCP errors mean</heading>
<p>
I keep seeing the following errors in my log file:
<verb>
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
</verb>
This is because ppp 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
locally too:
<verb>
disable pred1
</verb>
<sect2>
<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/,
the relevent parts of your log file and the output of the
<tt/netstat -rn/ command (before and after connecting) to the
<url url="mailto:freebsd-questions@FreeBSD.org"
name="freebsd-questions@FreeBSD.org"> mailing list, and someone
should point you in the right direction.
<sect1>
<heading>I can't create a <tt>/dev/ed0</tt> device!</heading>