diff options
Diffstat (limited to 'FAQ/FAQ.sgml')
| -rw-r--r-- | FAQ/FAQ.sgml | 293 |
1 files changed, 266 insertions, 27 deletions
diff --git a/FAQ/FAQ.sgml b/FAQ/FAQ.sgml index 8d2009303f..de347ab5e6 100644 --- a/FAQ/FAQ.sgml +++ b/FAQ/FAQ.sgml @@ -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='<peter@taronga.com>'></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> + set log Phase Chat Connect Carrier lcp ipcp ccp command +</verb> + 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> -deny pred1 -disable pred1 + disable pred1 </verb> - Use these two before you dial out and it should work. + + <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> |