Pick up the sledgehammer used by Nik for rev 1.114, Ben for rev 1.87, and
others -- and do some major SGML cleanup. Replace <emphasis remap=xx> by whatever is appropriate. Reviewed by: alex Inspired by: German FAQ translation, rev. 1.101
This commit is contained in:
Udo Erdelhoff
parent
285bbf2296
commit
76bd774fd3
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=9447
2 changed files with 244 additions and 220 deletions
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
<corpauthor>The FreeBSD Documentation Project</corpauthor>
|
||||
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.193 2001/05/14 22:57:35 dd Exp $</pubdate>
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.194 2001/05/15 00:24:18 dd Exp $</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1995</year>
|
||||
|
|
@ -3669,7 +3669,7 @@ quit</programlisting>
|
|||
<para>
|
||||
<note>
|
||||
<para>You can not use a
|
||||
<emphasis remap=bf>dangerously dedicated</emphasis> disk
|
||||
<literal>dangerously dedicated</literal> disk
|
||||
with an HP Netserver. See <link linkend="dedicate">this
|
||||
note</link> for more info.</para>
|
||||
</note></para>
|
||||
|
|
@ -3954,7 +3954,7 @@ quit</programlisting>
|
|||
<literal>2e8</literal>, and the fourth serial port does too.
|
||||
Due to a bug (feature?) in the &man.sio.4;
|
||||
driver it will touch this port even if you don't have the
|
||||
fourth serial port, and <emphasis remap=bf>even</emphasis> if
|
||||
fourth serial port, and <emphasis>even</emphasis> if
|
||||
you disable sio3 (the fourth port) which normally uses this
|
||||
address.</para>
|
||||
|
||||
|
|
@ -5237,7 +5237,7 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
|
|||
math co-processor, right? Wrong! :-) The
|
||||
<devicename>npx0</devicename> is
|
||||
<emphasis>MANDATORY</emphasis>. Even if you don't have a
|
||||
mathematic co-processor, you <emphasis remap=bf>must</emphasis>
|
||||
mathematic co-processor, you <emphasis>must</emphasis>
|
||||
include the <devicename>npx0</devicename> device.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
|
@ -5289,12 +5289,12 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para><emphasis remap=bf>Q.</emphasis> When I compile a kernel
|
||||
<para>When I compile a kernel
|
||||
with multi-port serial code, it tells me that only the first
|
||||
port is probed and the rest skipped due to interrupt conflicts.
|
||||
How do I fix this?</para>
|
||||
|
||||
<para><emphasis remap=bf>A.</emphasis> The problem here is that
|
||||
<para>The problem here is that
|
||||
FreeBSD has code built-in to keep the kernel from getting
|
||||
trashed due to hardware or software conflicts. The way to fix
|
||||
this is to leave out the IRQ settings on all but one port. Here
|
||||
|
|
@ -5650,18 +5650,18 @@ device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para><emphasis remap=bf> Digital UNIX</emphasis> UFS CDROMs can
|
||||
<para><literal>Digital UNIX</literal> UFS CDROMs can
|
||||
be mounted directly on FreeBSD. Mounting disk partitions from
|
||||
Digital UNIX and other systems that support UFS may be more
|
||||
complex, depending on the details of the disk partitioning for
|
||||
the operating system in question.</para>
|
||||
|
||||
<para><emphasis remap=bf> Linux</emphasis>: 2.2 and later have
|
||||
support for <emphasis remap=bf>ext2fs</emphasis> partitions.
|
||||
<para><literal>Linux</literal>: 2.2 and later have
|
||||
support for <literal>ext2fs</literal> partitions.
|
||||
See &man.mount.ext2fs.8;
|
||||
for more information.</para>
|
||||
|
||||
<para><emphasis remap=bf> NT</emphasis>: A read-only NTFS driver
|
||||
<para><literal>NT</literal>: A read-only NTFS driver
|
||||
exists for FreeBSD. For more information, see this tutorial by
|
||||
Mark Ovens at
|
||||
<ulink URL="http://ukug.uk.freebsd.org/~mark/ntfs_install.html">
|
||||
|
|
@ -5699,7 +5699,7 @@ C:\="DOS"</programlisting>
|
|||
|
||||
<para>For 2.2.x systems this procedure assumes that DOS, NT,
|
||||
FreeBSD, or whatever have been installed into their respective
|
||||
fdisk partitions on the <emphasis remap=bf>same</emphasis>
|
||||
fdisk partitions on the <emphasis>same</emphasis>
|
||||
disk. This example was tested on a system where DOS & NT
|
||||
were on the first fdisk partition, and FreeBSD on the second.
|
||||
FreeBSD was also set up to boot from its native partition, not
|
||||
|
|
@ -6503,7 +6503,7 @@ rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \
|
|||
the rest.</para>
|
||||
|
||||
<para>If you've got a dynamically assigned IP number and use a
|
||||
dialup <emphasis remap=bf>ppp</emphasis> connection to the
|
||||
dialup <application>ppp</application> connection to the
|
||||
internet, you will probably be given a mailbox on your ISPs
|
||||
mail server. Lets assume your ISPs domain is
|
||||
<hostid role="domainname">myISP.com</hostid>, and that your user name is
|
||||
|
|
@ -7365,7 +7365,7 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
|
|||
<filename>/dev/sysmouse</filename>. All mouse events received
|
||||
from the real mouse device are written to the sysmouse device
|
||||
via moused. If you wish to use your mouse on one or more
|
||||
virtual consoles, <emphasis remap=bf>and</emphasis> use X, see
|
||||
virtual consoles, <emphasis>and</emphasis> use X, see
|
||||
<xref linkend="moused" remap="another section"> and set up
|
||||
moused.</para>
|
||||
|
||||
|
|
@ -7844,7 +7844,7 @@ ttyvb "/usr/libexec/getty Pc" cons25 off secure</programlisting>
|
|||
URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=startx">
|
||||
startx</ulink>, the permissions on
|
||||
<filename>/dev/console</filename> will
|
||||
<emphasis remap=tt>not</emphasis> get changed, resulting in
|
||||
<emphasis>not</emphasis> get changed, resulting in
|
||||
things like <ulink
|
||||
URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xterm">
|
||||
xterm -C</ulink> and <ulink
|
||||
|
|
@ -8740,7 +8740,7 @@ Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
|
|||
|
||||
<listitem>
|
||||
<para>Place heavily triggered rules earlier in the rule
|
||||
set than those rarely used (<emphasis remap=bf>without
|
||||
set than those rarely used (<emphasis>without
|
||||
changing the permissiveness of the firewall</emphasis>,
|
||||
of course). You can see which rules are used most often
|
||||
by examining the packet counting statistics with
|
||||
|
|
@ -8970,10 +8970,10 @@ Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
|
|||
<programlisting>set log Phase Chat Connect Carrier lcp ipcp ccp command</programlisting>
|
||||
|
||||
<para>This command may be typed at the
|
||||
<emphasis remap=bf>ppp</emphasis> command prompt or it may be
|
||||
<application>ppp</application> command prompt or it may be
|
||||
entered in the <filename>/etc/ppp/ppp.conf</filename>
|
||||
configuration file (the start of the
|
||||
<emphasis remap=bf>default</emphasis> section is the best
|
||||
<literal>default</literal> section is the best
|
||||
place to put it). Make sure that
|
||||
<filename>/etc/syslog.conf</filename> (see &man.syslog.conf.5;) contains the lines</para>
|
||||
|
||||
|
|
@ -9038,7 +9038,7 @@ default 10.0.0.2 UGSc 0 0 tun0
|
|||
running an old version of &man.ppp.8;
|
||||
that doesn't understand the word <literal>HISADDR</literal>
|
||||
in the ppp.conf file. If your version of
|
||||
<emphasis remap=bf>ppp</emphasis> is from before FreeBSD
|
||||
<application>ppp</application> is from before FreeBSD
|
||||
2.2.5, change the</para>
|
||||
|
||||
<programlisting>add 0 0 HISADDR</programlisting>
|
||||
|
|
@ -9080,7 +9080,7 @@ default 10.0.0.2 UGSc 0 0 tun0
|
|||
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
|
||||
<emphasis remap=tt>packet mode</emphasis> (packet mode is
|
||||
<literal>packet mode</literal> (packet mode is
|
||||
indicated by the capitalized <acronym>PPP</acronym> in the
|
||||
prompt):</para>
|
||||
|
||||
|
|
@ -9111,8 +9111,8 @@ add 0 0 HISADDR</programlisting>
|
|||
closed due to a timeout. It is possible to put this command in
|
||||
the <filename>ppp.conf</filename> 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 <emphasis
|
||||
remap=bf>ppp</emphasis>s server socket using
|
||||
the fly while the line is active by connecting to
|
||||
<application>ppp</application>s server socket using
|
||||
&man.telnet.1; or &man.pppctl.8;.
|
||||
Refer to the
|
||||
&man.ppp.8; man
|
||||
|
|
@ -9267,15 +9267,19 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
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
|
||||
<emphasis remap=bf>ppp</emphasis> to initiate the LCP, use the
|
||||
<application>ppp</application> to initiate the LCP, use the
|
||||
following line:</para>
|
||||
|
||||
<programlisting>set openmode active</programlisting>
|
||||
|
||||
<para><emphasis remap=bf>Note</emphasis>: It usually does no
|
||||
<para>
|
||||
<note>
|
||||
<para>It usually does no
|
||||
harm if both sides initiate negotiation, so openmode is now
|
||||
active by default. However, the next section explains when
|
||||
it <emphasis remap=bf>does</emphasis> do some harm.</para>
|
||||
it <emphasis>does</emphasis> do some harm.</para>
|
||||
</note>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -9349,44 +9353,44 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>There is currently an implementation mis-feature in
|
||||
<emphasis remap=bf>ppp</emphasis> where it doesn't associate
|
||||
<application>ppp</application> where it doesn't associate
|
||||
LCP, CCP & IPCP responses with their original requests. As
|
||||
a result, if one <emphasis remap=bf>ppp</emphasis>
|
||||
a result, if one <application>ppp</application>
|
||||
implementation is more than 6 seconds slower than the other
|
||||
side, the other side will send two additional LCP configuration
|
||||
requests. This is fatal.</para>
|
||||
|
||||
<para>Consider two implementations,
|
||||
<emphasis remap=bf>A</emphasis> and <emphasis
|
||||
remap=bf>B</emphasis>. <emphasis remap=bf>A</emphasis> starts
|
||||
sending LCP requests immediately after connecting and <emphasis
|
||||
remap=bf>B</emphasis> takes 7 seconds to start. When <emphasis
|
||||
remap=bf>B</emphasis> starts, <emphasis remap=bf>A</emphasis>
|
||||
<hostid>A</hostid> and
|
||||
<hostid>B</hostid>. <hostid>A</hostid> starts
|
||||
sending LCP requests immediately after connecting and
|
||||
<hostid>B</hostid> takes 7 seconds to start. When
|
||||
<hostid>B</hostid> starts, <hostid>A</hostid>
|
||||
has sent 3 LCP REQs. We're assuming the line has ECHO switched
|
||||
off, otherwise we'd see magic number problems as described in
|
||||
the previous section. <emphasis remap=bf>B</emphasis> sends a
|
||||
REQ, then an ACK to the first of <emphasis
|
||||
remap=bf>A</emphasis>'s REQs. This results in <emphasis
|
||||
remap=bf>A</emphasis> entering the <acronym>OPENED</acronym>
|
||||
state and sending and ACK (the first) back to <emphasis
|
||||
remap=bf>B</emphasis>. In the meantime, <emphasis
|
||||
remap=bf>B</emphasis> sends back two more ACKs in response to
|
||||
the two additional REQs sent by <emphasis remap=bf>A</emphasis>
|
||||
before <emphasis remap=bf>B</emphasis> started up. <emphasis
|
||||
remap=bf>B</emphasis> then receives the first ACK from
|
||||
<emphasis remap=bf>A</emphasis> and enters the
|
||||
<acronym>OPENED</acronym> state. <emphasis
|
||||
remap=bf>A</emphasis> receives the second ACK from <emphasis
|
||||
remap=bf>B</emphasis> and goes back to the <emphasis
|
||||
remap=bf>REQ-SENT</emphasis> state, sending another (forth) REQ
|
||||
the previous section. <hostid>B</hostid> sends a
|
||||
REQ, then an ACK to the first of
|
||||
<hostid>A</hostid>'s REQs. This results in
|
||||
<hostid>A</hostid> entering the <acronym>OPENED</acronym>
|
||||
state and sending and ACK (the first) back to
|
||||
<hostid>B</hostid>. In the meantime,
|
||||
<hostid>B</hostid> sends back two more ACKs in response to
|
||||
the two additional REQs sent by <hostid>A</hostid>
|
||||
before <hostid>B</hostid> started up.
|
||||
<hostid>B</hostid> then receives the first ACK from
|
||||
<hostid>A</hostid> and enters the
|
||||
<acronym>OPENED</acronym> state.
|
||||
<hostid>A</hostid> receives the second ACK from
|
||||
<hostid>B</hostid> and goes back to the
|
||||
<literal>REQ-SENT</literal> state, sending another (forth) REQ
|
||||
as per the RFC. It then receives the third ACK and enters the
|
||||
<acronym>OPENED</acronym> state. In the meantime, <emphasis
|
||||
remap=bf>B</emphasis> receives the forth REQ from <emphasis
|
||||
remap=bf>A</emphasis>, resulting in it reverting to the
|
||||
<emphasis remap=bf>ACK-SENT</emphasis> state and sending
|
||||
another (second) REQ and (forth) ACK as per the RFC. <emphasis
|
||||
remap=bf>A</emphasis> gets the REQ, goes into <emphasis
|
||||
remap=bf>REQ-SENT</emphasis> and sends another REQ. It
|
||||
<acronym>OPENED</acronym> state. In the meantime,
|
||||
<hostid>B</hostid> receives the forth REQ from
|
||||
<hostid>A</hostid>, resulting in it reverting to the
|
||||
<literal>ACK-SENT</literal> state and sending
|
||||
another (second) REQ and (forth) ACK as per the RFC.
|
||||
<hostid>A</hostid> gets the REQ, goes into
|
||||
<literal>REQ-SENT</literal> and sends another REQ. It
|
||||
immediately receives the following ACK and enters
|
||||
<acronym>OPENED</acronym>.</para>
|
||||
|
||||
|
|
@ -9394,7 +9398,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
getting nowhere and gives up.</para>
|
||||
|
||||
<para>The best way to avoid this is to configure one side to be
|
||||
<emphasis remap=bf>passive</emphasis> - that is, make one side
|
||||
<literal>passive</literal> - that is, make one side
|
||||
wait for the other to start negotiating. This can be done
|
||||
with the</para>
|
||||
|
||||
|
|
@ -9406,12 +9410,12 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<programlisting>set stopped N</programlisting>
|
||||
|
||||
<para>command to limit the amount of time that
|
||||
<emphasis remap=bf>ppp</emphasis> waits for the peer to begin
|
||||
<application>ppp</application> waits for the peer to begin
|
||||
negotiations. Alternatively, the</para>
|
||||
|
||||
<programlisting>set openmode active N</programlisting>
|
||||
|
||||
<para>command (where <emphasis remap=bf>N</emphasis> is the
|
||||
<para>command (where <replaceable>N</replaceable> is the
|
||||
number of seconds to wait before starting negotiations) can be
|
||||
used. Check the manual page for details.</para>
|
||||
</answer>
|
||||
|
|
@ -9425,11 +9429,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<answer>
|
||||
<para>Prior to version 2.2.5 of FreeBSD, it was possible that
|
||||
your link was disabled shortly after connection due to
|
||||
<emphasis remap=bf>ppp</emphasis> mis-handling Predictor1
|
||||
<application>ppp</application> 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 <emphasis remap=bf>ppp</emphasis>,
|
||||
running an old version of <application>ppp</application>,
|
||||
the problem can be circumvented with the line</para>
|
||||
|
||||
<programlisting>disable pred1</programlisting>
|
||||
|
|
@ -9465,7 +9469,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>There is no way for <emphasis remap=bf>ppp</emphasis> to
|
||||
<para>There is no way for <application>ppp</application> 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,
|
||||
|
|
@ -9482,7 +9486,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<para>Why does ppp dial for no reason in -auto mode</para>
|
||||
</question><answer>
|
||||
|
||||
<para>If <emphasis remap=bf>ppp</emphasis> is dialing
|
||||
<para>If <application>ppp</application> is dialing
|
||||
unexpectedly, you must determine the cause, and set up Dial
|
||||
filters (dfilters) to prevent such dialing.</para>
|
||||
|
||||
|
|
@ -9497,8 +9501,8 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<para>You can now 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 remap=bf>not</emphasis> prevent
|
||||
<emphasis remap=bf>ppp</emphasis> from passing the packets
|
||||
<emphasis>not</emphasis> prevent
|
||||
<application>ppp</application> from passing the packets
|
||||
through an established connection), use the following:</para>
|
||||
|
||||
<programlisting>set dfilter 1 deny udp src eq 53
|
||||
|
|
@ -9563,7 +9567,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
via syslogd.</para>
|
||||
|
||||
<para>The ppp specification says that an MRU of 1500 should
|
||||
<emphasis remap=bf>always</emphasis> be accepted as a minimum,
|
||||
<emphasis>always</emphasis> 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
|
||||
transmit packets of 1500 regardless, and you will tickle this
|
||||
|
|
@ -9602,7 +9606,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
\"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"</programlisting>
|
||||
|
||||
<para>Here, we get our CONNECT, send nothing, then expect a
|
||||
line-feed, forcing <emphasis remap=bf>ppp</emphasis> to read
|
||||
line-feed, forcing <application>ppp</application> to read
|
||||
the whole CONNECT response.</para>
|
||||
|
||||
</answer>
|
||||
|
|
@ -9618,7 +9622,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
interpret strings such as
|
||||
<literal>set phone "123 456 789"</literal> correctly (and
|
||||
realize that the number is actually only
|
||||
<emphasis remap=bf>one</emphasis> argument. In order to specify
|
||||
<emphasis>one</emphasis> argument. In order to specify
|
||||
a <literal>"</literal> character, you must escape it using a
|
||||
backslash (<literal>\</literal>).</para>
|
||||
|
||||
|
|
@ -9667,9 +9671,9 @@ ATDT1234567</programlisting>
|
|||
dump core. Because ppp runs with an effective user id of 0,
|
||||
the operating system will not write ppps core image to disk
|
||||
before terminating it. If, however ppp
|
||||
<emphasis remap=bf>is</emphasis> actually termating due to a
|
||||
is actually termating due to a
|
||||
segmentation violation or some other signal that normally
|
||||
causes core to be dumped, <emphasis remap=bf>and</emphasis>
|
||||
causes core to be dumped, <emphasis>and</emphasis>
|
||||
you're sure you're using the latest version (see the start of
|
||||
this section), then you should do the following:</para>
|
||||
|
||||
|
|
@ -9719,18 +9723,18 @@ ATDT1234567</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>This was a known problem with
|
||||
<emphasis remap=bf>ppp</emphasis> set up to negotiate a
|
||||
<application>ppp</application> 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
|
||||
<emphasis remap=bf>iface</emphasis>.</para>
|
||||
<literal>iface</literal>.</para>
|
||||
|
||||
<para>The problem was that when that initial program calls
|
||||
&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. <emphasis
|
||||
remap=bf>Ppp</emphasis> then reads the packet and establishes a
|
||||
connection. If, as a result of <emphasis
|
||||
remap=bf>ppp</emphasis>s dynamic IP assignment, the interface
|
||||
outgoing packet and writes it to the tun device.
|
||||
<application>ppp</application> then reads the packet and establishes a
|
||||
connection. If, as a result of
|
||||
<application>ppp</application>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 aren't, any responses will not route
|
||||
|
|
@ -9739,8 +9743,8 @@ ATDT1234567</programlisting>
|
|||
|
||||
<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 <emphasis remap=tt>:-)</emphasis>
|
||||
The current version of <emphasis remap=bf>ppp</emphasis> does
|
||||
same IP number if possible <literal>:-)</literal>
|
||||
The current version of <application>ppp</application> does
|
||||
this, but most other implementations don't.</para>
|
||||
|
||||
<para>The easiest method from our side would be to never change
|
||||
|
|
@ -9748,7 +9752,7 @@ ATDT1234567</programlisting>
|
|||
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 <emphasis remap=bf>ppp</emphasis> is
|
||||
the latest version of <application>ppp</application> is
|
||||
doing (with the help of
|
||||
&man.libalias.3; and ppp's <option>-nat</option> switch) -
|
||||
it's maintaining all previous interface addresses and NATing
|
||||
|
|
@ -9756,7 +9760,7 @@ ATDT1234567</programlisting>
|
|||
|
||||
<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. <emphasis remap=bf>Ppp</emphasis> would
|
||||
from one IP to another. <application>ppp</application> 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
|
||||
|
|
@ -9766,7 +9770,7 @@ ATDT1234567</programlisting>
|
|||
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 <emphasis remap=bf>ppp</emphasis>
|
||||
the socket. It would be up to <application>ppp</application>
|
||||
to change the source IP number, but only if it's 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
|
||||
|
|
@ -9821,7 +9825,9 @@ ATDT1234567</programlisting>
|
|||
<para>If the port numbers aren't consistent, there are three
|
||||
more options:</para>
|
||||
|
||||
<para><emphasis remap=bf>1)</emphasis> Submit support in
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Submit support in
|
||||
libalias. Examples of <quote>special cases</quote> can be found
|
||||
in <filename>/usr/src/lib/libalias/alias_*.c</filename>
|
||||
(<filename>alias_ftp.c</filename> is a good prototype). This
|
||||
|
|
@ -9834,16 +9840,22 @@ ATDT1234567</programlisting>
|
|||
|
||||
<para>This is the most difficult solution, but it is the best
|
||||
and will make the software work with multiple machines.</para>
|
||||
|
||||
<para><emphasis remap=bf>2)</emphasis> Use a proxy. The
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Use a proxy. The
|
||||
application may support socks5 for example, or (as in the
|
||||
<quote>cvsup</quote> case) may have a <quote>passive</quote>
|
||||
option that avoids ever requesting that the peer open
|
||||
connections back to the local machine.</para>
|
||||
</listitem>
|
||||
|
||||
<para><emphasis remap=bf>3)</emphasis> Redirect everything to
|
||||
<listitem>
|
||||
<para>Redirect everything to
|
||||
the internal machine using <literal>nat addr</literal>. This
|
||||
is the sledge-hammer approach.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -9933,9 +9945,9 @@ ATDT1234567</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>FCS stands for <emphasis remap=bf>F</emphasis>rame
|
||||
<emphasis remap=bf>C</emphasis>heck
|
||||
<emphasis remap=bf>S</emphasis>equence. Each ppp packet
|
||||
<para>FCS stands for <literal>F</literal>rame
|
||||
<literal>C</literal>heck
|
||||
<literal>S</literal>equence. 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
|
||||
|
|
@ -9990,7 +10002,7 @@ ATDT1234567</programlisting>
|
|||
router. MacOS and Windows 98 (and maybe other Microsoft OSs)
|
||||
send TCP packets with a requested segment size too big to fit
|
||||
into a PPPoE frame (MTU is 1500 by default for ethernet)
|
||||
<emphasis remap=bf>and</emphasis> have the <quote>don't
|
||||
<emphasis>and</emphasis> have the <quote>don't
|
||||
fragment</quote> bit set (default of TCP) and the Telco router
|
||||
is not sending ICMP <quote>must fragment</quote> back to the
|
||||
www site you are trying to load. (Alternatively, the router is
|
||||
|
|
@ -10038,12 +10050,12 @@ ATDT1234567</programlisting>
|
|||
<literal>Save as Auto Configure</literal>, and click
|
||||
<literal>Make Active</literal>.</para>
|
||||
|
||||
<para>The latest version of <emphasis remap=bf>ppp</emphasis>
|
||||
<para>The latest version of <application>ppp</application>
|
||||
(2.3 or greater) has an <command>enable tcpmssfixup</command>
|
||||
command that will automatically adjust the MSS to an appropriate
|
||||
value. This facility is enabled by default. If you're stuck
|
||||
with an older version of <emphasis remap=bf>ppp</emphasis>, you
|
||||
may want to look at the <emphasis remap=bf>tcpmssd</emphasis>
|
||||
with an older version of <application>ppp</application>, you
|
||||
may want to look at the <application>tcpmssd</application>
|
||||
port.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
|
@ -10056,7 +10068,7 @@ ATDT1234567</programlisting>
|
|||
<answer>
|
||||
<para>If all else fails, send as much information as you can,
|
||||
including your config files, how you're starting
|
||||
<emphasis remap=bf>ppp</emphasis>, the relevant parts of your
|
||||
<application>ppp</application>, the relevant parts of your
|
||||
log file and the output of the
|
||||
<command>netstat -rn</command> command (before and after connecting) to
|
||||
the <email>freebsd-questions@FreeBSD.org</email> mailing list
|
||||
|
|
@ -10670,7 +10682,7 @@ raisechar=^^</programlisting>
|
|||
<qandaentry>
|
||||
<question id="zmodem-tip">
|
||||
<para>How can I run zmodem with
|
||||
<emphasis remap=tt>tip</emphasis>?</para>
|
||||
<application>tip</application>?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
|
|
@ -10840,7 +10852,7 @@ raisechar=^^</programlisting>
|
|||
necessary and the transition made.</para>
|
||||
|
||||
<para>In FreeBSD's case, our shared library mechanism is based
|
||||
more closely on Sun's <emphasis remap=tt>SunOS</emphasis>-style
|
||||
more closely on Sun's <application>SunOS</application>-style
|
||||
shared library mechanism and, as such, is very easy to use.
|
||||
However, starting with 3.0, FreeBSD officially supports
|
||||
<acronym>ELF</acronym> binaries as the default format. Even
|
||||
|
|
@ -10967,9 +10979,9 @@ raisechar=^^</programlisting>
|
|||
<warning>
|
||||
<para>The <option>-R</option> option does a
|
||||
<acronym>RECURSIVE</acronym>
|
||||
<emphasis remap=tt>chmod</emphasis>. Be careful about
|
||||
&man.chmod.1;. Be careful about
|
||||
specifying directories or symlinks to directories to
|
||||
<emphasis remap=tt>chmod</emphasis>. If you want to
|
||||
<command>chmod</command>. If you want to
|
||||
change the permissions of a directory referenced by a
|
||||
symlink, use &man.chmod.1;
|
||||
without any options and follow the symlink
|
||||
|
|
@ -10992,7 +11004,7 @@ raisechar=^^</programlisting>
|
|||
|
||||
<qandaentry>
|
||||
<question id="login-8char">
|
||||
<para>Why are login names <emphasis remap=bf>still</emphasis>
|
||||
<para>Why are login names <emphasis>still</emphasis>
|
||||
restricted to 8 characters?</para>
|
||||
</question>
|
||||
|
||||
|
|
@ -11036,7 +11048,7 @@ raisechar=^^</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>Yes, starting with version 3.0 you can using BSDI's
|
||||
<emphasis remap=tt>doscmd</emphasis> DOS emulation which has
|
||||
<application>doscmd</application> DOS emulation which has
|
||||
been integrated and enhanced. Send mail to <ulink
|
||||
URL="mailto:freebsd-emulation@FreeBSD.org">The FreeBSD
|
||||
emulation discussion list</ulink> if you're interested in
|
||||
|
|
@ -11074,7 +11086,7 @@ raisechar=^^</programlisting>
|
|||
<para><ulink URL="http://www.grex.org/">Grex</ulink> provides a
|
||||
site very similar to M-Net including the same bulletin board
|
||||
and interactive chat software. However, the machine is a Sun
|
||||
4M and is running SunOS.</para>
|
||||
4M and is running SunOS</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -11463,11 +11475,11 @@ raisechar=^^</programlisting>
|
|||
<quote>-CURRENT</quote>.</para>
|
||||
|
||||
<para>Right now, <quote>-CURRENT</quote> is the 5.0 development
|
||||
stream and the <emphasis remap=bf>4-STABLE</emphasis> branch,
|
||||
stream and the <literal>4-STABLE</literal> branch,
|
||||
<symbol>RELENG_4</symbol>, forked off from
|
||||
<quote>-CURRENT</quote> in Mar 2000.</para>
|
||||
|
||||
<para>The <emphasis remap=bf>2.2-STABLE</emphasis> branch,
|
||||
<para>The <literal>2.2-STABLE</literal> branch,
|
||||
<symbol>RELENG_2_2</symbol>, departed -CURRENT in November
|
||||
1996, and has pretty much been retired.</para>
|
||||
</answer>
|
||||
|
|
@ -11609,7 +11621,7 @@ doc-all</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Yes, you can do this <emphasis remap=tt>without</emphasis>
|
||||
<para>Yes, you can do this <literal>without</literal>
|
||||
downloading the whole source tree by using the <ulink
|
||||
URL="../handbook/synching.html#CTM">CTM facility.</ulink></para>
|
||||
</answer>
|
||||
|
|
@ -11782,7 +11794,7 @@ ${RELEASEDIR}/tarballs/bindist/bin_tgz.)</programlisting>
|
|||
<para>This depends on whether or not you plan on making the
|
||||
driver publicly available. If you do, then please send us a
|
||||
copy of the driver source code, plus the appropriate
|
||||
modifications to <emphasis remap=tt>files.i386</emphasis>, a
|
||||
modifications to <filename>files.i386</filename>, a
|
||||
sample configuration file entry, and the appropriate
|
||||
&man.MAKEDEV.8;
|
||||
code to create any special files your device uses. If you do
|
||||
|
|
@ -11962,13 +11974,13 @@ Cc: current@FreeBSD.org</programlisting>
|
|||
|
||||
<para> To make sure you capture a crash dump, you need edit
|
||||
<filename>/etc/rc.conf</filename> and set
|
||||
<emphasis remap=tt>dumpdev</emphasis> to point to your swap
|
||||
<literal>dumpdev</literal> to point to your swap
|
||||
partition. This will cause the <command>rc(8)</command> scripts
|
||||
to use the <command>dumpon(8)</command> command to enable crash
|
||||
dumps. You can also run <command>dumpon(8)</command> manually.
|
||||
After a panic, the crash dump can be recovered using
|
||||
<command>savecore(8)</command>; if <emphasis
|
||||
remap=tt>dumpdev</emphasis> is set in
|
||||
<command>savecore(8)</command>; if
|
||||
<literal>dumpdev</literal> is set in
|
||||
<filename>/etc/rc.conf</filename>, the <command>rc(8)</command>
|
||||
scripts will run <command>savecore(8)</command> automatically
|
||||
and put the crash dump in
|
||||
|
|
@ -12036,8 +12048,8 @@ Cc: current@FreeBSD.org</programlisting>
|
|||
<para>The ELF toolchain does not, by default, make the symbols
|
||||
defined in an executable visible to the dynamic linker.
|
||||
Consequently <function>dlsym()</function> searches on handles
|
||||
obtained from calls to <emphasis remap=tt>dlopen(NULL,
|
||||
flags)</emphasis> will fail to find such symbols.</para>
|
||||
obtained from calls to <function>dlopen(NULL,
|
||||
flags)</function> will fail to find such symbols.</para>
|
||||
|
||||
<para>If you want to search, using <function>dlsym()</function>,
|
||||
for symbols present in the main executable of a process, you
|
||||
|
|
@ -12105,10 +12117,10 @@ SECTIONS
|
|||
|
||||
<para>Then reconfig and rebuild your kernel. You will probably
|
||||
have problems with <command>ps(1)</command>,
|
||||
<command>top(1)</command> and the like; <emphasis remap=tt>make
|
||||
world</emphasis> should take care of it (or a manual rebuild of
|
||||
<emphasis remap=tt>libkvm</emphasis>, <emphasis
|
||||
remap=tt>ps</emphasis> and <emphasis remap=tt>top</emphasis>
|
||||
<command>top(1)</command> and the like; <command>make
|
||||
world</command> should take care of it (or a manual rebuild of
|
||||
<filename>libkvm</filename>,
|
||||
<command>ps</command> and <command>top</command>
|
||||
after copying the patched <filename>pmap.h</filename> to
|
||||
<filename>/usr/include/vm/</filename>.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
<corpauthor>The FreeBSD Documentation Project</corpauthor>
|
||||
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.193 2001/05/14 22:57:35 dd Exp $</pubdate>
|
||||
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.194 2001/05/15 00:24:18 dd Exp $</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1995</year>
|
||||
|
|
@ -3669,7 +3669,7 @@ quit</programlisting>
|
|||
<para>
|
||||
<note>
|
||||
<para>You can not use a
|
||||
<emphasis remap=bf>dangerously dedicated</emphasis> disk
|
||||
<literal>dangerously dedicated</literal> disk
|
||||
with an HP Netserver. See <link linkend="dedicate">this
|
||||
note</link> for more info.</para>
|
||||
</note></para>
|
||||
|
|
@ -3954,7 +3954,7 @@ quit</programlisting>
|
|||
<literal>2e8</literal>, and the fourth serial port does too.
|
||||
Due to a bug (feature?) in the &man.sio.4;
|
||||
driver it will touch this port even if you don't have the
|
||||
fourth serial port, and <emphasis remap=bf>even</emphasis> if
|
||||
fourth serial port, and <emphasis>even</emphasis> if
|
||||
you disable sio3 (the fourth port) which normally uses this
|
||||
address.</para>
|
||||
|
||||
|
|
@ -5237,7 +5237,7 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
|
|||
math co-processor, right? Wrong! :-) The
|
||||
<devicename>npx0</devicename> is
|
||||
<emphasis>MANDATORY</emphasis>. Even if you don't have a
|
||||
mathematic co-processor, you <emphasis remap=bf>must</emphasis>
|
||||
mathematic co-processor, you <emphasis>must</emphasis>
|
||||
include the <devicename>npx0</devicename> device.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
|
@ -5289,12 +5289,12 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para><emphasis remap=bf>Q.</emphasis> When I compile a kernel
|
||||
<para>When I compile a kernel
|
||||
with multi-port serial code, it tells me that only the first
|
||||
port is probed and the rest skipped due to interrupt conflicts.
|
||||
How do I fix this?</para>
|
||||
|
||||
<para><emphasis remap=bf>A.</emphasis> The problem here is that
|
||||
<para>The problem here is that
|
||||
FreeBSD has code built-in to keep the kernel from getting
|
||||
trashed due to hardware or software conflicts. The way to fix
|
||||
this is to leave out the IRQ settings on all but one port. Here
|
||||
|
|
@ -5650,18 +5650,18 @@ device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para><emphasis remap=bf> Digital UNIX</emphasis> UFS CDROMs can
|
||||
<para><literal>Digital UNIX</literal> UFS CDROMs can
|
||||
be mounted directly on FreeBSD. Mounting disk partitions from
|
||||
Digital UNIX and other systems that support UFS may be more
|
||||
complex, depending on the details of the disk partitioning for
|
||||
the operating system in question.</para>
|
||||
|
||||
<para><emphasis remap=bf> Linux</emphasis>: 2.2 and later have
|
||||
support for <emphasis remap=bf>ext2fs</emphasis> partitions.
|
||||
<para><literal>Linux</literal>: 2.2 and later have
|
||||
support for <literal>ext2fs</literal> partitions.
|
||||
See &man.mount.ext2fs.8;
|
||||
for more information.</para>
|
||||
|
||||
<para><emphasis remap=bf> NT</emphasis>: A read-only NTFS driver
|
||||
<para><literal>NT</literal>: A read-only NTFS driver
|
||||
exists for FreeBSD. For more information, see this tutorial by
|
||||
Mark Ovens at
|
||||
<ulink URL="http://ukug.uk.freebsd.org/~mark/ntfs_install.html">
|
||||
|
|
@ -5699,7 +5699,7 @@ C:\="DOS"</programlisting>
|
|||
|
||||
<para>For 2.2.x systems this procedure assumes that DOS, NT,
|
||||
FreeBSD, or whatever have been installed into their respective
|
||||
fdisk partitions on the <emphasis remap=bf>same</emphasis>
|
||||
fdisk partitions on the <emphasis>same</emphasis>
|
||||
disk. This example was tested on a system where DOS & NT
|
||||
were on the first fdisk partition, and FreeBSD on the second.
|
||||
FreeBSD was also set up to boot from its native partition, not
|
||||
|
|
@ -6503,7 +6503,7 @@ rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \
|
|||
the rest.</para>
|
||||
|
||||
<para>If you've got a dynamically assigned IP number and use a
|
||||
dialup <emphasis remap=bf>ppp</emphasis> connection to the
|
||||
dialup <application>ppp</application> connection to the
|
||||
internet, you will probably be given a mailbox on your ISPs
|
||||
mail server. Lets assume your ISPs domain is
|
||||
<hostid role="domainname">myISP.com</hostid>, and that your user name is
|
||||
|
|
@ -7365,7 +7365,7 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
|
|||
<filename>/dev/sysmouse</filename>. All mouse events received
|
||||
from the real mouse device are written to the sysmouse device
|
||||
via moused. If you wish to use your mouse on one or more
|
||||
virtual consoles, <emphasis remap=bf>and</emphasis> use X, see
|
||||
virtual consoles, <emphasis>and</emphasis> use X, see
|
||||
<xref linkend="moused" remap="another section"> and set up
|
||||
moused.</para>
|
||||
|
||||
|
|
@ -7844,7 +7844,7 @@ ttyvb "/usr/libexec/getty Pc" cons25 off secure</programlisting>
|
|||
URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=startx">
|
||||
startx</ulink>, the permissions on
|
||||
<filename>/dev/console</filename> will
|
||||
<emphasis remap=tt>not</emphasis> get changed, resulting in
|
||||
<emphasis>not</emphasis> get changed, resulting in
|
||||
things like <ulink
|
||||
URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xterm">
|
||||
xterm -C</ulink> and <ulink
|
||||
|
|
@ -8740,7 +8740,7 @@ Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
|
|||
|
||||
<listitem>
|
||||
<para>Place heavily triggered rules earlier in the rule
|
||||
set than those rarely used (<emphasis remap=bf>without
|
||||
set than those rarely used (<emphasis>without
|
||||
changing the permissiveness of the firewall</emphasis>,
|
||||
of course). You can see which rules are used most often
|
||||
by examining the packet counting statistics with
|
||||
|
|
@ -8970,10 +8970,10 @@ Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
|
|||
<programlisting>set log Phase Chat Connect Carrier lcp ipcp ccp command</programlisting>
|
||||
|
||||
<para>This command may be typed at the
|
||||
<emphasis remap=bf>ppp</emphasis> command prompt or it may be
|
||||
<application>ppp</application> command prompt or it may be
|
||||
entered in the <filename>/etc/ppp/ppp.conf</filename>
|
||||
configuration file (the start of the
|
||||
<emphasis remap=bf>default</emphasis> section is the best
|
||||
<literal>default</literal> section is the best
|
||||
place to put it). Make sure that
|
||||
<filename>/etc/syslog.conf</filename> (see &man.syslog.conf.5;) contains the lines</para>
|
||||
|
||||
|
|
@ -9038,7 +9038,7 @@ default 10.0.0.2 UGSc 0 0 tun0
|
|||
running an old version of &man.ppp.8;
|
||||
that doesn't understand the word <literal>HISADDR</literal>
|
||||
in the ppp.conf file. If your version of
|
||||
<emphasis remap=bf>ppp</emphasis> is from before FreeBSD
|
||||
<application>ppp</application> is from before FreeBSD
|
||||
2.2.5, change the</para>
|
||||
|
||||
<programlisting>add 0 0 HISADDR</programlisting>
|
||||
|
|
@ -9080,7 +9080,7 @@ default 10.0.0.2 UGSc 0 0 tun0
|
|||
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
|
||||
<emphasis remap=tt>packet mode</emphasis> (packet mode is
|
||||
<literal>packet mode</literal> (packet mode is
|
||||
indicated by the capitalized <acronym>PPP</acronym> in the
|
||||
prompt):</para>
|
||||
|
||||
|
|
@ -9111,8 +9111,8 @@ add 0 0 HISADDR</programlisting>
|
|||
closed due to a timeout. It is possible to put this command in
|
||||
the <filename>ppp.conf</filename> 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 <emphasis
|
||||
remap=bf>ppp</emphasis>s server socket using
|
||||
the fly while the line is active by connecting to
|
||||
<application>ppp</application>s server socket using
|
||||
&man.telnet.1; or &man.pppctl.8;.
|
||||
Refer to the
|
||||
&man.ppp.8; man
|
||||
|
|
@ -9267,15 +9267,19 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
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
|
||||
<emphasis remap=bf>ppp</emphasis> to initiate the LCP, use the
|
||||
<application>ppp</application> to initiate the LCP, use the
|
||||
following line:</para>
|
||||
|
||||
<programlisting>set openmode active</programlisting>
|
||||
|
||||
<para><emphasis remap=bf>Note</emphasis>: It usually does no
|
||||
<para>
|
||||
<note>
|
||||
<para>It usually does no
|
||||
harm if both sides initiate negotiation, so openmode is now
|
||||
active by default. However, the next section explains when
|
||||
it <emphasis remap=bf>does</emphasis> do some harm.</para>
|
||||
it <emphasis>does</emphasis> do some harm.</para>
|
||||
</note>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -9349,44 +9353,44 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>There is currently an implementation mis-feature in
|
||||
<emphasis remap=bf>ppp</emphasis> where it doesn't associate
|
||||
<application>ppp</application> where it doesn't associate
|
||||
LCP, CCP & IPCP responses with their original requests. As
|
||||
a result, if one <emphasis remap=bf>ppp</emphasis>
|
||||
a result, if one <application>ppp</application>
|
||||
implementation is more than 6 seconds slower than the other
|
||||
side, the other side will send two additional LCP configuration
|
||||
requests. This is fatal.</para>
|
||||
|
||||
<para>Consider two implementations,
|
||||
<emphasis remap=bf>A</emphasis> and <emphasis
|
||||
remap=bf>B</emphasis>. <emphasis remap=bf>A</emphasis> starts
|
||||
sending LCP requests immediately after connecting and <emphasis
|
||||
remap=bf>B</emphasis> takes 7 seconds to start. When <emphasis
|
||||
remap=bf>B</emphasis> starts, <emphasis remap=bf>A</emphasis>
|
||||
<hostid>A</hostid> and
|
||||
<hostid>B</hostid>. <hostid>A</hostid> starts
|
||||
sending LCP requests immediately after connecting and
|
||||
<hostid>B</hostid> takes 7 seconds to start. When
|
||||
<hostid>B</hostid> starts, <hostid>A</hostid>
|
||||
has sent 3 LCP REQs. We're assuming the line has ECHO switched
|
||||
off, otherwise we'd see magic number problems as described in
|
||||
the previous section. <emphasis remap=bf>B</emphasis> sends a
|
||||
REQ, then an ACK to the first of <emphasis
|
||||
remap=bf>A</emphasis>'s REQs. This results in <emphasis
|
||||
remap=bf>A</emphasis> entering the <acronym>OPENED</acronym>
|
||||
state and sending and ACK (the first) back to <emphasis
|
||||
remap=bf>B</emphasis>. In the meantime, <emphasis
|
||||
remap=bf>B</emphasis> sends back two more ACKs in response to
|
||||
the two additional REQs sent by <emphasis remap=bf>A</emphasis>
|
||||
before <emphasis remap=bf>B</emphasis> started up. <emphasis
|
||||
remap=bf>B</emphasis> then receives the first ACK from
|
||||
<emphasis remap=bf>A</emphasis> and enters the
|
||||
<acronym>OPENED</acronym> state. <emphasis
|
||||
remap=bf>A</emphasis> receives the second ACK from <emphasis
|
||||
remap=bf>B</emphasis> and goes back to the <emphasis
|
||||
remap=bf>REQ-SENT</emphasis> state, sending another (forth) REQ
|
||||
the previous section. <hostid>B</hostid> sends a
|
||||
REQ, then an ACK to the first of
|
||||
<hostid>A</hostid>'s REQs. This results in
|
||||
<hostid>A</hostid> entering the <acronym>OPENED</acronym>
|
||||
state and sending and ACK (the first) back to
|
||||
<hostid>B</hostid>. In the meantime,
|
||||
<hostid>B</hostid> sends back two more ACKs in response to
|
||||
the two additional REQs sent by <hostid>A</hostid>
|
||||
before <hostid>B</hostid> started up.
|
||||
<hostid>B</hostid> then receives the first ACK from
|
||||
<hostid>A</hostid> and enters the
|
||||
<acronym>OPENED</acronym> state.
|
||||
<hostid>A</hostid> receives the second ACK from
|
||||
<hostid>B</hostid> and goes back to the
|
||||
<literal>REQ-SENT</literal> state, sending another (forth) REQ
|
||||
as per the RFC. It then receives the third ACK and enters the
|
||||
<acronym>OPENED</acronym> state. In the meantime, <emphasis
|
||||
remap=bf>B</emphasis> receives the forth REQ from <emphasis
|
||||
remap=bf>A</emphasis>, resulting in it reverting to the
|
||||
<emphasis remap=bf>ACK-SENT</emphasis> state and sending
|
||||
another (second) REQ and (forth) ACK as per the RFC. <emphasis
|
||||
remap=bf>A</emphasis> gets the REQ, goes into <emphasis
|
||||
remap=bf>REQ-SENT</emphasis> and sends another REQ. It
|
||||
<acronym>OPENED</acronym> state. In the meantime,
|
||||
<hostid>B</hostid> receives the forth REQ from
|
||||
<hostid>A</hostid>, resulting in it reverting to the
|
||||
<literal>ACK-SENT</literal> state and sending
|
||||
another (second) REQ and (forth) ACK as per the RFC.
|
||||
<hostid>A</hostid> gets the REQ, goes into
|
||||
<literal>REQ-SENT</literal> and sends another REQ. It
|
||||
immediately receives the following ACK and enters
|
||||
<acronym>OPENED</acronym>.</para>
|
||||
|
||||
|
|
@ -9394,7 +9398,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
getting nowhere and gives up.</para>
|
||||
|
||||
<para>The best way to avoid this is to configure one side to be
|
||||
<emphasis remap=bf>passive</emphasis> - that is, make one side
|
||||
<literal>passive</literal> - that is, make one side
|
||||
wait for the other to start negotiating. This can be done
|
||||
with the</para>
|
||||
|
||||
|
|
@ -9406,12 +9410,12 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<programlisting>set stopped N</programlisting>
|
||||
|
||||
<para>command to limit the amount of time that
|
||||
<emphasis remap=bf>ppp</emphasis> waits for the peer to begin
|
||||
<application>ppp</application> waits for the peer to begin
|
||||
negotiations. Alternatively, the</para>
|
||||
|
||||
<programlisting>set openmode active N</programlisting>
|
||||
|
||||
<para>command (where <emphasis remap=bf>N</emphasis> is the
|
||||
<para>command (where <replaceable>N</replaceable> is the
|
||||
number of seconds to wait before starting negotiations) can be
|
||||
used. Check the manual page for details.</para>
|
||||
</answer>
|
||||
|
|
@ -9425,11 +9429,11 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<answer>
|
||||
<para>Prior to version 2.2.5 of FreeBSD, it was possible that
|
||||
your link was disabled shortly after connection due to
|
||||
<emphasis remap=bf>ppp</emphasis> mis-handling Predictor1
|
||||
<application>ppp</application> 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 <emphasis remap=bf>ppp</emphasis>,
|
||||
running an old version of <application>ppp</application>,
|
||||
the problem can be circumvented with the line</para>
|
||||
|
||||
<programlisting>disable pred1</programlisting>
|
||||
|
|
@ -9465,7 +9469,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>There is no way for <emphasis remap=bf>ppp</emphasis> to
|
||||
<para>There is no way for <application>ppp</application> 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,
|
||||
|
|
@ -9482,7 +9486,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<para>Why does ppp dial for no reason in -auto mode</para>
|
||||
</question><answer>
|
||||
|
||||
<para>If <emphasis remap=bf>ppp</emphasis> is dialing
|
||||
<para>If <application>ppp</application> is dialing
|
||||
unexpectedly, you must determine the cause, and set up Dial
|
||||
filters (dfilters) to prevent such dialing.</para>
|
||||
|
||||
|
|
@ -9497,8 +9501,8 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
|
|||
<para>You can now 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 remap=bf>not</emphasis> prevent
|
||||
<emphasis remap=bf>ppp</emphasis> from passing the packets
|
||||
<emphasis>not</emphasis> prevent
|
||||
<application>ppp</application> from passing the packets
|
||||
through an established connection), use the following:</para>
|
||||
|
||||
<programlisting>set dfilter 1 deny udp src eq 53
|
||||
|
|
@ -9563,7 +9567,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
via syslogd.</para>
|
||||
|
||||
<para>The ppp specification says that an MRU of 1500 should
|
||||
<emphasis remap=bf>always</emphasis> be accepted as a minimum,
|
||||
<emphasis>always</emphasis> 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
|
||||
transmit packets of 1500 regardless, and you will tickle this
|
||||
|
|
@ -9602,7 +9606,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
\"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"</programlisting>
|
||||
|
||||
<para>Here, we get our CONNECT, send nothing, then expect a
|
||||
line-feed, forcing <emphasis remap=bf>ppp</emphasis> to read
|
||||
line-feed, forcing <application>ppp</application> to read
|
||||
the whole CONNECT response.</para>
|
||||
|
||||
</answer>
|
||||
|
|
@ -9618,7 +9622,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
|
|||
interpret strings such as
|
||||
<literal>set phone "123 456 789"</literal> correctly (and
|
||||
realize that the number is actually only
|
||||
<emphasis remap=bf>one</emphasis> argument. In order to specify
|
||||
<emphasis>one</emphasis> argument. In order to specify
|
||||
a <literal>"</literal> character, you must escape it using a
|
||||
backslash (<literal>\</literal>).</para>
|
||||
|
||||
|
|
@ -9667,9 +9671,9 @@ ATDT1234567</programlisting>
|
|||
dump core. Because ppp runs with an effective user id of 0,
|
||||
the operating system will not write ppps core image to disk
|
||||
before terminating it. If, however ppp
|
||||
<emphasis remap=bf>is</emphasis> actually termating due to a
|
||||
is actually termating due to a
|
||||
segmentation violation or some other signal that normally
|
||||
causes core to be dumped, <emphasis remap=bf>and</emphasis>
|
||||
causes core to be dumped, <emphasis>and</emphasis>
|
||||
you're sure you're using the latest version (see the start of
|
||||
this section), then you should do the following:</para>
|
||||
|
||||
|
|
@ -9719,18 +9723,18 @@ ATDT1234567</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>This was a known problem with
|
||||
<emphasis remap=bf>ppp</emphasis> set up to negotiate a
|
||||
<application>ppp</application> 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
|
||||
<emphasis remap=bf>iface</emphasis>.</para>
|
||||
<literal>iface</literal>.</para>
|
||||
|
||||
<para>The problem was that when that initial program calls
|
||||
&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. <emphasis
|
||||
remap=bf>Ppp</emphasis> then reads the packet and establishes a
|
||||
connection. If, as a result of <emphasis
|
||||
remap=bf>ppp</emphasis>s dynamic IP assignment, the interface
|
||||
outgoing packet and writes it to the tun device.
|
||||
<application>ppp</application> then reads the packet and establishes a
|
||||
connection. If, as a result of
|
||||
<application>ppp</application>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 aren't, any responses will not route
|
||||
|
|
@ -9739,8 +9743,8 @@ ATDT1234567</programlisting>
|
|||
|
||||
<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 <emphasis remap=tt>:-)</emphasis>
|
||||
The current version of <emphasis remap=bf>ppp</emphasis> does
|
||||
same IP number if possible <literal>:-)</literal>
|
||||
The current version of <application>ppp</application> does
|
||||
this, but most other implementations don't.</para>
|
||||
|
||||
<para>The easiest method from our side would be to never change
|
||||
|
|
@ -9748,7 +9752,7 @@ ATDT1234567</programlisting>
|
|||
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 <emphasis remap=bf>ppp</emphasis> is
|
||||
the latest version of <application>ppp</application> is
|
||||
doing (with the help of
|
||||
&man.libalias.3; and ppp's <option>-nat</option> switch) -
|
||||
it's maintaining all previous interface addresses and NATing
|
||||
|
|
@ -9756,7 +9760,7 @@ ATDT1234567</programlisting>
|
|||
|
||||
<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. <emphasis remap=bf>Ppp</emphasis> would
|
||||
from one IP to another. <application>ppp</application> 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
|
||||
|
|
@ -9766,7 +9770,7 @@ ATDT1234567</programlisting>
|
|||
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 <emphasis remap=bf>ppp</emphasis>
|
||||
the socket. It would be up to <application>ppp</application>
|
||||
to change the source IP number, but only if it's 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
|
||||
|
|
@ -9821,7 +9825,9 @@ ATDT1234567</programlisting>
|
|||
<para>If the port numbers aren't consistent, there are three
|
||||
more options:</para>
|
||||
|
||||
<para><emphasis remap=bf>1)</emphasis> Submit support in
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Submit support in
|
||||
libalias. Examples of <quote>special cases</quote> can be found
|
||||
in <filename>/usr/src/lib/libalias/alias_*.c</filename>
|
||||
(<filename>alias_ftp.c</filename> is a good prototype). This
|
||||
|
|
@ -9834,16 +9840,22 @@ ATDT1234567</programlisting>
|
|||
|
||||
<para>This is the most difficult solution, but it is the best
|
||||
and will make the software work with multiple machines.</para>
|
||||
|
||||
<para><emphasis remap=bf>2)</emphasis> Use a proxy. The
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Use a proxy. The
|
||||
application may support socks5 for example, or (as in the
|
||||
<quote>cvsup</quote> case) may have a <quote>passive</quote>
|
||||
option that avoids ever requesting that the peer open
|
||||
connections back to the local machine.</para>
|
||||
</listitem>
|
||||
|
||||
<para><emphasis remap=bf>3)</emphasis> Redirect everything to
|
||||
<listitem>
|
||||
<para>Redirect everything to
|
||||
the internal machine using <literal>nat addr</literal>. This
|
||||
is the sledge-hammer approach.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -9933,9 +9945,9 @@ ATDT1234567</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>FCS stands for <emphasis remap=bf>F</emphasis>rame
|
||||
<emphasis remap=bf>C</emphasis>heck
|
||||
<emphasis remap=bf>S</emphasis>equence. Each ppp packet
|
||||
<para>FCS stands for <literal>F</literal>rame
|
||||
<literal>C</literal>heck
|
||||
<literal>S</literal>equence. 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
|
||||
|
|
@ -9990,7 +10002,7 @@ ATDT1234567</programlisting>
|
|||
router. MacOS and Windows 98 (and maybe other Microsoft OSs)
|
||||
send TCP packets with a requested segment size too big to fit
|
||||
into a PPPoE frame (MTU is 1500 by default for ethernet)
|
||||
<emphasis remap=bf>and</emphasis> have the <quote>don't
|
||||
<emphasis>and</emphasis> have the <quote>don't
|
||||
fragment</quote> bit set (default of TCP) and the Telco router
|
||||
is not sending ICMP <quote>must fragment</quote> back to the
|
||||
www site you are trying to load. (Alternatively, the router is
|
||||
|
|
@ -10038,12 +10050,12 @@ ATDT1234567</programlisting>
|
|||
<literal>Save as Auto Configure</literal>, and click
|
||||
<literal>Make Active</literal>.</para>
|
||||
|
||||
<para>The latest version of <emphasis remap=bf>ppp</emphasis>
|
||||
<para>The latest version of <application>ppp</application>
|
||||
(2.3 or greater) has an <command>enable tcpmssfixup</command>
|
||||
command that will automatically adjust the MSS to an appropriate
|
||||
value. This facility is enabled by default. If you're stuck
|
||||
with an older version of <emphasis remap=bf>ppp</emphasis>, you
|
||||
may want to look at the <emphasis remap=bf>tcpmssd</emphasis>
|
||||
with an older version of <application>ppp</application>, you
|
||||
may want to look at the <application>tcpmssd</application>
|
||||
port.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
|
@ -10056,7 +10068,7 @@ ATDT1234567</programlisting>
|
|||
<answer>
|
||||
<para>If all else fails, send as much information as you can,
|
||||
including your config files, how you're starting
|
||||
<emphasis remap=bf>ppp</emphasis>, the relevant parts of your
|
||||
<application>ppp</application>, the relevant parts of your
|
||||
log file and the output of the
|
||||
<command>netstat -rn</command> command (before and after connecting) to
|
||||
the <email>freebsd-questions@FreeBSD.org</email> mailing list
|
||||
|
|
@ -10670,7 +10682,7 @@ raisechar=^^</programlisting>
|
|||
<qandaentry>
|
||||
<question id="zmodem-tip">
|
||||
<para>How can I run zmodem with
|
||||
<emphasis remap=tt>tip</emphasis>?</para>
|
||||
<application>tip</application>?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
|
|
@ -10840,7 +10852,7 @@ raisechar=^^</programlisting>
|
|||
necessary and the transition made.</para>
|
||||
|
||||
<para>In FreeBSD's case, our shared library mechanism is based
|
||||
more closely on Sun's <emphasis remap=tt>SunOS</emphasis>-style
|
||||
more closely on Sun's <application>SunOS</application>-style
|
||||
shared library mechanism and, as such, is very easy to use.
|
||||
However, starting with 3.0, FreeBSD officially supports
|
||||
<acronym>ELF</acronym> binaries as the default format. Even
|
||||
|
|
@ -10967,9 +10979,9 @@ raisechar=^^</programlisting>
|
|||
<warning>
|
||||
<para>The <option>-R</option> option does a
|
||||
<acronym>RECURSIVE</acronym>
|
||||
<emphasis remap=tt>chmod</emphasis>. Be careful about
|
||||
&man.chmod.1;. Be careful about
|
||||
specifying directories or symlinks to directories to
|
||||
<emphasis remap=tt>chmod</emphasis>. If you want to
|
||||
<command>chmod</command>. If you want to
|
||||
change the permissions of a directory referenced by a
|
||||
symlink, use &man.chmod.1;
|
||||
without any options and follow the symlink
|
||||
|
|
@ -10992,7 +11004,7 @@ raisechar=^^</programlisting>
|
|||
|
||||
<qandaentry>
|
||||
<question id="login-8char">
|
||||
<para>Why are login names <emphasis remap=bf>still</emphasis>
|
||||
<para>Why are login names <emphasis>still</emphasis>
|
||||
restricted to 8 characters?</para>
|
||||
</question>
|
||||
|
||||
|
|
@ -11036,7 +11048,7 @@ raisechar=^^</programlisting>
|
|||
|
||||
<answer>
|
||||
<para>Yes, starting with version 3.0 you can using BSDI's
|
||||
<emphasis remap=tt>doscmd</emphasis> DOS emulation which has
|
||||
<application>doscmd</application> DOS emulation which has
|
||||
been integrated and enhanced. Send mail to <ulink
|
||||
URL="mailto:freebsd-emulation@FreeBSD.org">The FreeBSD
|
||||
emulation discussion list</ulink> if you're interested in
|
||||
|
|
@ -11074,7 +11086,7 @@ raisechar=^^</programlisting>
|
|||
<para><ulink URL="http://www.grex.org/">Grex</ulink> provides a
|
||||
site very similar to M-Net including the same bulletin board
|
||||
and interactive chat software. However, the machine is a Sun
|
||||
4M and is running SunOS.</para>
|
||||
4M and is running SunOS</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -11463,11 +11475,11 @@ raisechar=^^</programlisting>
|
|||
<quote>-CURRENT</quote>.</para>
|
||||
|
||||
<para>Right now, <quote>-CURRENT</quote> is the 5.0 development
|
||||
stream and the <emphasis remap=bf>4-STABLE</emphasis> branch,
|
||||
stream and the <literal>4-STABLE</literal> branch,
|
||||
<symbol>RELENG_4</symbol>, forked off from
|
||||
<quote>-CURRENT</quote> in Mar 2000.</para>
|
||||
|
||||
<para>The <emphasis remap=bf>2.2-STABLE</emphasis> branch,
|
||||
<para>The <literal>2.2-STABLE</literal> branch,
|
||||
<symbol>RELENG_2_2</symbol>, departed -CURRENT in November
|
||||
1996, and has pretty much been retired.</para>
|
||||
</answer>
|
||||
|
|
@ -11609,7 +11621,7 @@ doc-all</programlisting>
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Yes, you can do this <emphasis remap=tt>without</emphasis>
|
||||
<para>Yes, you can do this <literal>without</literal>
|
||||
downloading the whole source tree by using the <ulink
|
||||
URL="../handbook/synching.html#CTM">CTM facility.</ulink></para>
|
||||
</answer>
|
||||
|
|
@ -11782,7 +11794,7 @@ ${RELEASEDIR}/tarballs/bindist/bin_tgz.)</programlisting>
|
|||
<para>This depends on whether or not you plan on making the
|
||||
driver publicly available. If you do, then please send us a
|
||||
copy of the driver source code, plus the appropriate
|
||||
modifications to <emphasis remap=tt>files.i386</emphasis>, a
|
||||
modifications to <filename>files.i386</filename>, a
|
||||
sample configuration file entry, and the appropriate
|
||||
&man.MAKEDEV.8;
|
||||
code to create any special files your device uses. If you do
|
||||
|
|
@ -11962,13 +11974,13 @@ Cc: current@FreeBSD.org</programlisting>
|
|||
|
||||
<para> To make sure you capture a crash dump, you need edit
|
||||
<filename>/etc/rc.conf</filename> and set
|
||||
<emphasis remap=tt>dumpdev</emphasis> to point to your swap
|
||||
<literal>dumpdev</literal> to point to your swap
|
||||
partition. This will cause the <command>rc(8)</command> scripts
|
||||
to use the <command>dumpon(8)</command> command to enable crash
|
||||
dumps. You can also run <command>dumpon(8)</command> manually.
|
||||
After a panic, the crash dump can be recovered using
|
||||
<command>savecore(8)</command>; if <emphasis
|
||||
remap=tt>dumpdev</emphasis> is set in
|
||||
<command>savecore(8)</command>; if
|
||||
<literal>dumpdev</literal> is set in
|
||||
<filename>/etc/rc.conf</filename>, the <command>rc(8)</command>
|
||||
scripts will run <command>savecore(8)</command> automatically
|
||||
and put the crash dump in
|
||||
|
|
@ -12036,8 +12048,8 @@ Cc: current@FreeBSD.org</programlisting>
|
|||
<para>The ELF toolchain does not, by default, make the symbols
|
||||
defined in an executable visible to the dynamic linker.
|
||||
Consequently <function>dlsym()</function> searches on handles
|
||||
obtained from calls to <emphasis remap=tt>dlopen(NULL,
|
||||
flags)</emphasis> will fail to find such symbols.</para>
|
||||
obtained from calls to <function>dlopen(NULL,
|
||||
flags)</function> will fail to find such symbols.</para>
|
||||
|
||||
<para>If you want to search, using <function>dlsym()</function>,
|
||||
for symbols present in the main executable of a process, you
|
||||
|
|
@ -12105,10 +12117,10 @@ SECTIONS
|
|||
|
||||
<para>Then reconfig and rebuild your kernel. You will probably
|
||||
have problems with <command>ps(1)</command>,
|
||||
<command>top(1)</command> and the like; <emphasis remap=tt>make
|
||||
world</emphasis> should take care of it (or a manual rebuild of
|
||||
<emphasis remap=tt>libkvm</emphasis>, <emphasis
|
||||
remap=tt>ps</emphasis> and <emphasis remap=tt>top</emphasis>
|
||||
<command>top(1)</command> and the like; <command>make
|
||||
world</command> should take care of it (or a manual rebuild of
|
||||
<filename>libkvm</filename>,
|
||||
<command>ps</command> and <command>top</command>
|
||||
after copying the patched <filename>pmap.h</filename> to
|
||||
<filename>/usr/include/vm/</filename>.</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue