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
This commit is contained in:
Dru Lavigne 2014-05-14 21:23:56 +00:00
parent cad9394eb5
commit 615bcc2056
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44834

View file

@ -4798,9 +4798,9 @@ ttyvb "/usr/libexec/getty Pc" xterm on secure</programlisting>
<answer>
<para>Use <keycombo
action="simul"><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>F<replaceable>n</replaceable></keycap></keycombo>
to switch back to a virtual console. <keycombo
to switch back to a virtual console. Press <keycombo
action="simul"><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>F1</keycap></keycombo>
would return you to the first virtual console.</para>
to return to the first virtual console.</para>
<para>Once at a text console, use
<keycombo
@ -5194,16 +5194,15 @@ Key F15 A A Menu Workplace Nop</programlisting>
<answer>
<para>If the alias is on the same subnet as an address
already configured on the interface, then add
<literal>netmask 0xffffffff</literal> to your
&man.ifconfig.8; command-line, as in the following:</para>
already configured on the interface, add
<literal>netmask 0xffffffff</literal> to this command:</para>
<screen>&prompt.root; <userinput>ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff</userinput></screen>
<screen>&prompt.root; <userinput>ifconfig <replaceable>ed0</replaceable> alias <replaceable>192.0.2.2 </replaceable>netmask 0xffffffff</userinput></screen>
<para>Otherwise, just specify the network address and
<para>Otherwise, specify the network address and
netmask as usual:</para>
<screen>&prompt.root; <userinput>ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00</userinput></screen>
<screen>&prompt.root; <userinput>ifconfig <replaceable>ed0</replaceable> alias <replaceable>172.16.141.5</replaceable> netmask 0xffffff00</userinput></screen>
<para>More information can be found in the &os; <link
xlink:href="&url.books.handbook;/configtuning-virtual-hosts.html">Handbook</link>.</para>
@ -5928,7 +5927,7 @@ add 0 0 HISADDR</programlisting>
<answer>
<para>If Link Quality Reporting (<acronym>LQR</acronym>) is configured,
it is possible that too many <acronym>LQR</acronym> 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. <acronym>LQR</acronym> is
disabled by default and can be enabled with the following
line:</para>
@ -6013,9 +6012,9 @@ add 0 0 HISADDR</programlisting>
<answer>
<para>There is very little that can be done about this. Many ISPs
will refuse to help users not running a &microsoft;
OS. You can <literal>enable lqr</literal> in
OS. Add <literal>enable lqr</literal> to
<filename>/etc/ppp/ppp.conf</filename>, 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.</para>
<para>First, try disabling all local compression by adding
@ -6134,7 +6133,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<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
initiate negotiations. In this case, try
something like:</para>
<programlisting>set openmode active 3</programlisting>
@ -6207,8 +6206,8 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<programlisting>set openmode passive</programlisting>
<para>Care should be taken with this option. You should
also use this command to limit the amount of time that
<para>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:</para>
@ -6231,14 +6230,13 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
</question>
<answer>
<para>When you execute the <command>shell</command> or
<command>!</command> command, &man.ppp.8; executes a shell
(or if you have passed any arguments, &man.ppp.8; will
execute those arguments). The
<para>When using <command>shell</command> or
<command>!</command>, &man.ppp.8; executes a shell
or the passed arguments. The
<application>ppp</application> 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.</para>
<para>To execute commands like this, use
@ -6275,8 +6273,8 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
</question>
<answer>
<para>If &man.ppp.8; is dialing unexpectedly, you must
determine the cause, and set up Dial filters (dfilters) to
<para>If &man.ppp.8; is dialing unexpectedly,
determine the cause, and set up dial filters to
prevent such dialing.</para>
<para>To determine the cause, use the following line:</para>
@ -6284,11 +6282,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
<programlisting>set log +tcp/ip</programlisting>
<para>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.</para>
<para>You can now disable dialing under these circumstances.
<para>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 <emphasis>not</emphasis> prevent &man.ppp.8;
@ -6300,31 +6298,29 @@ set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0</programlisting>
<para>This is not always suitable, as it will effectively
break your demand-dial capabilities &mdash; most programs
break demand-dial capabilities. Most programs
will need a DNS lookup before doing any other network
related things.</para>
<para>In the DNS case, you should try to determine what is
<para>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 <application>sendmail</application> not
time, &man.sendmail.8; is the culprit. Make
sure to configure <application>sendmail</application> not
to do any DNS lookups in its configuration file. See the
section on <link
xlink:href="&url.books.handbook;/smtp-dialup.html">using
email with a dialup connection</link> 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
<filename>.mc</filename>:</para>
<programlisting>define(`confDELIVERY_MODE', `d')dnl</programlisting>
<para>This will make <application>sendmail</application>
queue everything until the queue is run (usually, sendmail
is run with <option>-bd -q30m</option>, telling it to run
the queue every 30 minutes) or until a <command>sendmail
-q</command> is done (perhaps from your
<filename>ppp.linkup</filename>).</para>
queue everything until the queue is run, usually,
every 30 minutes, or until a <command>sendmail
-q</command> is done, perhaps from
<filename>/etc/ppp/ppp.linkup</filename>.</para>
</answer>
</qandaentry>
@ -6343,8 +6339,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
<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 locally too:</para>
harmless, but can be disabled with:</para>
<programlisting>disable pred1</programlisting>
</answer>
@ -6357,8 +6352,8 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
</question>
<answer>
<para>To log all lines of your modem
<quote>conversation</quote>, you must enable the
<para>To log all lines of the modem
conversation, enable the
following:</para>
<programlisting>set log +connect</programlisting>
@ -6366,18 +6361,16 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
<para>This will make &man.ppp.8; log everything up until the
last requested <quote>expect</quote> string.</para>
<para>If you wish to see your connect speed and are using
PAP or CHAP (and therefore do not have anything to
<quote>chat</quote> after the CONNECT in the dial script
&mdash; no <literal>set login</literal> script), you must
make sure that you instruct &man.ppp.8; to
<quote>expect</quote> the whole CONNECT line, something
<para>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:</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
<para>This gets the CONNECT, sends nothing, then expects a
line-feed, forcing &man.ppp.8; to read the whole CONNECT
response.</para>
</answer>
@ -6391,22 +6384,22 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
<answer>
<para>The <application>ppp</application> 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 <literal>set phone "123 456 789"</literal>
correctly and realize that the number is actually only
<emphasis>one</emphasis> argument. To specify a
<literal>&quot;</literal> character, you must escape it
one argument. To specify a
<literal>&quot;</literal> character, escape it
using a backslash (<literal>\</literal>).</para>
<para>When the chat interpreter parses each argument, it
re-interprets the argument to find any special escape
sequences such as <literal>\P</literal> or
<literal>\T</literal> (see the manual page). As a result
of this double-parsing, you must remember to use the
<literal>\T</literal>. As a result
of this double-parsing, remember to use the
correct number of escapes.</para>
<para>If you wish to actually send a <literal>\</literal>
character to (say) your modem, you would need something
<para>To actually send a <literal>\</literal>
character, do something
like:</para>
<programlisting>set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"</programlisting>
@ -6431,136 +6424,6 @@ ATDT1234567</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question xml:id="ppp-segfault-nocore">
<para>Why does &man.ppp.8; get a <errorname>Segmentation
fault</errorname>, but I see no
<filename>ppp.core</filename></para>
</question>
<answer>
<para>The <application>ppp</application> utility (or any
other program for that matter) should never dump core.
Because &man.ppp.8; runs setuid (with an effective
user&nbsp;ID of <literal>0</literal>), 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,
<emphasis>and</emphasis> 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:</para>
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/ppp</userinput>
&prompt.root; <userinput>echo STRIP= &gt;&gt; /etc/make.conf</userinput>
&prompt.root; <userinput>echo CFLAGS+=-g &gt;&gt; /etc/make.conf</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>
<para>You will now have a debuggable version of &man.ppp.8;
installed. You will have to be <systemitem
class="username">root</systemitem> 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 &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>
<screen>&prompt.user; <userinput>su</userinput>
&prompt.root; <userinput>gdb /usr/sbin/ppp ppp.core</userinput>
<prompt>(gdb)</prompt> <userinput>bt</userinput>
.....
<prompt>(gdb)</prompt> <userinput>f 0</userinput>
....
<prompt>(gdb)</prompt> <userinput>i args</userinput>
....
<prompt>(gdb)</prompt> <userinput>l</userinput>
.....</screen>
<para>All of this information should be given alongside your
question, making it possible to diagnose the
problem.</para>
<para>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.</para>
</answer>
</qandaentry>
<qandaentry>
<question xml:id="ppp-autodialprocess-noconnect">
<para>Why does the process that forces a dial in
<option>-auto</option> mode never connect?</para>
</question>
<answer>
<para>This was a known problem with &man.ppp.8; set up to
negotiate a dynamic local IP number with the peer in
<option>-auto</option> mode. It has been fixed a long
time ago &mdash; search the manual page for
<literal>iface</literal>.</para>
<para>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.</para>
<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. 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 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
<literal>iface-alias</literal> option in the latest
version of &man.ppp.8; is doing (with the help of
&man.libalias.3; and &man.ppp.8;'s <option>-nat</option>
switch) &mdash; 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. &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 <acronym>DHCP</acronym> clients when they
are forced to call the <function>bind()</function>
function for their sockets.</para>
<para>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 <systemitem
class="ipaddress">255.255.255.255</systemitem> up until
the first <literal>SIOCAIFADDR</literal> &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 <systemitem
class="ipaddress">255.255.255.255</systemitem>, 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.</para>
</answer>
</qandaentry>
<qandaentry>
<question xml:id="ppp-nat-games">
<para>Why do most games not work with the