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:
parent
cad9394eb5
commit
615bcc2056
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44834
1 changed files with 48 additions and 185 deletions
|
@ -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 µsoft;
|
||||
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 — 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
|
||||
— 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>"</literal> character, you must escape it
|
||||
one argument. To specify a
|
||||
<literal>"</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 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= >> /etc/make.conf</userinput>
|
||||
&prompt.root; <userinput>echo CFLAGS+=-g >> /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 — 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) — 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
|
||||
|
|
Loading…
Reference in a new issue