diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml index ed483ac2c3..3a3b73b4de 100644 --- a/en_US.ISO8859-1/books/faq/book.sgml +++ b/en_US.ISO8859-1/books/faq/book.sgml @@ -4578,7 +4578,7 @@ IO range check 0x00 activate 0x01 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. @@ -6939,7 +6939,7 @@ parse returns: $# uucp-dom $@ your.uucp.relay If you have got a dynamically assigned IP number and use a - dialup ppp 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 myISP.com, and that your user name is @@ -6951,7 +6951,7 @@ parse returns: $# uucp-dom $@ your.uucp.relayIn order to retrieve mail from your mailbox, you will need to install a retrieval agent. Fetchmail 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 /etc/ppp/ppp.linkup: @@ -8829,8 +8829,8 @@ Key F15 A A Menu Workplace Nop to access the Internet from the Windows95 box through the FreeBSD box. This is really just a special case of the previous question. ... and the answer is yes! In FreeBSD - 3.x, user-mode ppp contains a option. If - you run ppp with the , + 3.x, user-mode &man.ppp.8; contains a option. If + you run &man.ppp.8; with the , set gateway_enable to YES in /etc/rc.conf, and configure your Windows machine correctly, this should work @@ -8841,7 +8841,7 @@ Key F15 A A Menu Workplace Nop URL="../ppp-primer/index.html"> Pedantic PPP Primer by Steve Sims. - If you are using kernel-mode ppp, or have an Ethernet + 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 natd section of this FAQ. @@ -9730,13 +9730,13 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms &man.ppp.8; man page and the - ppp section of the handbook. Enable logging with + PPP section of the handbook. Enable logging with the command set log Phase Chat Connect Carrier lcp ipcp ccp command This command may be typed at the - ppp command prompt or it may be + &man.ppp.8; command prompt or it may be entered in the /etc/ppp/ppp.conf configuration file (the start of the default section is the best @@ -9752,7 +9752,7 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms If you need to get help from someone, it may make sense to them. - If your version of ppp does not understand the + If your version of &man.ppp.8; does not understand the set log command, you should download the latest version. 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 HISADDR in the ppp.conf file. If your version of - ppp is from before FreeBSD + &man.ppp.8; is from before FreeBSD 2.2.5, change the add 0 0 HISADDR @@ -9867,7 +9867,7 @@ add 0 0 HISADDR - The default ppp timeout is 3 minutes. This can be + The default PPP timeout is 3 minutes. This can be adjusted with the line set timeout NNN @@ -9946,8 +9946,8 @@ add 0 0 HISADDR does not flash, the problem is local. With an internal modem, you will need to use the set server command in your ppp.conf 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 set socket command succeeded at startup time), the problem is local. If you can connect and things are @@ -9972,10 +9972,10 @@ add 0 0 HISADDR 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 enable lqr in your - ppp.conf file, allowing ppp to detect + ppp.conf 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.... + avoid telling your ISP that you are running user-PPP... First, try disabling all local compression by adding the following to your configuration: @@ -10011,11 +10011,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj - Your best bet here is to rebuild ppp by adding + Your best bet here is to rebuild &man.ppp.8; by adding CFLAGS+=-g and STRIP= to the end of the Makefile, then doing a make clean && make && make - install. When ppp hangs, find the ppp process id + install. When &man.ppp.8; hangs, find the &man.ppp.8; process id with ps ajxww | fgrep ppp and run gdb ppp PID. From the gdb prompt, you can then use bt @@ -10037,7 +10037,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj 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 - ppp to initiate the LCP, use the + &man.ppp.8; to initiate the LCP, use the following line: set openmode active @@ -10061,20 +10061,20 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Occasionally, just after connecting, you may see messages in the log that say magic is the same. 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. + the log file until &man.ppp.8; eventually gives up and closes the + connection. 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 reflect back. One part of the LCP negotiation is to establish a magic @@ -10083,12 +10083,12 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj 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 set openmode passive - This tells ppp to wait for the server to initiate LCP + 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: set openmode active 3 - This tells ppp to be passive for 3 seconds, and then to + 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. + requests during this period, &man.ppp.8; will immediately respond + rather than waiting for the full 3 second period. @@ -10122,9 +10122,9 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj There is currently an implementation mis-feature in - ppp where it does not associate + &man.ppp.8; where it does not associate LCP, CCP & IPCP responses with their original requests. As - a result, if one ppp + 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. @@ -10179,7 +10179,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj set stopped N command to limit the amount of time that - ppp waits for the peer to begin + &man.ppp.8; waits for the peer to begin negotiations. Alternatively, the set openmode active N @@ -10198,11 +10198,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Prior to version 2.2.5 of FreeBSD, it was possible that your link was disabled shortly after connection due to - ppp 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 ppp, + running an old version of &man.ppp.8; the problem can be circumvented with the line disable pred1 @@ -10216,18 +10216,18 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj When you execute the shell or - ! command, ppp executes a + ! command, &man.ppp.8; executes a shell (or if you have passed any arguments, - ppp 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 - ppp is waiting for the command to + &man.ppp.8; is waiting for the command to complete. If you wish to execute commands like this, use the !bg 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. @@ -10238,7 +10238,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj - There is no way for ppp to + 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 Why does &man.ppp.8; dial for no reason in -auto mode? - If ppp is dialing + If &man.ppp.8; is dialing unexpectedly, you must determine the cause, and set up Dial filters (dfilters) to prevent such dialing. @@ -10271,7 +10271,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Usually, this sort of problem arises due to DNS lookups. To prevent DNS lookups from establishing a connection (this will not prevent - ppp from passing the packets + &man.ppp.8; from passing the packets through an established connection), use the following: set dfilter 1 deny udp src eq 53 @@ -10313,7 +10313,7 @@ set dfilter 3 permit 0/0 0/0 CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) - This is because ppp is trying to negotiate Predictor1 + 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) greater than the MTU size results in an IO error being logged via syslogd. - The ppp specification says that an MRU of 1500 should + The PPP specification says that an MRU of 1500 should always 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) or CHAP (and therefore do not have anything to chat after the CONNECT in the dial script - no set login script), you must make sure that - you instruct ppp to expect the whole CONNECT + you instruct &man.ppp.8; to expect the whole CONNECT line, something like this: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Here, we get our CONNECT, send nothing, then expect a - line-feed, forcing ppp to read + line-feed, forcing &man.ppp.8; to read the whole CONNECT response. @@ -10438,9 +10438,9 @@ ATDT1234567 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, and @@ -10456,12 +10456,12 @@ ATDT1234567 &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp - You will now have a debuggable version of ppp installed. - You will have to be root to run ppp as all of its privileges - have been revoked. When you start ppp, take a careful note + You will now have a debuggable version of &man.ppp.8; installed. + You will have to be root 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. - Now, if and when ppp receives the segmentation violation, + Now, if and when &man.ppp.8; receives the segmentation violation, it will dump a core file called ppp.core. You should then do the following: @@ -10493,7 +10493,7 @@ ATDT1234567 This was a known problem with - ppp 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 iface. @@ -10502,9 +10502,9 @@ ATDT1234567 &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. - ppp then reads the packet and + &man.ppp.8; then reads the packet and establishes a connection. If, as a result of - ppp'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 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 :-) - The current version of ppp does + The current version of &man.ppp.8; does this, but most other implementations do not. The easiest method from our side would be to never change @@ -10522,15 +10522,15 @@ ATDT1234567 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 iface-alias option in - the latest version of ppp is + the latest version of &man.ppp.8; is doing (with the help of - &man.libalias.3; and ppp's switch) - + &man.libalias.3; and &man.ppp.8;'s switch) - it is maintaining all previous interface addresses and NATing them to the last negotiated address. Another alternative (and probably the most reliable) would be to implement a system call that changes all bound sockets - from one IP to another. ppp 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 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 ppp + 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 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 (set log +tcp/ip) + enable &man.ppp.8; tcp/ip logging (set log +tcp/ip) on the gateway. When you start the offending software, you should see @@ -10723,7 +10723,7 @@ ATDT1234567 FCS stands for Frame Check - Sequence. Each ppp packet + Sequence. 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 flow control (XON/XOFF). If your datalink must use software flow control, use the command set accmap 0x000a0000 to tell - ppp to escape the ^Q and + &man.ppp.8; to escape the ^Q and ^S characters. Another reason for seeing too many FCS errors may be that @@ -10751,7 +10751,7 @@ ATDT1234567 may want to enable async 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 close lcp command (a following term command will reconnect you to the shell on the remote machine. @@ -10828,11 +10828,11 @@ ATDT1234567 Save as Auto Configure, and click Make Active. - The latest version of ppp + The latest version of &man.ppp.8; (2.3 or greater) has an enable tcpmssfixup 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 ppp, you + with an older version of &man.ppp.8;, you may want to look at the tcpmssd port. @@ -10846,7 +10846,7 @@ ATDT1234567 If all else fails, send as much information as you can, including your config files, how you are starting - ppp, the relevant parts of your + &man.ppp.8;, the relevant parts of your log file and the output of the netstat -rn command (before and after connecting) to the &a.questions; or the