From owner-svn-doc-head@FreeBSD.ORG Wed May 14 21:23:57 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50770B3D; Wed, 14 May 2014 21:23:57 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C6A82BE1; Wed, 14 May 2014 21:23:57 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s4ELNv9S063883; Wed, 14 May 2014 21:23:57 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s4ELNvni063882; Wed, 14 May 2014 21:23:57 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201405142123.s4ELNvni063882@svn.freebsd.org> From: Dru Lavigne Date: Wed, 14 May 2014 21:23:57 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44834 - head/en_US.ISO8859-1/books/faq X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:23:57 -0000 Author: dru Date: Wed May 14 21:23:56 2014 New Revision: 44834 URL: http://svnweb.freebsd.org/changeset/doc/44834 Log: Fix some use of "you". As per discussion at BSDCan, remove section on how to debug a version of PPP that dumps core. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Wed May 14 20:33:46 2014 (r44833) +++ head/en_US.ISO8859-1/books/faq/book.xml Wed May 14 21:23:56 2014 (r44834) @@ -4798,9 +4798,9 @@ ttyvb "/usr/libexec/getty Pc" Use CtrlAltFn - to switch back to a virtual console. CtrlAltF1 - would return you to the first virtual console. + to return to the first virtual console. Once at a text console, use If the alias is on the same subnet as an address - already configured on the interface, then add - netmask 0xffffffff to your - &man.ifconfig.8; command-line, as in the following: + already configured on the interface, add + netmask 0xffffffff to this command: - &prompt.root; ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff + &prompt.root; ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff - Otherwise, just specify the network address and + Otherwise, specify the network address and netmask as usual: - &prompt.root; ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 + &prompt.root; ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 More information can be found in the &os; Handbook. @@ -5928,7 +5927,7 @@ add 0 0 HISADDR If Link Quality Reporting (LQR) is configured, it is possible that too many LQR packets are lost between - your machine and the peer. &man.ppp.8; deduces that the + the &os; system and the peer. &man.ppp.8; deduces that the line must therefore be bad, and disconnects. LQR is disabled by default and can be enabled with the following line: @@ -6013,9 +6012,9 @@ add 0 0 HISADDR There is very little that can be done about this. Many ISPs will refuse to help users not running a µsoft; - OS. You can enable lqr in + OS. Add enable lqr to /etc/ppp/ppp.conf, allowing &man.ppp.8; to - detect the remote failure and hang up, but this detection + detect the remote failure and hang up. This detection is relatively slow and therefore not that useful. First, try disabling all local compression by adding @@ -6134,7 +6133,7 @@ deny pred1 deflate deflate24 protocomp a 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 + initiate negotiations. In this case, try something like: set openmode active 3 @@ -6207,8 +6206,8 @@ deny pred1 deflate deflate24 protocomp a set openmode passive - Care should be taken with this option. You should - also use this command to limit the amount of time that + Care should be taken with this option. + This command can also be used to limit the amount of time that &man.ppp.8; waits for the peer to begin negotiations: @@ -6231,14 +6230,13 @@ deny pred1 deflate deflate24 protocomp a - When you execute the shell or - ! command, &man.ppp.8; executes a shell - (or if you have passed any arguments, &man.ppp.8; will - execute those arguments). The + When using shell or + !, &man.ppp.8; executes a shell + or the passed arguments. The ppp program 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 &man.ppp.8; is + command to complete before continuing. Any attempt to + use the PPP link while running the command will appear as + a frozen link. This is because &man.ppp.8; is waiting for the command to complete. To execute commands like this, use @@ -6275,8 +6273,8 @@ deny pred1 deflate deflate24 protocomp a - If &man.ppp.8; is dialing unexpectedly, you must - determine the cause, and set up Dial filters (dfilters) to + If &man.ppp.8; is dialing unexpectedly, + determine the cause, and set up dial filters to prevent such dialing. To determine the cause, use the following line: @@ -6284,11 +6282,11 @@ deny pred1 deflate deflate24 protocomp a set log +tcp/ip 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 + next time the line comes up unexpectedly, the + reason will be logged with a convenient timestamp next to it. - You can now disable dialing under these circumstances. + Next, 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 not prevent &man.ppp.8; @@ -6300,31 +6298,29 @@ set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 This is not always suitable, as it will effectively - break your demand-dial capabilities — most programs + break demand-dial capabilities. Most programs will need a DNS lookup before doing any other network related things. - In the DNS case, you should try to determine what is + In the DNS case, try to determine what is actually trying to resolve a host name. A lot of the - time, &man.sendmail.8; is the culprit. You should make - sure that you tell sendmail not + time, &man.sendmail.8; is the culprit. Make + sure to configure sendmail not to do any DNS lookups in its configuration file. See the section on using email with a dialup connection in the &os; - Handbook for details on how to create your own - configuration file and what should go into it. You may + Handbook for details. You may also want to add the following line to .mc: define(`confDELIVERY_MODE', `d')dnl This will make sendmail - queue everything until the queue is run (usually, sendmail - is run with , telling it to run - the queue every 30 minutes) or until a sendmail - -q is done (perhaps from your - ppp.linkup). + queue everything until the queue is run, usually, + every 30 minutes, or until a sendmail + -q is done, perhaps from + /etc/ppp/ppp.linkup. @@ -6343,8 +6339,7 @@ CCP: Received Terminate Ack (1) state = 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 locally too: + harmless, but can be disabled with: disable pred1 @@ -6357,8 +6352,8 @@ CCP: Received Terminate Ack (1) state = - To log all lines of your modem - conversation, you must enable the + To log all lines of the modem + conversation, enable the following: set log +connect @@ -6366,18 +6361,16 @@ CCP: Received Terminate Ack (1) state = This will make &man.ppp.8; log everything up until the last requested expect string. - If you wish to see your connect speed and are using - PAP 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 &man.ppp.8; to - expect the whole CONNECT line, something + To seether connect speed when using + PAP or CHAP, + make sure to configure &man.ppp.8; to + expect the whole CONNECT line, using 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 + This gets the CONNECT, sends nothing, then expects a line-feed, forcing &man.ppp.8; to read the whole CONNECT response. @@ -6391,22 +6384,22 @@ CCP: Received Terminate Ack (1) state = The ppp utility parses each - line in your config files so that it can interpret strings + line in its configuration files so that it can interpret strings such as set phone "123 456 789" correctly and realize that the number is actually only - one argument. To specify a - " character, you must escape it + one argument. To specify a + " character, escape it using a backslash (\). When the chat interpreter parses each argument, it re-interprets the argument to find any special escape sequences such as \P or - \T (see the manual page). As a result - of this double-parsing, you must remember to use the + \T. As a result + of this double-parsing, remember to use the correct number of escapes. - If you wish to actually send a \ - character to (say) your modem, you would need something + To actually send a \ + character, do something like: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" @@ -6432,136 +6425,6 @@ ATDT1234567 - - Why does &man.ppp.8; get a Segmentation - fault, but I see no - ppp.core - - - - The ppp utility (or any - other program for that matter) should never dump core. - Because &man.ppp.8; runs setuid (with an effective - user ID of 0), the operating - system will not write core image of &man.ppp.8; 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 you are sure you are using the - latest version (see the start of this section), then you - should install the system sources and do the - following: - - &prompt.root; cd /usr/src/usr.sbin/ppp -&prompt.root; echo STRIP= >> /etc/make.conf -&prompt.root; echo CFLAGS+=-g >> /etc/make.conf -&prompt.root; make install clean - - 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 &man.ppp.8; receives the segmentation - violation, it will dump a core file called - ppp.core. You should then do the - following: - - &prompt.user; su -&prompt.root; gdb /usr/sbin/ppp ppp.core -(gdb) bt -..... -(gdb) f 0 -.... -(gdb) i args -.... -(gdb) l -..... - - All of this information should be given alongside your - question, making it possible to diagnose the - problem. - - If you are familiar with &man.gdb.1;, you may wish to - find out some other bits and pieces such as what actually - caused the dump or the addresses and values of the - relevant variables. - - - - - - Why does the process that forces a dial in - mode never connect? - - - - This was a known problem with &man.ppp.8; set up to - negotiate a dynamic local IP number with the peer in - mode. It has been fixed a long - time ago — search the manual page for - iface. - - The problem was that when that initial program calls - &man.connect.2;, the IP number of the &man.tun.4; - interface is assigned to the socket endpoint. The kernel - creates the first outgoing packet and writes it to the - &man.tun.4; device. &man.ppp.8; then reads the packet and - establishes a connection. If, as a result of - &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 not - route back to the originating machine as the IP number is - no longer owned by that machine. - - 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 - &man.ppp.8; does this, but most other implementations do - not. - - The easiest method from our side would be to never - change the &man.tun.4; interface IP number, but instead to - change all outgoing 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 &man.ppp.8; is doing (with the help of - &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. &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 call the bind() - function for their sockets. - - Yet another possibility is to allow an interface to be - brought up without an IP number. Outgoing packets would - be given an IP number of 255.255.255.255 up until - the first SIOCAIFADDR &man.ioctl.2; is - done. This would result in fully binding 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 would be sending - bad packets to an improperly configured interface, on the - assumption that some other mechanism is capable of fixing - things retrospectively. - - - - Why do most games not work with the switch?