path: root/zh/FAQ
diff options
authorFoxfair Hu <foxfair@FreeBSD.org>1999-04-21 05:26:08 +0000
committerFoxfair Hu <foxfair@FreeBSD.org>1999-04-21 05:26:08 +0000
commit4eccc1e9878e83391a4294c7caf4791dd59826fa (patch)
tree888a4d664f0a41c6951856d3a4d43dbe0a2679fd /zh/FAQ
parent1288a8419426ed58c648449caffa9f7d243c9376 (diff)
Introduce the final part of Chinese(big5) FAQ, the next step I'd like to
let Simplified Chinese(GB2312) FAQ show up. These two files was submitted by: J.T. Jang <jtjang@gcn.net.tw> The translation of Handbook(new DocBook) is in progress , too.
Notes: svn path=/head/; revision=4721
Diffstat (limited to 'zh/FAQ')
2 files changed, 800 insertions, 865 deletions
diff --git a/zh/FAQ/hackers.sgml b/zh/FAQ/hackers.sgml
index 3ddcd8a408..99fc61bd7d 100644
--- a/zh/FAQ/hackers.sgml
+++ b/zh/FAQ/hackers.sgml
@@ -1,58 +1,54 @@
-<!-- $Id: hackers.sgml,v 1.2 1999-03-21 16:25:40 wosch Exp $ -->
+<!-- $Id: hackers.sgml,v 1.3 1999-04-21 05:26:07 foxfair Exp $ -->
<!-- The FreeBSD Documentation Project -->
-<!-- Translate into Chinese by -->
+<!-- Translate into Chinese by jtjang@gcn.net.tw -->
<!-- English Version: 1.11 -->
- <heading>For serious FreeBSD hackers only<label id="hackers"></heading>
+ <heading>只給正經的 FreeBSD hacker 看<label id="hackers"></heading>
- <heading>
- What are SNAPs and RELEASEs?
- </heading>
+ <heading>SNAPs 和 RELEASEs 是什麼?</heading>
- <p>There are currently three active/semi-active branches in the FreeBSD
+ <p>目前有三個活躍/半活躍的分支在 FreeBSD 的
<url url="http://www.freebsd.org/cgi/cvsweb.cgi" name="CVS Repository">:
- <item><bf/RELENG_2_2/ AKA <bf/2.2-stable/ AKA <bf/"2.2 branch"/
- <item><bf/RELENG_3/ AKA <bf/3.x-stable/ AKA <bf/"3.0 branch"/
- <item><bf/HEAD/ AKA <bf/-current/ AKA <bf/4.0-current/
+ <item><bf/RELENG_2_2/ 即 <bf/2.2-stable/ 即 <bf/"2.2 branch"/
+ <item><bf/RELENG_3/ 即 <bf/3.x-stable/ 即 <bf/"3.0 branch"/
+ <item><bf/HEAD/ 即 <bf/-current/ 即 <bf/4.0-current/
- <p><bf/HEAD/ is not an actual branch tag, like the other two, it's
- simply a symbolic constant for
- <em/"the current, non-branched development stream"/ which we simply
- refer to as <bf/-current/.
+ <p>如同其他兩個,<bf/HEAD/ 並不是真正的 branch tag,它只是一個符號
+ 常數,指向 <em/"current:尚未分支的發展中版本"/ ,簡記為
+ <bf/-current/。
- <p>Right now, <bf/-current/ is the 4.0 development stream and the
- <bf/3.0-stable/ branch, <bf/RELENG_3/, forked off from
- <bf/-current/ in Jan 1999.
+ <p>以現在來說,<bf/-current/ 朝向 4.0 發展,而 <bf/3.0-stable/ 這
+ 個分支,也就是 <bf/RELENG_3/,在 1999 年 1 月從 <bf/-current/ 分出
+ 來。
- <p>The <bf/2.2-stable/ branch, <bf/RELENG_2_2/, departed -current in
- November 1996.
+ <p><bf/2.2-stable/ 這個分支,也就是 <bf/RELENG_2_2/,是在 1996 年
+ 11 月從 -current 分出來。
- <p>The <bf/2.1-stable/ branch, <bf/RELENG_2_1_0/, departed -current in
- September of 1994. This branch has been fully retired.
+ <p><bf/2.1-stable/ 這個分支,也就是 <bf/RELENG_2_1_0/,則是在
+ 1994 年 9 月從 -current 分支出來,這個分支已經完全退休了。
- How do I make my own custom release?<label id="custrel">
+ 我要怎麼作出自己的 release?<label id="custrel">
- <p>To make a release you need to do three things: First, you need to
- be running a kernel with the <htmlurl
- url="http://www.freebsd.org/cgi/man.cgi?vn" name="vn"> driver configured
- in. Add this to your kernel config file and build a new kernel:
+ <p>做 release 包括下面這三個步驟:首先,做出有 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?vn" name="vn"> 這個驅動程
+ 式的可用 kernel。把下面這一行加到 kernel 設定檔,然後做出新的
+ kernel 重新開機:
pseudo-device vn #Vnode driver (turns a file into a device)
- <p>Second, you have to have the whole CVS repository at hand.
- To get this you can use <url url="../../handbook/cvsup.html" name="CVSUP">
- but in your supfile set the release name to cvs and remove any tag or
- date fields:
+ <p>接著,你手上要有整個 CVS repository。可以參考 <url
+ url="../handbook/cvsup.html" name="CVSUP"> 這篇文章,但在 supfile
+ 中把 release 名稱設成 cvs,再刪掉所有 tag 或 date 的欄位,如下:
*default prefix=/home/ncvs
@@ -72,12 +68,11 @@
- <p>Then run <tt/cvsup -g supfile/ to suck all the good bits onto your
- box...
+ <p>然後執行 <tt/cvsup -g supfile/ 把所有東西都抓下來...
- <p>Finally, you need a chunk of empty space to build into. Let's
- say it's in <tt>/some/big/filesystem</tt>, and from the example
- above you've got the CVS repository in <tt>/home/ncvs</tt>:
+ <p>最後,硬碟要有相當大的空間來做 release。假設你想把它放在
+ <tt>/some/big/filesystem</tt> 這裡,上面這個例子也把 CVS
+ repository 放在 <tt>/home/ncvs</tt> 了,接著:
setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
@@ -85,70 +80,59 @@
make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
- <p>An entire release will be built in
- <tt>/some/big/filesystem/release</tt> and you will have a full FTP-type
- installation in <tt>/some/big/filesystem/release/R/ftp</tt> when you're
- done. If you want to build your SNAP along some other branch than
- -current, you can also add <tt/RELEASETAG=SOMETAG/ to
- the make release command line above, e.g. <tt/RELEASETAG=RELENG_2_2/
- would build an up-to-the- minute 2.2-STABLE snapshot.
+ <p>整個 release 會做在 <tt>/some/big/filesystem/release</tt>。結束
+ 時 <tt>/some/big/filesystem/release/R/ftp</tt> 這個目錄可以直接用
+ 來做為 FTP 安裝方式的來源。如果想做出 -current 以外分支的 SNAP,
+ 在上面 make release 這一行加 <tt/RELEASETAG=SOMETAG/。舉例來說,
+ <tt/RELEASETAG=RELENG_2_2/ 這個參數會做個即時的 2.2-STABLE snapshot。
- <heading>How do I create customized installation disks?</heading>
+ <heading>怎樣才能做出自己用的安裝磁片?</heading>
- <p>The entire process of creating installation disks and source and
- binary archives is automated by various targets in
- <tt>/usr/src/release/Makefile</tt>. The information there should
- be enough to get you started. However, it should be said that this
- involves doing a ``make world'' and will therefore take up a lot of
- time and disk space.
+ <p>建立安裝磁片、還有做出 source/binary archive,都是由
+ <tt>/usr/src/release/Makefile</tt> 裡面的各種 target 自動產生,這
+ 個檔案裡的資訊應該足以開始。但是這個過程牽涉到 make world,所以會
+ 用到相當多的時間和硬碟空間。
- <heading>``make world'' clobbers my existing installed binaries.</heading>
+ <heading>``make world'' 把原來裝的 binary 檔都換掉了。</heading>
- <p>Yes, this is the general idea; as its name might suggest,
- ``make world'' rebuilds every system binary from scratch, so you can be
- certain of having a clean and consistent environment at the end (which
- is why it takes so long).
+ <p>沒錯,就是這樣子。如名字所示,``make world'' 會重新編譯系統內建
+ 的每個 binary 檔,這樣在結束時就可確定有個一致且乾淨的環境(所以要
+ 花上好一段時間)。
- <p>If the environment variable <tt/DESTDIR/ is defined while running
- ``<tt/make world/'' or ``<tt/make install/'', the newly-created
- binaries will be deposited in a directory tree identical to the
- installed one, rooted at <tt>&dollar;&lcub;DESTDIR&rcub;</tt>.
- Some random combination of shared libraries modifications and
- program rebuilds can cause this to fail in ``<tt/make world/'',
- however.
+ <p>在執行 ``<tt/make world/'' 或 ``<tt/make install/'' 時,如果有
+ 設 <tt/DESTDIR/ 這個環境變數,新產生的 binary 將會裝在
+ <tt>&dollar;&lcub;DESTDIR&rcub;</tt> 下的同樣目錄樹中。但在某些修
+ 改 shared library 和重建 binary 的無特定情況下,這樣做可能會使
+ ``<tt/make world/'' 失敗。
- When my system boots, it says ``(bus speed defaulted)''.
+ 在系統開機時,出現 ``(bus speed defaulted)''。
- <p>The Adaptec 1542 SCSI host adapters allow the user to configure
- their bus access speed in software. Previous versions of the
- 1542 driver tried to determine the fastest usable speed and set
- the adapter to that. We found that this breaks some users'
- systems, so you now have to define the ``<tt/TUNE&lowbar;1542/'' kernel
- configuration option in order to have this take place. Using it
- on those systems where it works may make your disks run faster,
- but on those systems where it doesn't, your data could be
- corrupted.
+ <p>Adaptec 1542 SCSI 卡允許使用者用軟體調整匯流排的存取速度。早
+ 期的 1542 驅動程式試圖將它設成可用的最快速度,但後來發現在一些
+ 機器上不能用,所以現在要在 kernel 設定中加 ``<tt/TUNE&lowbar;1542/''
+ 這個選項來啟動這個功能。在支援的機器上用這個選項會使硬碟存取更
+ 快,但在不支援的機器上有可能會毀掉資料。
- Can I follow current with limited Internet access?<label id="ctm">
+ 我的網路連線不快,那可以跟著 current 的發展嗎?<label id="ctm">
- <p>Yes, you can do this <tt /without/ downloading the whole source tree
- by using the <url url="../../handbook/ctm.html" name="CTM facility.">
+ <p>可以,藉著 <url url="../handbook/ctm.html" name="CTM"> 就
+ 可以不用下傳所有的原始碼目錄樹。
- <heading>How did you split the distribution into 240k files?</heading>
+ <heading>你是怎麼把發行版本中的檔案切成一個個 240k 的小檔案?</heading>
- <p>Newer BSD based systems have a ``<tt/-b/'' option to split that
- allows them to split files on arbitrary byte boundaries.
+ <p>在以 BSD 為主的較新系統中,split 有個 ``<tt/-b/'' 選項,是用來
+ 把檔案以任意數目 byte 切開。
- <p>Here is an example from <tt>/usr/src/Makefile</tt>.
+ <p>這裡是 <tt>/usr/src/Makefile</tt> 中的一個例子:
@@ -160,166 +144,130 @@
- <heading>I've written a kernel extension, who do I send it to?</heading>
+ <heading>我在 kernel 裡加了些新功能,要把它寄給誰?</heading>
- <p>Please take a look at <url url="../../handbook/contrib.html"
- name="The Handbook entry on how to submit code.">
+ <p>請看一下 <url url="../handbook/contrib.html"
+ name="Handbook 中加入程式碼的部份">。
- <p>And thanks for the thought!
+ <p>同時也感謝你的費心!
- <heading>How are Plug N Play ISA cards detected and initialized?</heading>
- <p>By: <url url="mailto:uhclem@nemesis.lonestar.org"
- name="Frank Durda IV">
- <p>In a nutshell, there a few I/O ports that all of the PnP boards
- respond to when the host asks if anyone is out there. So when
- the PnP probe routine starts, he asks if there are any PnP boards
- present, and all the PnP boards respond with their model &num; to
- a I/O read of the same port, so the probe routine gets a wired-OR
- ``yes'' to that question. At least one bit will be on in that
- reply. Then the probe code is able to cause boards with board
- model IDs (assigned by Microsoft/Intel) lower than X to go
- ``off-line''. It then looks to see if any boards are still
- responding to the query. If the answer was ``<tt/0/'', then
- there are no boards with IDs above X. Now probe asks if there
- are any boards below ``X''. If so, probe knows there are boards
- with a model numbers below X. Probe then asks for boards greater
- than X-(limit/4) to go off-line. If repeats the query. By
- repeating this semi-binary search of IDs-in-range enough times,
- the probing code will eventually identify all PnP boards present
- in a given machine with a number of iterations that is much lower
- than what 2^64 would take.
- <p>The IDs are two 32-bit fields (hence 2&circ;64) + 8 bit checksum.
- The first 32 bits are a vendor identifier. They never come out
- and say it, but it appears to be assumed that different types of
- boards from the same vendor could have different 32-bit vendor
- ids. The idea of needing 32 bits just for unique manufacturers
- is a bit excessive.
- <p>The lower 32 bits are a serial &num;, ethernet address, something
- that makes this one board unique. The vendor must never produce
- a second board that has the same lower 32 bits unless the upper
- 32 bits are also different. So you can have multiple boards of
- the same type in the machine and the full 64 bits will still be
- unique.
- <p>The 32 bit groups can never be all zero. This allows the
- wired-OR to show non-zero bits during the initial binary search.
- <p>Once the system has identified all the board IDs present, it will
- reactivate each board, one at a time (via the same I/O ports),
- and find out what resources the given board needs, what interrupt
- choices are available, etc. A scan is made over all the boards
- to collect this information.
- <p>This info is then combined with info from any ECU files on the
- hard disk or wired into the MLB BIOS. The ECU and BIOS PnP
- support for hardware on the MLB is usually synthetic, and the
- peripherals don't really do genuine PnP. However by examining
- the BIOS info plus the ECU info, the probe routines can cause the
- devices that are PnP to avoid those devices the probe code cannot
- relocate.
- <p>Then the PnP devices are visited once more and given their I/O,
- DMA, IRQ and Memory-map address assignments. The devices will
- then appear at those locations and remain there until the next
- reboot, although there is nothing that says you can't move them
- around whenever you want.
- <p>There is a lot of oversimplification above, but you should get
- the general idea.
- <p>Microsoft took over some of the primary printer status ports to
- do PnP, on the logic that no boards decoded those addresses for
- the opposing I/O cycles. I found a genuine IBM printer board
- that did decode writes of the status port during the early PnP
- proposal review period, but MS said ``tough''. So they do a
- write to the printer status port for setting addresses, plus that
- use that address + <tt/0x800/, and a third I/O port for reading
- that can be located anywhere between <tt/0x200/ and <tt/0x3ff/.
+ <heading>ISA 的 Plug N Play 卡是怎麼偵測和初始化的?</heading>
+ <p>由 <url url="mailto:uhclem@nemesis.lonestar.org"
+ name="Frank Durda IV"> 所寫:
+ <p>簡單的說,當主機發出是否有 PnP 卡的詢問訊號時,所有的 PnP
+ 會在幾個固定的 I/O port 作回應。所以當偵測 PnP 的程式開始時,它
+ 會先問有沒有 PnP 卡在,接著所有 PnP 卡會在它所讀的 port 以自己
+ 的型號 &num; 作回答,這樣偵測程式就會得到一個 wired-OR ``yes''
+ 的數字,其中至少會有一個 bit 是打開的。然後偵測程式會要求型號
+ (由 Microsoft/Intel指定)小於 X 的卡``離線'',再去看是否還有卡回
+ 答同樣的詢問,如果得到 ``<tt/0/'',就表示沒有型號大於 X 的卡。
+ 現在程式會問是否有型號小於 X 的卡,如果有的話,程式再要型號大於
+ X-(limit/4) 的卡離線,然後重覆上面的動作。用這種類似 binary
+ search 的方法,在某範圍內找個幾次後,偵測程式最後會在機器中區分
+ 出所有的 PnP 卡,搜尋次數也遠低於一個個找的 2^64 次。
+ <p>一張卡的 ID 由兩個 32-bit(所以上面是 2&circ;64) + 8bit 偵錯
+ 碼組成,第一個 32 bits 是用來區分各家廠商的。這些廠商沒有出來澄
+ 清過,但看來應假設同一家出的不同種類的卡的廠商 ID 有可能不同。
+ 用 32 bits 只來表示不同廠商的想法實在有點過頭了。
+ <p>第二個 32 bits 則是型號 &num、乙太網路位址、或一些使這張卡獨
+ 特的資料。除非第一個 32 bits 不同,否則廠商不可能作出第二個 32
+ bit 相同的兩張卡。所以在一台機器中可以有同樣的好幾張卡,然而他們
+ 整個 64 bits 還是會都不一樣。
+ <p>這兩個 32 bit 永遠都不可能為零,這使得最開始 binary search 中
+ 的 wired-OR 會得到一個非零數字。
+ <p>一旦系統區分出所有卡的 ID,接著會經由同樣的 port 一個個重新啟
+ 動每張卡,接著找出已知介面卡所需的資源、有那些可以選的 interrupt
+ 等等。所有卡都會被掃描一次,來收集這些資料。
+ <p>這些資訊接著和硬碟上的 ECU 檔案、或 MLB BIOS 裡的資料結合在一
+ 起,通常是綜合 ECU 和 MLB 裡的 BIOS PnP 資料,這些週邊並不支援真
+ 正的 PnP,然而偵測程式在檢查 BIOS 和 ECU 資料後,它可以避免 PnP
+ 週邊和那些偵測不到的相衝突。
+ <p>接著再度拜訪這些 PnP 週邊,這次會把可用的 I/O、DMA、IRQ 和記
+ 憶體映射的位址都指定給它們。這些週邊就會出現在所指定的地方,直到
+ 下一次重新開機為止,不過也沒有人說不能把它們隨時移來移去。
+ <p>上面有相當多的簡化,但你應該已經了解大致的過程。
+ <p>Microsoft 把表示印表機狀態的幾個主要 port 拿來作 PnP,他們的
+ 邏輯是沒有一張卡會在這些地方解碼作相反的 I/O cycles。但是我找到
+ 一款早期仍在評估 PnP 提案時的 IBM 原廠 printer board,它的確去解
+ 對這些狀態 port 的寫入資料,但是 MS ``說了就算''。所以它們的確有
+ 對印表機狀態 port 寫入,還有讀取該位址 + <tt/0x800/、和另一個在
+ <tt/0x200/ 及 <tt/0x3ff/ 之間的 port。
- <heading>Does FreeBSD support architectures other than the x86?</heading>
+ <heading>FreeBSD 是否有支援 x86 以外的機器架構?</heading>
- <p>Several groups of people have expressed interest in working on
- multi-architecture ports for FreeBSD and the FreeBSD/AXP (ALPHA)
- port is one such effort which has been quite successful, now
- available in 3.0 SNAPshot release form at <url
+ <p>有幾群人士已經表示對發展多平台 FreeBSD 的興趣,其中
+ FreeBSD/AXP (ALPHA) 即是其中相當成功的例子,可以在 <url
- name="ftp://ftp.freebsd.org/pub/FreeBSD/alpha">. The ALPHA
- port currently runs on a growing number of ALPHA machine
- types, among them the AlphaStation, AXPpci, PC164, Miata and Multia
- models. This port is not yet considered a full release and won't be
- until a full compliment of system installation tools and a distribution
- on CDROM installation media is available, including a reasonable
- number of working ports and packages.
- FreeBSD/AXP should be considered BETA quality software at this
- time. For status information, please join the
+ name="ftp://ftp.freebsd.org/pub/FreeBSD/alpha"> 這裡取得它的
+ 3.0 SNAPshot 版本。ALPHA 版的 FreeBSD 在越來越多的 ALPHA 機器上
+ 使用,其中包括了 AlphaStation、AXPpci、PC164、Miata 和 Multia
+ 這幾種。要等到系統安裝工具完全、能用光碟安裝、以及有足夠能用的
+ port/package 之後,我們才打算把它當作完整的版本,所以現在應該把
+ FreeBSD/AXP 當作 BETA 品質的軟體。若要相關狀況的消息,請加入
<tt>&lt;freebsd-alpha@FreeBSD.ORG&gt;</tt><ref id="mailing"
name="mailing list">.
- Interest has also been expressed in a port of FreeBSD to
- the SPARC architecture, join the <tt>&lt;freebsd-sparc@FreeBSD.ORG&gt;
- </tt><ref id="mailing" name="mailing list"> if you are interested
- in joining that project. For general discussion on new architectures,
- join the <tt>&lt;freebsd-platforms@FreeBSD.ORG&gt;</tt>
- <ref id="mailing" name="mailing list">.
+ 也有人表示過將 FreeBSD SPARC 版本的興趣,如果你想參加這個計畫,
+ 請加入 <tt>&lt;freebsd-sparc@FreeBSD.ORG&gt;
+ </tt><ref id="mailing" name="mailing list">。如果想要知道關於
+ 新平台的討論,請加入 <tt>&lt;freebsd-platforms@FreeBSD.ORG&gt;</tt>
+ <ref id="mailing" name="mailing list">。
- <heading>I need a major number for a device driver I've written.</heading>
- <p>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
- <tt>files.i386</tt>, a sample configuration file entry, and the
- appropriate <htmlurl url="http://www.freebsd.org/cgi/man.cgi?MAKEDEV"
- name="MAKEDEV"> code to create any special files your device uses. If
- you do not, or are unable to because of licensing restrictions, then
- character major number 32 and block major number 8 have been reserved
- specifically for this purpose; please use them. In any case, we'd
- appreciate hearing about your driver on
- <tt>&lt;freebsd-hackers@FreeBSD.ORG&gt;</tt>.
+ <heading>我剛剛寫了某個設備的驅動程式,能不能給它一個 major number?
+ </heading>
+ <p>這要看你是否打算將這個驅動程式公開使用,如果是的話,請把它的原始
+ 碼送一份給我們,還有 <tt>files.i386</tt> 修改的部份、kernel 設定
+ 檔樣本、以及用來產生設備檔的 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?MAKEDEV" name="MAKEDEV">。
+ 如果你不打算、或因為版權問題而不能公開的話,我們有特地保留
+ character major number 32 和 block major number 8 給這方面的使用,
+ 直接用這兩個就好了。不論如何,我們都會很感激你能在
+ <tt>&lt;freebsd-hackers@FreeBSD.ORG&gt;</tt> 發表驅動程式的消息。
- <heading>Alternative layout policies for directories</heading>
- <p>
- In answer to the question of alternative layout policies for
- directories, the scheme that is currently in use is unchanged
- from what I wrote in 1983. I wrote that policy for the original
- fast filesystem, and never revisited it. It works well at keeping
- cylinder groups from filling up. As several of you have noted,
- it works poorly for find. Most filesystems are created from
- archives that were created by a depth first search (aka ftw).
- These directories end up being striped across the cylinder groups
- thus creating a worst possible senario for future depth first
- searches. If one knew the total number of directories to be
- created, the solution would be to create (total / fs_ncg) per
- cylinder group before moving on. Obviously, one would have to
- create some heuristic to guess at this number. Even using a
- small fixed number like say 10 would make an order of magnitude
- improvement. To differentiate restores from normal operation
- (when the current algorithm is probably more sensible), you
- could use the clustering of up to 10 if they were all done
- within a ten second window. Anyway, my conclusion is that this
- is an area ripe for experimentation.</p>
+ <heading>關於放置目錄和檔案 inode 作法上的相異</heading>
+ <p>在回答有關目錄放置方式不同的問題上,我在 1983 年寫好目前的作法
+ 後就沒有再改變過,這種方式是針對原先的 FFS 檔案系統,後來也沒
+ 有對它作任何更動。它在避免 cylinder group 被填滿這方面做得相當
+ 成功,但是就像有些人已經注意到,它和 `find' 就配合得不大好。大
+ 部份的檔案系統是由那些用 depth first search(aka ftw) 產生的
+ archive 製造出來,解出來的目錄 inode 會橫跨好幾個 cylinder
+ group,如果以後要做 depth first search 的話,這是最糟糕的情況之
+ 一。如果我們知道總共會產生多少目錄的話,解法是在做任何存取/寫
+ 入動作之前,在每個 cylinder group 上先造出(所有目錄數/cylinder
+ greoup 的數目)這麼多的目錄。很明顯的,我們必須要有根據地去猜這
+ 個數字,就算一個像 10 的很小固定數目也會使效率以級數成長。區分
+ restore (即解開上述的 archive) 和一般檔案操作的方法可以是(現在
+ 用的演算法可能要更敏感):如果一些目錄(最多 10 個)都在 10 秒內產
+ 生的話,那麼就把這些目錄聚集在同一個 cylinder group。不管怎樣,
+ 我的經驗指出這是一個已經充份實驗過的部份。</p>
<p>Kirk McKusick, September 1998</p>
- <heading>Making the most of a kernel panic</heading>
+ <heading>如何從 kernel panic 得到最多資訊?</heading>
- <em>[This section was extracted from a mail written by <url
- url="mailto:wpaul@FreeBSD.ORG" name="Bill Paul"> on the
- freebsd-current <ref id="mailing" name="mailing list"> by <url
- url="mailto:des@FreeBSD.ORG" name="Dag-Erling Co&iuml;dan
- Sm&oslash;rgrav">, who fixed a few typos and added the bracketed
- comments]</em>
+ <em>[這節是從 <url url="mailto:wpaul@FreeBSD.ORG" name="Bill Paul">
+ 在 freebsd-current <ref id="mailing" name="mailing list"> 上發表
+ 的信中節錄,<url url="mailto:des@FreeBSD.ORG"
+ name="Dag-Erling Co&iuml;dan Sm&oslash;rgrav"> 修正了打字錯誤、再
+ 加上括弧裡的注解。]</em>
@@ -331,8 +279,7 @@ Cc: current@FreeBSD.ORG
- <em>[&lt;ben@rosengart.com&gt; posted the following panic
- message]</em>
+ <em>[&lt;ben@rosengart.com&gt; 發表了下面的 panic 訊息]</em>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x40
@@ -350,112 +297,93 @@ Cc: current@FreeBSD.ORG
> panic: page fault
- <p> [When] you see a message like this, it's not enough to just
- reproduce it and send it in. The instruction pointer value that
- I highlighted up there is important; unfortunately, it's also
- configuration dependent. In other words, the value varies
- depending on the exact kernel image that you're using. If you're
- using a GENERIC kernel image from one of the snapshots, then
- it's possible for somebody else to track down the offending
- function, but if you're running a custom kernel then only
- <em/you/ can tell us where the fault occured.
- <p> What you should do is this:
+ <p>當你看到像這樣的訊息時,只把它拷一份送上來是不夠的。我在上
+ 面特地標明的 instruction pointer 值相當重要,不幸的是它會因設
+ 定而不同。換句話說,這個值會跟你用的 kernel image 檔而變動。如
+ 果是用某個 snapshot 版本的 GENERIC kernel,也許其他人可以追蹤
+ 到出問題的函式,但如果你是用自訂的 kernel,那麼只有<em/你/才能
+ 告訴我們問題出在那裡。
+ <p>要做的事包括這些:
- <item>Write down the instruction pointer value. Note that the
- <tt/0x8:/ part at the begining is not significant in this case:
- it's the <tt/0xf0xxxxxx/ part that we want.
- <item>When the system reboots, do the following:
+ <item>把 instruction pointer 的值記下來。注意在前面的 <tt/0x8:/
+ 在這個情況中並不重要,我們要的是 <tt/0xf0xxxxxx/。
+ <item>當系統重新開機後,執行這道命令:
-% nm /kernel.that.caused.the.panic | grep f0xxxxxx
+% nm /(造成 panic 的 kernel 檔案) | grep f0xxxxxx
- where <tt/f0xxxxxx/ is the instruction pointer value. The
- odds are you will not get an exact match since the symbols
- in the kernel symbol table are for the entry points of
- functions and the instruction pointer address will be
- somewhere inside a function, not at the start. If you don't
- get an exact match, omit the last digit from the instruction
- pointer value and try again, i.e.:
+ 其中 <tt/f0xxxxxx/ 就是記下來的 instruction pointer 值。有可能
+ 不會剛好找到完整的這個字串,這是因為 kernel symbol table 裡的各
+ 個 symbol 只是函式的進入點,但 instruction pointer 所指的位址有
+ 可能是在函式內的某一處,而不一定在開頭。所以如果找不到整個字串,
+ 那麼把 instruction pointer 值的最後一個數字拿掉,再試一次:
% nm /kernel.that.caused.the.panic | grep f0xxxxx
- If that doesn't yield any results, chop off another digit.
- Repeat until you get some sort of output. The result will be
- a possible list of functions which caused the panic. This is
- a less than exact mechanism for tracking down the point of
- failure, but it's better than nothing.
+ 如果這樣也找不到,那就把另一個數字去掉再找,一直重複到找到為止,
+ 結果是一串可能造成 panic 的函式列表。這樣比直接找到出問題的函式
+ 來得差,但至少好過什麼都沒有。
- <p> I see people constantly show panic messages like this but
- rarely do I see someone take the time to match up the
- instruction pointer with a function in the kernel symbol table.
+ <p>我常常看到人們顯示一大片 panic 訊息,但很少看到有人花一點時間
+ 把 instruction pointer 和 kernel symbol table 中的函式比較一下。
- <p> The best way to track down the cause of a panic is by
- capturing a crash dump, then using <tt/gdb(1)/ to to a stack
- trace on the crash dump. Of course, this depends on <tt/gdb(1)/
- in -current working correctly, which I can't guarantee (I recall
- somebody saying that the new ELF-ized <tt/gdb(1)/ didn't handle
- kernel crash dumps correctly: somebody should check this before
- 3.0 goes out of beta or there'll be a lot of red faces after the
- CDs ship).
+ <p>要追蹤出造成 panic 原因的最好方法是先做出 crash dump,然後用
+ <tt/gdb(1)/ 在上面做 stack trace。當然,這要靠 -current 中的
+ <tt/gdb(1)/ 能運作正常,然而我無法保證這一點。(記得有人說 ELF 的
+ <tt/gdb(1)/ 在 kernel 的 crash dump 上不能正常操作,在 3.0 脫離
+ BETA 階段時最好有人先檢查這方面的狀況,免得很多人在收到 3.0 光碟
+ 後脹紅了臉。)
- In any case, the method I normally use is this:
+ 不管是那一種,我通常是用這個方法:
- <item>Set up a kernel config file, optionally adding 'options DDB' if you
- think you need the kernel debugger for something. (I use this mainly
- for setting beakpoints if I suspect an infinite loop condition of
- some kind.)
- <item>Use <tt/config -g KERNELCONFIG/ to set up the build directory.
+ <item>寫好 kernel 設定檔。如果你需要用 kernel debugger,在設定
+ 檔中加上 `options DDB' 這個選項。(當我懷疑有出現無窮迴圈時,通
+ 常會用這個來設定中斷點。)
+ <item>用 <tt/config -g KERNELCONFIG/ 做出用來編譯的目錄
<item><tt>cd /sys/compile/KERNELCONFIG; make</tt>
- <item>Wait for kernel to finish compiling.
+ <item>等 kernel 編譯出來
<item><tt/cp kernel kernel.debug/
<item><tt/strip -d kernel/
<item><tt/mv /kernel /kernel.orig/
<item><tt>cp kernel /</tt>
- <item>reboot
+ <item>重新開機
- <p> <em>[Note: Now that FreeBSD 3.x kernels are Elf by default,
- you should use <tt/strip -g/ instead of <tt/strip -d/. If for some
- reason your kernel is still a.out, use <tt/strip -aout -d/.]</em>
- WITH ALL THE DEBUG SYMBOLS IN IT. A kernel compiled with <tt/-g/
- can easily be close to 10MB in size. You don't have to actually
- boot this massive image: you only need it later for <tt/gdb(1)/
- (<tt/gdb(1)/ wants the symbol table). Instead, you want to keep
- a copy of the full image and create a second image with the
- debug symbols stripped out using <tt/strip -d/. It is this
- second stripped image that you want to boot.
- <p> To make sure you capture a crash dump, you need edit
- <tt>/etc/rc.conf</tt> and set <tt/dumpdev/ to point to your swap
- partition. This will cause the <tt/rc(8)/ scripts to use the
- <tt/dumpon(8)/ command to enable crash dumps. You can also run
- <tt/dumpon(8)/ manually. After a panic, the crash dump can be
- recovered using <tt/savecore(8)/; if <tt/dumpdev/ is set in
- <tt>/etc/rc.conf</tt>, the <tt/rc(8)/ scripts will run
- <tt/savecore(8)/ automatically and put the crash dump in
- <tt>/var/crash</tt>.
- <p> NOTE: FreeBSD crash dumps are usually the same size as the
- physical RAM size of your machine. That is, if you have 64MB of
- RAM, you will get a 64MB crash dump. Therefore you must make sure
- there's enough space in <tt>/var/crash</tt> to hold the dump.
- Alternatively, you run <tt/savecore(8)/ manually and have it
- recover the crash dump to another directory where you have more
- room. It's possible to limit the size of the crash dump by using
- <tt/options MAXMEM=(foo)/ to set the amount of memory the kernel
- will use to something a little more sensible. For example, if
- you have 128MB of RAM, you can limit the kernel's memory usage
- to 16MB so that your crash dump size will be 16MB instead of
- 128MB.
- <p> Once you have recovered the crash dump, you can get a stack
- trace with <tt/gdb(1)/ as follows:
+ <p> <em>[注意:現在 FreeBSD 3.x kernel 內定是 ELF 格式,所以應該
+ 用 <tt/strip -g/ 而不是 <tt/strip -d/。如果你的 kernel 因某種原
+ 因仍是 a.out 格式的話,則用 <tt/strip -aout -d/。]</em>
+ <p>注意你<em/不會/真的用包括所有 debug symbol 的 kernel 來開機,
+ 用 <tt/-g/ 編譯出來的 kernel 大小很容易就超過 10MB。不需要用這麼
+ 大的 kernel 開機,晚一點 <tt/gdb(1)/ 才會需要它(<tt/gdb(1)/ 會用
+ 到裡面的 symbol table)。所以我們才會把完整的 kernel 複製一份,接
+ 著用 <tt/strip -d/ 刪掉 debug symbol,做出第二個 kernel,這個才真
+ 正拿來開機。
+ <p>要確定能抓到 crash dump,先編輯 <tt>/etc/rc.conf</tt>,將
+ <tt/dumpdev/ 指到 swap 分割區。這樣 <tt/rc(8)/ 會用 <tt/dumpon(8)/
+ 來啟動 crash dump,你也可以手動用 <tt/dumpon(8)/。在 panic 之後,
+ crash dump 可以用 <tt/savecore(8)/ 存起來;如果 <tt>/etc/rc.conf</tt>
+ 裡有設 <tt/dumpdev/,那麼重新開機後 <tt/rc(8)/ 會自動執行
+ <tt/savecore(8)/ 把 crash dump 存在 <tt>/var/crash</tt>。
+ <p>注意:FreeBSD 的 crash dump 通常和機器裡的實際記憶體一樣大,
+ 就像如果有 64MB 記憶體,crash dump 大小就是 64MB。所以要確定
+ <tt>/var/crash</tt> 下有足夠的空間,或是可以手動執行 <tt/savecore(8)/
+ 把 crash dump 放到另一個空間較夠的目錄下。另一種也許可以限制 crash
+ dump 的方法,是在 kernel 設定檔中用 <tt/options MAXMEM=(foo)/,
+ 將 kernel 可用的記憶體限制在合理的大小。舉例來說,如果你有 128MB
+ 的記憶體,但是可以限制 kernel 只能用 16MB 的記憶體,這樣 crash
+ dump 就是 16MB 而不是 128MB 了。
+ <p>一旦發現有了 crash dump,就可以用 <tt/gdb(1)/ 來做 stack trace
+ ,如下所示:
@@ -463,30 +391,94 @@ Cc: current@FreeBSD.ORG
(gdb) where
- <p> Note that there may be several screens worth of information;
- ideally you should use <tt/script(1)/ to capture all of them.
- Using the unstripped kernel image with all the debug symbols
- should show the exact line of kernel source code where the panic
- occured. Usually you have to read the stack trace from the
- bottom up in order to trace the exact sequence of events that
- lead to the crash. You can also use <tt/gdb(1)/ to print out the
- contents of various variables or structures in order to examine
- the system state at the time of the crash.
- <p> Now, if you're really insane and have a second computer, you
- can also configure <tt/gdb(1)/ to do remote debugging such that
- you can use <tt/gdb(1)/ on one system to debug the kernel on
- another system, including setting breakpoints, single-stepping
- through the kernel code, just like you can do with a normal
- user-mode program. I haven't played with this yet as I don't
- often have the chance to set up two machines side by side for
- debugging purposes.
- <p> <em>[Bill adds: "I forgot to mention one thing: if you have
- DDB enabled and the kernel drops into the debugger, you can
- force a panic (and a crash dump) just by typing 'panic' at the
- ddb prompt. It may stop in the debugger again during the panic
- phase. If it does, type 'continue' and it will finish the crash
- dump." -ed]</em>
+ <p>要注意可能會出現好幾個螢幕的可用資訊,你可以用 <tt/script(1)/
+ 把所有輸出都存起來。用包括所有 debug symbol 的 kernel 來除錯,
+ 這樣應該可以直接顯示 panic 是發生在那一行。通常是由下往上讀 stack
+ strace,這樣才能一個個追蹤出有那些動作引到 crash。也可以用
+ <tt/gdb(1)/ 把各種變數或結構的內容印出來,以檢查系統 crash 時的
+ 實際狀態。
+ <p>好啦,如果你有第二台電腦而且有夠瘋狂,可以將 <tt/gdb(1)/ 設定
+ 成遠端除錯。這樣你可以在一台機器中用 <tt/gdb(1)/ 去除錯另一台裡的
+ kernel,可以執行的包括設定中斷點、在 kernel 原始碼中一步步執行等
+ 等,就像在一般使用者程式上除錯一樣。由於沒有什麼機會為除錯而設置
+ 兩台並鄰電腦,所以我還沒有這樣玩過。
+ <p><em>[Bill 附注:我忘了提到一點:如果你有啟動 DDB 而 kernel 也
+ 已經進入除錯器,可以在 DDB 命令列下打 `panic',強迫產生 panic(還
+ 有 crash dump)。也有可能在 panic 階段時再進入除錯器,如果這樣的話
+ ,輸入 `continue',接著它就會完成 crash dump。 -ed]</em>
+ <sect1>
+ <heading>dlsym() 對 ELF 執行檔不能用!</heading>
+ <p>在 ELF 一系列的工具中,內定是不會讓 dynamic linker 看到執行檔
+ 裡定義了那些 symbol。所以 <tt>dlsym()</tt> 沒有辦法用藉由呼叫
+ <tt>dlopen(NULL, flags)</tt> 取得的 handle,用它去搜尋有那些
+ symbol 一定會失敗。
+ <p>如果你想要用 <tt>dlsym()</tt> 找出某個 process 的主執行檔中
+ 有那些 symbol,則要在 link 時對
+ <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ld"
+ name="ELF linker"> 加上 <tt>-export-dynamic</tt> 這個參數。
+ <sect1>
+ <heading>增加或減少 kernel 能定址的空間</heading>
+ <p>系統的內定是,FreeBSD 3.x kernel 能定址到 256 MB,4.x 則是
+ 1 GB。如果是網路負荷相當重的伺服器(就像大型 FTP 或 HTTP 伺服器),
+ 256 MB 可能會不大夠。
+ <p>要怎麼增加定址空間呢? 要從兩方面著手。首先告訴 kernel 本身要
+ 保留較大空間; 其次,既然是在定址空間的最上面載入 kernel,所以還
+ 要調低載入的位址,否則就會超過定址範圍。
+ <p>增加 <tt>src/sys/i386/include/pmap.h</tt> 裡的 <tt/NKPDE/ 值
+ 便可達成第一個目標。1 GB 的定址空間會像這樣:
+ <verb>
+#ifndef NKPDE
+#ifdef SMP
+#define NKPDE 254 /* addressable number of page tables/pde's */
+#define NKPDE 255 /* addressable number of page tables/pde's */
+#endif /* SMP */
+ </verb>
+ <p>要算出 <tt/NKPDE/ 的正確值,將想要的空間大小(以 megabyte 為單
+ 位)除以 4,接著單 CPU 機器減 1,雙 CPU 則是減 2。
+ <p>要解決第二個問題,必須自行算出 kernel 被載入的位址:求出
+ 0x100100000 減掉定址空間大小的值(以 byte 為單位),如 1 GB 大小就
+ 是 0xc0100000。把 <tt>src/sys/i386/conf/Makefile.i386</tt> 裡的
+ <tt/LOAD_ADDRESS/ 設成這個值,接著將 section 列表最前面的
+ location counter 設成相同的值(譯注:在
+ <tt>src/sys/i386/conf/kernel.script</tt> 中),如下:
+ <verb>
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
+ /* Read-only sections, merged into text segment: */
+ . = 0xc0100000 + SIZEOF_HEADERS;
+ .interp : { *(.interp) }
+ </verb>
+ <p>然後重新 config 和做出新的 kernel。在執行像 <tt/ps(1)/、
+ <tt/top(1)/ 這類程式時可能會碰到問題,做一次 <tt/make world/
+ 應該就可以解決(或把改過的 <tt/pmap.h/ 拷到 <tt>/usr/include/vm/</tt>
+ 下,再手動編譯 <tt/libkvm/、<tt/ps/ 和 <tt/top/)。
+ <p>注意:kernel 所能定址的空間大小必須是 4 megabytes 的倍數。
+ <p><em>[<url url="mailto:dg@freebsd.org" name="David Greenman">
+ 加上這一段:我認為 kernel 定址空間大小應該是 2 的乘冪,但不大確
+ 定這一點。舊的啟動程式會動到 high order address bits,記得它假設
+ 至少有 256 MB。]</em>
diff --git a/zh/FAQ/network.sgml b/zh/FAQ/network.sgml
index 040ce418a5..3c551d4368 100644
--- a/zh/FAQ/network.sgml
+++ b/zh/FAQ/network.sgml
@@ -1,17 +1,17 @@
-<!-- $Id: network.sgml,v 1.3 1999-03-21 16:25:41 wosch Exp $ -->
+<!-- $Id: network.sgml,v 1.4 1999-04-21 05:26:08 foxfair Exp $ -->
<!-- The FreeBSD Documentation Project -->
-<!-- Translate into Chinese by wing@cc.nsysu.edu.tw -->
+<!-- Translate into Chinese by wing@cc.nsysu.edu.tw, jtjang@gcn.net.tw -->
<!-- English Version: 1.20 -->
- <heading>Networking<label id="networking"></heading>
+ <heading>網路設定<label id="networking"></heading>
<heading>我應該到哪邊找有關無磁碟開機 (diskless booting) 的資料?</heading>
<p>無磁碟開機就是讓 FreeBSD 主機從網路上開機,並且從網路上的 server 上讀取
其他必要的檔案,而非由主機的硬碟上取得這些檔案。 詳細的資料可以參考
- <url url="../../handbook/diskless.html"
+ <url url="../handbook/diskless.html"
name="FreeBSD 手冊的無磁碟開機篇">
@@ -92,19 +92,19 @@
name="slattach"> 處理有關撥出的功能。
- <url url="../../handbook/handbook.html" name="handbook">中找到:
+ <url url="../handbook/handbook.html" name="handbook">中找到:
- <item><url url="../../handbook/slips.html"
+ <item><url url="../handbook/slips.html"
name="SLIP (server 端) 的說明">
- <item><url url="../../handbook/slipc.html"
+ <item><url url="../handbook/slipc.html"
name="SLIP (client 端) 的說明">
- <item><url url="../../handbook/ppp.html"
+ <item><url url="../handbook/ppp.html"
name="PPP (kernel 模式) 的說明">
- <item><url url="../../handbook/userppp.html"
+ <item><url url="../handbook/userppp.html"
name="PPP (使用者模式) 的說明">
@@ -139,8 +139,8 @@
<p>你應該先看看 <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> 和
- <url url="../../handbook/userppp.html"
- name="ppp 使用說明">. 使用以下指令來打開記錄 (logging) 的功能
+ <url url="../handbook/userppp.html"
+ name="ppp 使用說明">。使用以下指令來打開記錄 (logging) 的功能
set log Phase Chat Connect Carrier lcp ipcp ccp command
@@ -200,43 +200,42 @@ default UGSc 0 0 tun0 UH 0 0 tun0
- <p>這些設定是假設您使用的 address 跟 handbook 裡面的設定,
- 或是與 man page 的範例抑或是 ppp.conf.sample 這個檔案裡的設定相同.
- 如果您沒有設定 default route, 那麼有可能您現在使用舊版本的
- <htmlurl
- url="http://www.freebsd.org/cgi/man.cgi?ppp"
- name="ppp"> that doesn't understand the
- word <tt/HISADDR/ in the ppp.conf file. 如果您的系統
- <bf/ppp/ 是在 FreeBSD 2.2.5 之前的話, 修改
+ <p>這些設定是假設您使用的 address 跟 handbook 裡面的、或是 man
+ page 的範例、或者和 ppp.conf.sample 裡的設定相同。如果您沒有設定
+ default route,那麼有可能您現在使用舊版本的 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">,舊的
+ ppp 會看不懂 ppp.conf 裡的 <tt/HISADDR/。如果您的系統 <bf/ppp/
+ 是在 FreeBSD 2.2.5 之前的話, 修改這一行
add 0 0 HISADDR
- <p>這一行成為
+ <p>成為
add 0 0
- <p>default route 這行沒有出現的另一個原因是
- 你設錯了 default router , 這個設定在
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
- name="/etc/rc.conf"> 檔案中 (這個檔案在 release 2.2.2 前叫
- <tt>/etc/sysconfig</tt> ), 你需要加入這麼一行
+ <p>default route 這行沒有出現的另一個原因是你設錯了 default
+ router,這個設定在 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
+ name="/etc/rc.conf"> 檔案中(這個檔案在 release 2.2.2 前叫
+ <tt>/etc/sysconfig</tt>),你需要在 <tt>ppp.conf</tt> 中加入這
+ 麼一行
delete ALL
- <p>在 <tt>ppp.conf</tt>中. 如果發生這種情形, 回到 handbook
- <url url="../../handbook/userppp:final.html"
- name="Final system configuration"> 的說明中查詢.
+ <p>如果發生這種情形, 回到 handbook <url
+ url="../handbook/userppp:final.html" name="userppp 最後設定">
+ 的說明中查詢。
<heading>什麼叫做 "No route to host"</heading>
- <p>This error is usually due to a missin這個狀況通常是因為缺少了這段設定
+ <p>這個狀況通常是因為缺少了這段設定
@@ -244,274 +243,295 @@ default UGSc 0 0 tun0
add 0 0 HISADDR
- <p>請檢查您的 <tt>/etc/ppp/ppp.linkup</tt> 檔案中是否有這些設定. 只有在您
- 使用動態 IP (dynamic IP) 或不知道您 gateway 的 IP 時才需要設定這個.
- 如果您是使用互動模式(interactive mode) 的話, 您可以
- type the following after entering <tt/packet mode/ (packet mode is
- indicated by the capitalized <bf/PPP/ in the prompt):
+ <p>請檢查您的 <tt>/etc/ppp/ppp.linkup</tt> 檔案中是否有這些設定。
+ 只有在您使用動態 IP(dynamic IP) 或不知道您 gateway 的 IP 時才需要
+ 設定這個。如果您是使用 interactive mode 的話, 您可以在進入 packet
+ mode 後輸入如下命令(如果 ppp 提示符號變成大寫的 <bf/PPP/,便代表已
+ 經進入 packet mode):
delete ALL
add 0 0 HISADDR
- <p>您可以參考 handbook 中 <url url="../../handbook/userppp:dynamicIP.html"
- name="PPP and Dynamic IP addresses"> 有較詳盡的說明.
+ <p>您可以參考 handbook 中 <url url="../handbook/userppp:dynamicIP.html"
+ name="PPP 和動態 IP 位址"> 的部份,有較詳盡的說明。
- <heading>我的連線在等待三分鐘後切斷了</heading>
+ <heading>我的連線在三分鐘後自動斷掉了</heading>
- <p>ppp 預設的 timeout 值是三分鐘. 可以用以下這行命令調整
+ <p>ppp 預設的 timeout 值是三分鐘。可以用以下這行命令調整
set timeout NNN
- <p><bf/NNN/ 代表在沒有連線成功前等待幾秒才將連線關閉.
- 如果 <bf/NNN/ 設為 0, 那麼將不會因為 timeout 而關閉連線,會一直等待下去
- . 你可以把這行命令放到
- <tt>ppp.conf</tt> 這個檔案裡面, 或是在 interactive mode 裡面輸入這個指令.
- 也可以用 on the fly 的方式調整,在線路啟用並聯接到
- <bf/ppp/s 伺服器的線路時使用
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet">
- 或 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
- name="pppctl">. 參考
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man
- page 以獲得更詳盡的資料.
+ <p>這代表如果在 <bf/NNN/ 秒內網路都沒有動靜的話,ppp 就會自動關閉
+ 連線。如果 <bf/NNN/ 設成 0,那麼將不會因為沒有資料來往而關閉連線。
+ 你可以把這行命令放到 <tt>ppp.conf</tt> 這個檔案裡面,或是在
+ interactive mode 裡面輸入這個指令,也可以用 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet"> 或
+ <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
+ name="pppctl"> 連到 <bf/ppp/s 伺服器的 socket,在連線後隨時調整
+ timeout 的值。參考 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man page
+ 以獲得更詳盡的資料.
- <p>如果您設定了 Link Quality Reporting (LQR) , 就有可能
- 發生您和對方主機之間有太多的 LQR 封包遺失的現象.
- Ppp 會因此判斷電話線路有問題.
- , 並且決定切斷連線. 在 FreeBSD 2.2.5 版以前,
- LQR 內定值是 enabled . 現在的內定值是 disabled.
- LQR 可以用這一行命令取消
+ <p>如果您設定要用 Link Quality Reporting(LQR),您和對方主機之間就
+ 有可能遺失太多的 LQR 封包。Ppp 會因此判斷電話線路有問題,然後就會
+ 切斷連線。在 FreeBSD 2.2.5 版以前,內定會使用 LQR,現在的內定值是
+ 不用。LQR 可以用這一行命令取消
disable lqr
- <heading>我的連線會不定時的斷掉</heading>
+ <heading>ppp 會不定時的斷線</heading>
- <p>有時候如果線路上有太多噪訊,甚至如果您使用了話中插撥的服務的話.
- , 您的 modem 將或 hang 住,因為他誤認這些訊息是 lost carrier.
+ <p>有時候如果線路上有太多雜訊,甚至如果您使用了電話插撥服務的話,
+ 您的數據機將會掛斷電話,因為它誤認這些訊息是 lost carrier。
- <p>大部分的 modem 都有容忍暫時失去 carrier 的設定.
- . 以 USR Sportster 為例, this is measured by the S10 register in
- tenths of a second. 如果要讓您的 modem 能容忍更大的錯誤, 你可以在您的 dial string
- 裡面加入以下的 send-expect 命令:
+ <p>大部分的數據機都有容忍暫時失去 carrier 的設定。以 USR Sportster
+ 為例,失去 carrier 和掛斷電話之間的時間,是以 1/10 秒為單位存在
+ S10 暫存器中。如果要讓您的數據機能容忍更長的時間,你可以在 dial
+ string 裡面加入以下 "送出命令 - 等待字串" 的部份:
set dial "...... ATS10=10 OK ......"
- <p>參考您的 modem 內附的說明書以取得更詳細的資料.
+ <p>參考數據機內附的說明書以取得更詳細的資料。
+ <sect2>
+ <heading>連線會不定時當掉</heading>
+ <p>許多人的連線會毫無來由的卡住,首先要做的是找出連線那一方當掉。
+ <p>如果用的是外接數據機,就用 <tt/ping/ 來看在傳資料時,<tt/TD/ 燈號
+ 會不會閃。如果會的話(並且 <tt/RD/ 不會閃),代表是對方出問題;如果
+ 不會,則是自己的問題。如果用內接數據機,先在 <tt/ppp.conf/ 中加入
+ <tt/set server/ 這道指令,當連線當掉時,執行 pppctl 連到 ppp。如果網
+ 路連線突然好了(因為 ppp 看到用來診斷問題的 socket)或無法連上(假設
+ 在一開始可以執行 <tt/set socket/ 這道指令),表示本地出問題。如果連
+ 得上 ppp 卻仍然不能用,用 <tt/set log local async/ 打開本地的非同步
+ 記錄,接著在另一個視窗(或終端機)執行 <tt/ping/ 在連線上傳送資料。
+ 非同步記錄的功能會同時顯示送出和接收的資料,如果資料只出不進,就是對
+ 方機器出問題。
+ <p>知道是本地或對方出問題後,就有兩種可能:
+ <sect3>
+ <heading>對方的機器沒有回應</heading>
+ <p>在這方面能作的相當有限,大部份的 ISP 會因為你不是用 Microsoft
+ 作業系統而不願幫忙。可以在 <tt/ppp.conf/ 中加入 <tt/enable lqr/,
+ 允許 ppp 偵測對方的錯誤而掛斷,但這個過程相當慢,所以不大實用。也
+ 許不想告訴 ISP 你是用 user-ppp 上線的....
+ <p>首先,用下面兩道命令關掉所有本地的壓縮功能:
+ <verb>
+ disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
+ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
+ </verb>
+ <p>然後重新連線,確定這樣不會有所不同。如果反而有進步或甚至將問題
+ 解決掉,就用試誤法來找出是那個設定造成的。這樣在聯絡 ISP 時就可以
+ 提供相當有用的資料(雖然會很容易看出你不是用 Microsoft 的產品)。
+ <p>在聯絡 ISP 之前,打開本地的非同步記錄功能,接著就等連線再度當掉,
+ 這可能會用到相當大的硬碟空間。最後從連接埠讀進的資料可能會相當有用,
+ 它通常是 ASCII 文字,甚至有可能會說明問題出在那裡(``Memory fault,
+ core dumped''?)。
+ <p>如果 ISP 願意協助的話,應該會在他們那一端也打開記錄功能,那麼在
+ 下次連線當掉時,就可以告訴你為何會出問題。很歡迎將詳細內容送到 <url
+ url="mailto:brian@Awfulhak.org" name="brian@Awfulhak.org">,甚至要
+ 求 ISP 直接向我連絡。
+ <sect3>
+ <heading>自己的 Ppp 當掉了</heading>
+ <p>這裡能做的最多就是重新編譯 ppp:在 Makefile 最後面加上
+ <tt/CFLAGS+=-g/ 和 <tt/STRIP=/,接著做
+ <tt/make clean &amp;&amp; make &amp;&amp; make install/。在 ppp 當
+ 掉時,先用 <tt/ps ajxww |fgrep ppp/ 找出 ppp 的 process id,然後執
+ 行 <tt/gdb ppp PID/。在 gdb 提示符號下,可以用 <tt/bt/ 找出 stack
+ trace。
+ <p>將結果送到 <url url="mailto:brian@Awfulhak.org"
+ name="brian@Awfulhak.org">.
<heading>在看到 Login OK! 的訊息以後就沒有反應了</heading>
- <p>在 FreeBSD 2.2.5 以前的版本上, 一但連線建立完成以後,
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
- name="ppp"> 會等對方的機器啟動 Line Control
- Protocol (LCP). 很多 ISP 不會自動啟動這個訊息交換,而是等
- 待 cleint 端啟動. 要強迫 <bf/ppp/ 主動啟動
- LCP, 請下這個命令:
+ <p>在 FreeBSD 2.2.5 以前的版本上,一旦連線建立完成以後,
+ <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
+ 會等對方的機器啟動 Line Control Protocol (LCP)。很多 ISP 不會自動
+ 啟動,而是等待由 client 端來啟動。要強迫 <bf/ppp/ 主動啟動 LCP,請
+ 執行這個命令:
set openmode active
- <p><bf/Note/: 通常如果兩邊都啟動訊息交換的話,通常不會造成任何副作用.
- , 所以 openmode 目前內定值是啟動的. 然而,
- 下一段將解釋在什麼狀況下這個設定 <bf/真的/ 會造成副作用.
+ <p><bf/Note/: 通常如果兩邊都啟動訊息交換的話,通常不會造成任何副作
+ 用,所以 openmode 目前內定是打開的。然而,下一段將解釋在什麼狀況下
+ 這樣設定 <bf/真的/ 會造成副作用。
<heading>我一直看到 magic being the same 的錯誤訊息</heading>
- <p>Occasionally, just after connecting, you may see messages in
- the log that say "magic is the same". Sometimes, these
- messages are harmless, and sometimes one side or the other
- exits. Most ppp implementations cannot survive this problem, and
- even if the link seems to come up, you'll see repeated configure
- requests and configure acknowledgements in the log file until
- ppp eventually gives up and closes the connection.
- <p>This normally happens on server machines with slow disks that
- are spawning a getty on the port, and executing ppp from a
- login script or program after login. I've also heard reports
- of it happening consistently when using slirp. The reason is
- that in the time taken between getty exiting and ppp starting, the
- client-side ppp starts sending Line Control Protocol (LCP)
- packets. Because ECHO is still switched on for the port on
- the server, the client ppp sees these packets "reflect" back.
- <p>One part of the LCP negotiation is to establish a magic number
- for each side of the link so that "reflections" can be detected.
- The protocol says that when the peer tries to negotiate
- the same magic number, a NAK should be sent and a new magic
- number should be chosen. During the period that the server
- port has ECHO turned on, the client ppp sends LCP packets,
- sees the same magic in the reflected packet and NAKs it. It
- also sees the NAK reflect (which also means ppp must change
- its magic). This produces a potentially enormous number of
- magic number changes, all of which are happily piling into
- the server's tty buffer. As soon as ppp starts on the server,
- it's flooded with magic number changes and almost immediately
- decides it's tried enough to negotiate LCP and gives up.
- Meanwhile, the client, who no longer sees the reflections,
- becomes happy just in time to see a hangup from the server.
- <p>This can be avoided by allowing the peer to start negotiating
- with the following line in your ppp.conf file:
+ <p>有時就在連上之後,在記錄檔會看到 "magic is the same" 的訊息。通
+ 常這些是無害的,有時候某一端則會斷線。大多數的 ppp 實作無法解決這個
+ 問題,就算似乎連上了,在記錄檔也可以看到一直重複的 configure request
+ 和 configure acknowledgement 之類的溝通訊息,ppp 最後會放棄而關掉連
+ 線。
+ <p>會發生這種問題的通常情況是,伺服器用速度慢的硬碟、在通訊埠上執行
+ getty、並且等到使用者登入後才用 script 或程式執行 ppp;也有聽說用
+ slirp 就一定會發生類似問題的報告。原因是在 getty 結束和 ppp 開始執行
+ 的這段時間內,client 端的 ppp 開始送出 Line Control Protocol(LCP) 封
+ 包,由於伺服器通訊埠的 ECHO 仍在打開狀態,client 端的 ppp 就會看到送
+ 出去的封包被 "反彈" 回來。
+ <p>在用 LCP 溝通時,有部份是要連線兩邊分別建立自己的 magic number,
+ 來偵測及避免封包被 "反彈" 回來的狀況。協定標準中說當對方試圖用和自己
+ 相同的 magic number 溝通時,要送給對方一個 NAK 的訊號(表示不接受),
+ 接著對方就會選另一個數字。但在伺服器通訊埠 ECHO 仍打開的這段期間,
+ client 端的 ppp 送出 LCP 封包,看到相同的 magic number,於是送出
+ NAK 訊號。這個 NAK 也會被 "反彈" 回來,被誤認由對方送出,因此 client
+ 端會改變自己的 magic number。這樣 magic number 的變動次數會非常地多,
+ 並且也全都存在對方的終端機緩衝區中。當伺服器啟動 ppp 時,它馬上就
+ 被 magic number 的大量更動所淹沒,並且(幾乎是立刻)決定已經試夠了
+ LCP 而放棄;在這期間,client 端雖然再也看不到被反彈的封包,但卻來得
+ 及看到伺服器把電話線掛掉。
+ <p>允許讓對方來作 LCP 溝通可以避免這種情形,在 ppp.conf 中加下面這
+ 一行:
set openmode passive
- <p>This tells ppp to wait for the server to initiate LCP
- negotiations. Some servers however may never initiate negotiations.
- If this is the case, you can do something like:
+ <p>這行告訴 ppp 由對方來啟動 LCP,不過有些伺服器永遠都不會主動溝通
+ ,在這種情況下,可以這麼設定:
set openmode active 3
- <p>This tells ppp to be passive for 3 seconds, and then to start
- sending LCP requests. If the peer starts sending requests during
- this period, ppp will immediately respond rather than waiting for
- the full 3 second period.
+ <p>這是要 ppp 等個三秒鐘,然後再開始送 LCP 相關要求。如果對方在這
+ 段時間送出 LCP 封包,ppp 就不會等足三秒而立刻回應。
- LCP negotiations continue 'till the connection is closed
- </heading>
- <p>There is currently an implementation mis-feature in <bf/ppp/
- where it doesn't associate LCP, CCP &amp; IPCP responses with
- their original requests. As a result, if one <bf/ppp/
- implementation is more than 6 seconds slower than the other side,
- the other side will send two additional LCP configuration requests.
- This is fatal.
- Consider two implementations, <bf/A/ and <bf/B/. <bf/A/ starts
- sending LCP requests immediately after connecting and <bf/B/ takes
- 7 seconds to start. When <bf/B/ starts, <bf/A/ 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.
- <bf/B/ sends a REQ, then an ACK to the first of <bf/A/'s REQs.
- This results in <bf/A/ entering the <bf/OPENED/ state and sending
- and ACK (the first) back to <bf/B/. In the meantime, <bf/B/ sends
- back two more ACKs in response to the two additional REQs sent by
- <bf/A/ before <bf/B/ started up. <bf/B/ then receives the first
- ACK from <bf/A/ and enters the <bf/OPENED/ state. <bf/A/ receives
- the second ACK from <bf/B/ and goes back to the <bf/REQ-SENT/ state,
- sending another (forth) REQ as per the RFC. It then receives the
- third ACK and enters the <bf/OPENED/ state. In the meantime,
- <bf/B/ receives the forth REQ from <bf/A/, resulting in it reverting
- to the <bf/ACK-SENT/ state and sending another (second) REQ and
- (forth) ACK as per the RFC. <bf/A/ gets the REQ, goes into
- <bf/REQ-SENT/ and sends another REQ. It immediately receives the
- following ACK and enters <bf/OPENED/.
- <p>This goes on 'till one side figures out that they're getting
- nowhere and gives up.
- <p>The best way to avoid this is to configure one side to be
- <bf/passive/ - that is, make one side wait for the other to start
- negotiating. This can be done with the
+ LCP 的溝通一直到連線關閉才結束</heading>
+ <p>目前 <bf/ppp/ 在實作上有個會出問題的 "功能",不會將 LCP、CCP
+ &amp; IPCP 這幾種封包的回應和原先要求作對照。結果是如果有一方的
+ <bf/ppp/ 啟動時比對方慢了六秒以上,對方會在其間多送出兩個 LCP 的設定
+ 要求,後果相當嚴重。
+ <p>假設有兩端 <bf/A/ 和 <bf/B/ 都在執行 ppp,<bf/A/ 在連線後立刻
+ 送出 LCP 要求,<bf/B/ 則花了七秒才開始,所以當 <bf/B/ 啟動時,<bf/A/
+ 早已送出三個 LCP REQ(request)。我們也假設連線已將 ECHO 關掉,否則就
+ 會看到上個問題提到的 magic number 問題。<bf/B/ 啟動時也會送出 REQ,
+ 同時對 <bf/A/ 送出的第一個 REQ 回應,送出 ACK(acknowledge)。A 收到這
+ 個 ACK 後會進入 <bf/OPENED/ 狀態,同時也對 <bf/B/ 的第一個 REQ 送出
+ ACK。但在這段期間,<bf/B/ 會看到 <bf/A/ 之前多送出的兩個 REQ,因而也
+ 以兩個 ACK 回應。<bf/B/ 接著看到 <bf/A/ 傳來的第一個 ACK,因此也進入
+ <bf/OPENED/ 狀態。但這時 <bf/A/ 收到 <bf/B/ 多送的兩個 ACK。根據
+ RFC 的規定,會對第二個 ACK 送出第四個 REQ 而回到 <bf/REQ-SENT/ 狀態
+ (再重複一次 REQ-ACK 的過程),但一看到第三個 ACK,<bf/A/ 以為是
+ <bf/B/ 回應剛剛送出的 REQ,又進入 <bf/OPENED/ 狀態。此時 <bf/B/ 收到
+ <bf/A/ 發出的第四個 REQ,根據 RFC,會對這個 REQ 送出 ACK,然後再送出
+ 第二個 REQ(也是再重複一次 REQ-ACK 的過程)。<bf/A/ 收到這個 REQ 後
+ 會再重新送 REQ 而回到 <bf/REQ-SENT/ 狀態,接著又收到 ACK 而進入
+ <bf/OPENED/ 狀態。因此雙方都會以為收到的 ACK 是對方回應剛剛送出去的
+ REQ,最後 <bf/A/ 會一直在 <bf/OPENED/ 和 <bf/REQ-SENT/ 兩種狀態間切
+ 換,對 <bf/B/ 則是 <bf/OPENED/ 和 <bf/ACK-SENT/。
+ <p>這種惡性循環會一直持續著,直到有一方發現自己在原地打轉而放棄繼續
+ 下去。
+ <p>避免這種情況的最好方式,是將某一端設成<bf/被動模式/-也就是等另一
+ 方先開始溝通,用這道命令:
set openmode passive
- command. Care should be taken with this option. You should also
- use the
+ 用這個選項時要小心,應該和這個命令一起用:
set stopped N
- command to limit the amount of time that <bf/ppp/ waits for the peer
- to begin negotiations. Alternatively, the
+ 這會設定 <bf/ppp/ 等待對方開始溝通的時間上限,另一個方法是用:
set openmode active N
- command (where <bf/N/ is the number of seconds to wait before
- starting negotiations) can be used. Check the manual page for
- details.
+ 其中 <bf/N/ 是在主動溝通之前先等待的秒數,man page 有更詳細的說明。
- <heading>Ppp locks up shortly after connecting</heading>
+ <heading>Ppp 在連線後就卡住了</heading>
- <p>Prior to version 2.2.5 of FreeBSD, it was possible that your
- link was disabled shortly after connection due to <bf/ppp/
- 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
- <bf/ppp/, the problem can be circumvented with the line
+ <p>在 FreeBSD 2.2.5 之前的版本,有可能因為 <bf/ppp/ 在處理 Predictor1
+ 壓縮時發生錯誤,使得在連線後馬上就卡住。只有當連線雙方都試圖用不同
+ 種 Compression Control Protocol(CCP) 溝通時,才會發生這種情形。這個
+ 問題已經解決了,但如果仍在用舊版的 <bf/ppp/,可以用這種方法避免:
disable pred1
- <heading>Ppp locks up when I shell out to test it</heading>
+ <heading>用 shell 跳出 Ppp 做測試時,連線似乎卡住了</heading>
- <p>When you execute the <tt/shell/ or <tt/!/ command, <bf/ppp/
- executes a shell (or if you've passed any arguements, <bf/ppp/
- will execute those arguements). Ppp 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 <bf/ppp/ is waiting for the command
- to complete.
+ <p>在用 <tt/shell/ 或 <tt/!/ 命令時,<bf/ppp/ 會執行 shell(<bf/ppp/
+ 也會把你指定的參數傳給 shell),Ppp 會等到這些命令結束後才繼續。如果
+ 有使用到 ppp 連線的命令,連線會像是被凍住了,這是因為 <bf/ppp/ 正在
+ 等這些指令結束。
- <p>If you wish to execute commands like this, use the
- <tt/!bg/ command instead. This will execute the given command
- in the background, and ppp can continue to service the link.
+ <p>如果想執行程式,用 <tt/!bg/ 這個命令,它會把程式丟到背景執行,ppp
+ 接著就能繼續保持連線。
- <heading>Ppp over a null-modem cable never exits</heading>
+ <heading>在 null-modem 線上建立的 Ppp 好像不會自動斷線</heading>
- <p>There is no way for <bf/ppp/ 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, LQR should always be enabled with
- the line
+ <p>由於 null-modem 本身用的線材,<bf/ppp/ 沒有辦法自動決定是否
+ 某個直接連線已經斷掉。當使用這類方式的連線時,一定要打開 LQR:
enable lqr
- <p>LQR is accepted by default if negotiated by the peer.
+ <p>內定是會接受 LQR,如果對方用它來溝通的話。
- <heading>Why does ppp dial for no reason in -auto mode</heading>
+ <heading>為什麼 ppp 在 -auto 模式下會無緣無故播號?</heading>
- <p>If <bf/ppp/ is dialing unexpectedly, you must determine the
- cause, and set up Dial filters (dfilters) to prevent such dialing.
+ <p>如果 <bf/ppp/ 非預期地播號,就必須要找出原因,然後設定播號過濾
+ 器(dfilter, Dial filter)來避免這種情形。
- <p>To determine the cause, use the following line:
+ <p>要找出原因,先用這個命令:
set log +tcp/ip
- <p>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 it.
+ <p>這樣會記錄經由連線的所有資料。下次如果又無故播號,就可以從記錄
+ 旁邊的時間很快找到原因。
- <p>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 <bf/not/
- prevent <bf/ppp/ from passing the packets through an established
- connection), use the following:
+ <p>現在可以避免因為這些原因播號。通常是在作 DNS 查詢時才會發生這種
+ 問題,要避免因 DNS 查詢而連線(這樣<bf/不會/使 <bf/ppp/ 在連線狀態
+ 下擋掉這些封包),用下面這幾行:
set dfilter 1 deny udp src eq 53
@@ -519,117 +539,99 @@ default UGSc 0 0 tun0
set dfilter 3 permit 0/0 0/0
- <p>This is not always suitable, as it will effectively break your
- demand-dial capabilities - most programs will need a DNS lookup
- before doing any other network related things.
+ <p>這種做法並不永遠適用,因為它事實上使得你無法用 demand-dial 功能
+ - 大部份程式在做網路相關動作前都會用到 DNS 查詢。
- <p>In the DNS case, you should try to determine what is actually
- trying to resolve a host name. A lot of the time,
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
- name="sendmail"> is the culprit. You should make sure that you tell
- sendmail not to do any DNS lookups in its configuration file. See
- the section on <ref id="ispmail" name="Mail Configuration"> for
- details on how to create your own configuration file and what should
- go into it. You may also want to add the following line to your
- <bf/.mc/ file:
+ <p>在 DNS 這個情況下,應該試著找出到底是誰想要解出主機名稱,通常幾
+ 乎都是由 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
+ name="sendmail"> 所造成,所以要在 sendmail 設定檔中指示它不要做任何
+ DNS 查詢。在 <ref id="ispmail" name="Mail 設定">中有詳細說明如何作出
+ 自己的設定檔、及裡面應該放那些設定,你也許想要將下一行加入 <bf/.mc/
+ 檔中:
define(`confDELIVERY_MODE', `d')dnl
- <p>This will make sendmail queue everything until the queue is
- run (usually, sendmail is invoked with ``-bd -q30m'', telling it
- to run the queue every 30 minutes) or until a ``sendmail -q''
- is done (perhaps from your ppp.linkup file).
+ <p>這會使 sendmail 先擋著所有信件,直到送信時再一齊送出去(通常
+ sendmail 執行時是用 ``-bd -q30m'' 這個參數,告訴它每三十分鐘才送信)
+ 或是有人執行 ``sendmail -q''(也許可以放在 ppp.linkup 裡)。
- <heading>What do these CCP errors mean</heading>
+ <heading>這些 CCP 錯誤訊息是指?</heading>
- <p>I keep seeing the following errors in my log file:
+ <p>我在 log 檔一直看到這些錯誤訊息:
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
- <p>This is because ppp 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:
+ <p>這是因為 ppp 試圖作 Predictor1 壓縮方面的溝通,但對方的機器卻完
+ 全不用壓縮功能。這些訊息是無害的,但如果不想看到它的話,可以把本地
+ ppp 的 Predictor1 壓縮也一起關掉:
disable pred1
- <heading>Ppp locks up during file transfers with IO errors</heading>
+ <heading>傳檔案時發生 IO 錯誤,然後 Ppp 就掛掉了</heading>
- <p>Under FreeBSD 2.2.2 and before, there was a bug in the tun
- driver that prevents incoming packets of a size larger than
- the tun interface's MTU size. Receipt of a packet greater than
- the MTU size results in an IO error being logged via syslogd.
+ <p>在 FreeBSD 2.2.2 及先前的版本中,tun 的驅動程式有個問題,它不會
+ 接收那些大過 tun 介面 MTU 的封包。如果收到比 MTU 大的封包,它會用
+ syslogd 記錄為 IO 錯誤。
- <p>The ppp specification says that an MRU of 1500 should
- <bf>always</bf> 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 non-feature - locking
- up your link.
+ <p>但 ppp 規格中有提到,不管 LCP 溝通的結果如何,MRU 最小的可接受
+ 值<bf>永遠</bf>是 1500。所以有可能你不小心將 MTU 調低於 1500,ISP
+ 會不理它而送出 1500 大小的封包,然後就會觸發上述的 "功能"。
- <p>The problem can be circumvented by never setting an MTU of
- less than 1500 under FreeBSD 2.2.2 or before.
+ <p>在 FreeBSD 2.2.2 及之前的版本中,永遠不要將 MTU 調低於 1500,就
+ 可以解決這個問題。
- <heading>Why doesn't ppp log my connection speed?</heading>
+ <heading>為什麼 ppp 不會記錄我的連線速度?</heading>
- <p>In order to log all lines of your modem ``conversation'',
- you must enable the following:
+ <p>如果要記錄電腦和數據機間的每一行 ``對話'',用下一行打開:
set log +connect
- <p>This will make
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
- log everything up until the last requested "expect" string.
+ <p>這會使 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
+ name="ppp"> 記錄所有資料,直到播號字串最後一個等待的數據機傳回值
+ 為止。
- <p>If you wish to see your connect speed and are using PAP or CHAP
- (and therefore don't have anything to "chat" after the CONNECT
- in the dial script - no "set login" script), you must make sure that
- you instruct ppp to "expect" the whole CONNECT line, something like
- this:
+ <p>如果使用 PAP 或 CHAP (因為沒有 "set login" 命令,所以設定檔中
+ CONNECT 之後就不會看到任何對話),想要看到連線速度的話,確定 ppp
+ 等待的數據機傳回值是 CONNECT 這一整行,像這樣:
- <p>Here, we get our CONNECT, send nothing, then expect a line-feed,
- forcing <bf/ppp/ to read the whole CONNECT response.
+ <p>這樣在看到 CONNECT 後不會送出任何東西,接著再等個換行字元,強
+ 迫 <bf/ppp/ 讀取回應的 CONNECT 一整行。
- <heading>Ppp ignores the `\' character in my chat script</heading>
+ <heading>Ppp 不理會 chat script 中的 `\' 字元</heading>
- <p>Ppp parses each line in your config files so that it can
- interpret strings such as <tt/set phone "123 456 789"/ correctly
- (and realize that the number is actually only <bf/one/ argument.
- In order to specify a ``"'' character, you must escape it using
- a backslash (``\'').
+ <p>Ppp 會去分析設定檔中的每一行,這樣它才會正確解讀像是
+ <tt/set phone "123 456 789"/ 的字串(你應該知道這個數字只是
+ <bf/一個/參數,如果要指定 ``"'' 這個字元,必須在它前面用反斜線
+ (``\'')將它跳開)。
- <p>When the chat interpreter parses each argument, it re-interprets
- the argument in order to find any special escape sequences such
- as ``\P'' or ``\T'' (see the man page). As a result of this
- double-parsing, you must remember to use the correct number of
- escapes.
+ <p>當解譯程式分析每個參數時,為了找出字串中所有像是 ``\P'' ``\T''
+ 的跳脫字元(見 man page),必須重新解譯該參數。在這種雙重分析之下,
+ 你必須記得用正確的跳脫數目。
- <p>If you wish to actually send a ``\'' character to (say) your
- modem, you'd need something like:
+ <p>假設要對數據機送出 ``\'' 這個字元,應該像是:
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
- <p>resulting in the following sequence:
+ <p>這樣則會得到下面這串:
@@ -638,14 +640,14 @@ default UGSc 0 0 tun0
- <p>or
+ <p>如果是
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
- <p>resulting in the following sequence:
+ <p>則會得到下面結果:
@@ -654,16 +656,14 @@ default UGSc 0 0 tun0
- <heading>Ppp gets a seg-fault, but I see no <tt/ppp.core/ file</heading>
+ <heading>Ppp 碰到了 seg-fault,但找不到 <tt/ppp.core/ 這個檔?
+ </heading>
- <p>Ppp (or any other program for that matter) should never
- dump core. Because ppp runs with an effective user id of 0,
- the operating system will not write ppps core image to disk
- before terminating it. If, however ppp <bf/is/ actually
- termating due to a segmentation violation or some other
- signal that normally causes core to be dumped, <bf/and/ you're
- sure you're using the latest version (see the start of this
- section), then you should do the following:
+ <p>Ppp (或任何類似的程式) 應該不可能有 core dump。由於 ppp 執行時
+ 的 effective user id 是 0 (即以 root 身份執行),作業系統在終止 ppp
+ 前不會對磁碟寫它的 core 映像檔。如果 ppp <bf/真的/因為 segmentation
+ violation 或其他一般會 core dump 的 signal 而終止、<bf/並且/確定用
+ 的是最新版本(見本節開頭),那麼你可以這麼做:
$ tar xfz ppp-*.src.tar.gz
@@ -676,14 +676,11 @@ default UGSc 0 0 tun0
# chmod 555 /usr/sbin/ppp
- <p>You will now have a debuggable version of ppp installed. You
- will have to be root to run ppp as all of its privileges have
- been revoked. When you start ppp, take a careful note of what
- your current directory was at the time.
+ <p>你現在已經裝上可以用來除錯的 ppp 版本,由於權限上沒有作特別設定,
+ 所以必須以 root 來執行 ppp,順便也要注意是在那個目錄執行的。
- <p>Now, if and when ppp receives the segmentation violation, it
- will dump a core file called ppp.core. You should then do the
- following:
+ <p>現在如果 ppp 碰到了 segmentation violation,就會將 coredump 存在
+ ppp.core 檔中,接下來就是:
$ su
@@ -698,177 +695,149 @@ default UGSc 0 0 tun0
- <p>All of this information should be given alongside your
- question, making it possible to diagnose the problem.
- <p>If you're familiar with gdb, you may wish to find out some
- other bits and pieces such as what actually caused the dump and
- the addresses & values of the relevant variables.
+ <p>根據你的問題來取得相關資料,就可以診斷問題出在那裡。
+ <p>如果熟悉 gdb,也許會想找出其他的詳細資料,像是那個動作造成
+ dump、及相關變數的位址及數值等。
- The process that forces a dial in auto mode never connects
+ 在 -auto 模式下,使 ppp 播號的程式在連線後卻連不到目的地
- <p>This was a known problem with <bf/ppp/ 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 <bf/iface/.
- <p>The problem was that when that initial program calls
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
- name="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. <bf/Ppp/ then
- reads the packet and establishes a connection. If, as a result
- of <bf/ppp/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 back to the originating
- machine as the IP number is no longer owned by that machine.
- <p>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 <tt/:-)/ The current version of <bf/ppp/ does this,
- but most other implementations don't.
- <p>The easiest method from our side would be to never change the
- tun 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
- <tt/iface-alias/ option in the latest version of <bf/ppp/ is
- doing (with the help of <htmlurl
- url="http://www.freebsd.org/cgi/man.cgi?libalias" name="libalias(3)">
- and ppp's <bf/-alias/ switch) - it's maintaining all previous
- interface addresses and aliasing them to the last negotiated address.
- <p>Another alternative (and probably the most reliable) would be
- to implement a system call that changes all bound sockets from one
- IP to another. <bf/Ppp/ 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 sockets.
- <p>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 up until the first SIOCAIFADDR
- ioctl is done. This would result in fully binding the socket. It
- would be up to <bf/ppp/ to change the source IP number, but only if
- it's set to, 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.
+ <p>這是設定 <bf/ppp/ 在 -auto 模式向對方取得動態 IP 時的已知問題,
+ 在最新版的 ppp 已經解決了 - 在 man page 中用 <bf/iface/ 關鍵字找找
+ 看。
+ <p>當用到網路的程式呼叫 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?connect" name="connect(2)">
+ 時,socket endpoint 會設成 tun 這個界面的 IP,kernel 接著產生要送出
+ 去的第一個封包,把它傳給 tun,<bf/Ppp/ 讀到這個封包後就會開始建立連
+ 線。如果 <bf/ppp/ 用的是動態分配 IP,那麼就會改變 tun 界面的位址,
+ 原先的 socket endpoint 就成為不正確的值。接著送到對方的封包通常都會
+ 被丟掉,就算能順利達到對方機器,由於該來源 IP 已給其他人使用,任何回
+ 應也不會被傳回本地的機器上。
+ <p>理論上,有好幾種方法可以解決這個問題。如果 ISP 願意每次都提供相同
+ IP 當然是最好 <tt/:-)/,目前版本的 <bf/ppp/ 會做到這一點,但大多數的
+ ppp 實作不會這麼做。
+ <p>從 client 端最容易的解決方式是,永遠都不要改變 tun 界面的 IP 值,
+ 但是將所有出去的封包來源 IP 從原先的 tun 界面 IP 改為連線時取得的
+ IP,基本上這就是最新版 <bf/ppp/ 裡 <tt/iface-alias/ 選項的做法(使用
+ 了 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
+ name="libalias(3)"> 和執行 ppp 時的 <bf/-alias/ 參數)-記住之前所有
+ 用過的 tun 界面 IP,再把全部換成最近一次拿到的位址。
+ <p>另一種方法(可能是最可靠)是寫個可以修改所有 socket endpoint 值的
+ system call。當拿到新的 IP 時,<bf/Ppp/ 就可以用它來修改所有執行程式
+ 所建立的 socket。當 DHCP client 程式對 socket 重新使用 bind() 時,也
+ 可以用同樣的呼叫。
+ <p>還有一個可能則是允許不用 IP,就可以啟用某個網路界面。送出去的封包
+ 來源 IP 會設成,直到 SIOCAIFADDR 這個 ioctl 第一次執
+ 行完成為止。這樣會完全連結 socket 的兩端,而由 <bf/ppp/ 來修改來源的
+ IP 值,但只有當原來 IP 值是 時、或者 IP 值和 IP 偵錯
+ 碼需要修改時才會去更動。這種方式有點算是 hack,即 kernel 可以對沒設
+ 定好的界面送出壞掉的封包,因為假設會有其他機制可以修正這種錯誤。
- <heading>Why don't most games work with the -alias switch</heading>
- <p>The reason games and the like don't work when libalias is
- in use is that the machine on the outside will try to open a
- connection or send (unsolicited) UDP packets to the machine
- on the inside. The packet alias software doesn't know that
- it should send these packets to the interior machine.
- <p>To make things work, make sure that the only thing running
- is the software that you're having problems with, then either
- run tcpdump on the tun interface of the gateway or enable ppp
- tcp/ip logging (``set log +tcp/ip'') on the gateway.
- <p>When you start the offending software, you should see packets
- passing through the gateway machine. When something comes back
- from the outside, it'll be dropped (that's the problem). Note
- the port number of these packets then shut down the offending
- software. Do this a few times to see if the port numbers are
- consistent. If they are, then the following line in the relevant
- section of /etc/ppp/ppp.conf will make the software functional:
+ <heading>為何玩大多數遊戲時,都不能使用 -alias 這個參數?</heading>
+ <p>遊戲或類似程式不能和 libalias 搭配使用的原因是,外面的機器試著對
+ 著內部的機器開啟連線、或(不請自來地)送出 UDP 封包,而 alias 封包的
+ 軟體不知道它應該把這些封包送到裡面的機器去。
+ <p>解決的方式是,先確定現在只有執行那個會出問題的程式,然後在
+ gateway 機器上對 tun 界面執行 tcpdump、或在上面打開記錄 tcp/ip 的功
+ 能(``set log +tcp/ip'')。
+ <p>在啟動出問題的程式時,應該會在 gateway 機器上看到有封包通過,當外
+ 界有傳回封包時則會被丟掉(這就是問題所在)。記下這些封包要送到目的地
+ 的那個埠,然後關掉程式。重複幾次,看看是否都要送到同樣固定的埠,如果
+ 是的話,在 /etc/ppp/ppp.conf 相關位置加上這一行,就可使程式正確運作:
alias port proto internalmachine:port port
- <p>where ``proto'' is either ``tcp'' or ``udp'',
- ``internalmachine'' is the machine that you want the packets
- to be sent to and ``port'' is the destination port number of
- the packets.
+ <p>其中 ``proto'' 是 ``tcp'' 或 ``udp'',``internalmachine'' 是要接
+ 收這些封包的機器,``port'' 則是這些封包要送到那個埠。
- <p>You won't be able to use the software on other machines
- without changing the above command, and running the software
- on two internal machines at the same time is out of the question
- - after all, the outside world is seeing your entire internal
- network as being just a single machine.
+ <p>如果要在其他機器上執行同樣程式,必須重複同樣過程修改上一行設定,
+ 否則就不能正常使用;也不可能在兩台內部機器上同時使用-畢竟外界只是把
+ 這個內部網路看成一台機器而已。
- <p>If the port numbers aren't consistent, there are three more
- options:
+ <p>如果封包不一定送到同樣的埠,你有三種選擇:
- <p><bf>1)</bf> Submit support in libalias. Examples of ``special
- cases'' can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c
- is a good prototype). This usually involves reading certain
- recognised outgoing packets, identifying the instruction that
- tells the outside machine to initiate a connection back to the
- internal machine on a specific (random) port and setting up a
- ``route'' in the alias table so that the subsequent packets
- know where to go.
+ <p><bf>1)</bf> 在 libalias 加入對它的支援,
+ /usr/src/lib/libalias/alias_*.c 有一些 ``特例'' 的示範(alias_ftp.c
+ 是個不錯的原型檔)。通常是讀取某些可以認得出的外送封包,找出要外面連
+ 到內部機器某個埠的指令,然後在 alias 表中設定 ``route'',以後再收到
+ 這種封包就知道要往那裡送。
- <p>This is the most difficult solution, but it is the best and
- will make the software work with multiple machines.
+ <p>這是最困難的解法,但也是最好的,並且還可以在多台機器上用同樣程式。
- <p><bf>2)</bf> Use a proxy. The application may support socks5
- for example, or (as in the ``cvsup'' case) may have a ``passive''
- option that avoids ever requesting that the peer open connections
- back to the local machine.
+ <p><bf>2)</bf> 使用 proxy。舉例來說,該應用程式也許支援 socks5,或是
+ 有個 ``passive'' 的選項(像是 ``cvsup'')可以避免對方向內部機器提出
+ 連線的要求。
- <p><bf>3)</bf> Redirect everything to the internal machine using
- ``alias addr''. This is the sledge-hammer approach.
+ <p><bf>3)</bf> 用 ``alias addr'' 把所有資料都轉給內部機器,這是最後
+ 才用的暴力法。
+ <sect3>
+ <heading>那裡可以找到常用埠的列表?</heading>
+ <p>現在還沒有,但可以將這些弄成一個名單(如果有人感興趣的話):
+ <itemize>
+ <item><bf>Quake</bf>
+ <p>Quake 是說用 UDP 6112 這個埠,所以如果 Quake 伺服器的 IP 是
+ <tt>hostmachine</tt>,那麼
+ <tt>alias port udp hostmachine:6112 6112</tt> 這一行應該就可以正
+ 常運作。如果想用其他方式,<htmlurl
+ url="http://www.battle.net/support/proxy/" name="www.battle.net">
+ 有 Quake 對 proxy 支援的說明。
+ </itemize>
- <heading>What are FCS errors ?</heading>
- <p>FCS stands for <bf/F/rame <bf/C/heck <bf/S/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 count is increased. The HDLC error values can be
- displayed using the <tt>show hdlc</tt> command.
- <p>If your link is bad (or if your serial driver is dropping
- packets), you will see the occasional FCS error. This is not
- usually worth worrying about although it does slow down the
- compression protocols substantially. If you have an external
- modem, make sure your cable is properly shielded from
- interference - this may eradicate the problem.
- <p>If your link freezes as soon as you've connected and you see
- a large number of FCS errors, this may be because your link is
- not 8 bit clean. Make sure your modem is not using software
- flow control (XON/XOFF). If your datalink <bf>must</bf> use
- software flow control, use the command
- <tt>set accmap 0x000a0000</tt> to tell <bf>ppp</bf> to escape
- the ^Q and ^S characters.
- <p>Another reason for seeing too many FCS errors may be that
- the remote end has stopped talking <bf/PPP/. You may want to
- enable <tt/async/ logging at this point to determine if the
- incoming data is actually a login or shell prompt. If you
- have a shell prompt at the remote end, it's possible to
- terminate ppp without dropping the line by using the
- <tt>close lcp</tt> command (a following <tt>term</tt> command
- will reconnect you to the shell on the remote machine.
- <p>If nothing in your log file indicates why the link might
- have been terminated, you should ask the remote administrator
- (your ISP?) why the session was terminated.
+ <heading>什麼是 FCS 錯誤?</heading>
+ <p>FCS 是 <bf/F/rame <bf/C/heck <bf/S/equence 的縮寫。每一個 ppp
+ 封包都附有偵錯碼來確定收到的資料的確是送出的資料。如果進來的某個
+ 封包 FCS 不正確,就丟掉這個封包、再把 HDLC 裡的 FCS 計數器加 1。
+ 用 <tt>show hdlc</tt> 便可看到 HDLC 裡的各種錯誤計數值。
+ <p>不良線路(或封包被串列埠的驅動程式丟掉)有時候就會發生 FCS 錯誤,
+ 雖然它的確會大大拖慢壓縮協定,不過通常這沒什麼大不了。如果你用的
+ 是外接數據機,確定有保護線路不受外界干擾 - 這樣說不定就解決了。
+ <p>如果在連上時馬上就凍住、並且還看到一大堆 FCS 錯誤的話,有可能
+ 是因為你的連線並非是 8 bit clean。確定數據機不是用軟體流程控制
+ (XON/XOFF),如果你的連線<bf>一定</bf>要用軟體流程控制的話,用
+ <tt>set accmap 0x000a0000</tt> 這道命令告訴 <bf>ppp</bf> 跳過 ^Q
+ 和 ^S 這兩個字元。
+ <p>看到一大堆 FCS 錯誤的另一個原因,是連線另一端不再使用 <bf/PPP/
+ 溝通。這時候也許應該打開 <tt/async/ 的記錄功能,來決定是否進來的
+ 資料其實是 login 或 shell 提示符號。如果另一端是 shell 提示符號,
+ 先執行 <tt>close lcp</tt>、接著 <tt>term</tt> 就可以重新連接到對
+ 方機器的 shell 下,而不用掛掉電話線。
+ <p>如果記錄檔裡沒有任何資訊可以指示連線為何斷掉,那麼就該問問另一
+ 端的管理員(你的 ISP?) 怎麼會這樣結束。
- <heading>None of this helps - I'm desperate !</heading>
- <p>If all else fails, send as much information as you can,
- including your config files, how you're starting <bf/ppp/,
- the relevant parts of your log file and the output of the
- <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
- name="netstat -rn"> command (before and after connecting) to the
- <url url="mailto:freebsd-questions@FreeBSD.org"
- name="freebsd-questions@FreeBSD.org"> mailing list or the
+ <heading>沒有一個方法可以用,我完蛋了啦!</heading>
+ <p>如果上面說的都沒用,就盡可能找出所有資訊,這包括了設定檔、如何
+ 啟動 <bf/ppp/、log 檔的相關部份、連線前後的 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?netstat" name="netstat -rn">
+ 輸出結果,把這些送到 <url url="mailto:freebsd-questions@FreeBSD.org"
+ name="freebsd-questions@FreeBSD.org"> mailing list 或
<url url="news:comp.unix.bsd.freebsd.misc"
- name="comp.unix.bsd.freebsd.misc"> news group, and someone
- should point you in the right direction.
+ name="comp.unix.bsd.freebsd.misc"> newsgroup,這樣應該就會有人指點
+ 正確的方向。
<heading>我沒有辦法建立 <tt>/dev/ed0</tt> 這個 device!</heading>
@@ -908,7 +877,7 @@ default UGSc 0 0 tun0
<p>某些 PC 的網路卡比其他的好(含蓄的說來)
這種狀況在造成 NFS 這種對網路敏感的程式有時會出現問題.
- <p>參考 <url url="../../handbook/nfs.html" name="the Handbook entry on NFS">
+ <p>參考 <url url="../handbook/nfs.html" name="the Handbook entry on NFS">
@@ -989,180 +958,154 @@ default UGSc 0 0 tun0
- <heading>為什麼我的主機要提供 FQDN ?</heading>
- <p>You will probably find that the host is actually in a different
- domain; for example, if you are in foo.bar.edu and you wish to reach
- a host called ``mumble'' in the bar.edu domain, you will have to
- refer to it by the fully-qualified domain name, ``mumble.bar.edu'',
- instead of just ``mumble''.
- <p>Traditionally, this was allowed by BSD BIND resolvers. However
- the current version of <htmlurl
- url="http://www.freebsd.org/cgi/man.cgi?named" name="bind"> that ships
- with FreeBSD no longer provides default abbreviations for non-fully
- qualified domain names other than the domain you are in.
- So an unqualified host <tt>mumble</tt> must either be found
- as <tt>mumble.foo.bar.edu</tt>, or it will be searched for
- in the root domain.
- <p>This is different from the previous behavior, where the
- search continued across <tt>mumble.bar.edu</tt>, and
- <tt>mumble.edu</tt>. Have a look at RFC 1535 for why this
- was considered bad practice, or even a security hole.
- <p>As a good workaround, you can place the line
+ <heading>為什麼要用 FQDN 才能連到其他機器?</heading>
+ <p>你也許會發現要連的機器其實是在另一個網域。舉個例子,假設你是在
+ foo.bar.edu 這個網域中,想要連到在 bar.edu 裡一台叫 ``mumble'' 的
+ 機器,則必須用 Fully-Qualified Domain Name,也就是
+ ``mumble.bar.edu'',而不是只用 ``mumble'' 來指向它。
+ <p>傳統的 BSD BIND resolver 允許用這種方式解出機器的位址,但是
+ FreeBSD 內附 <htmlurl
+ url="http://www.freebsd.org/cgi/man.cgi?named" name="bind"> 版本
+ 的內定方式,則是除了你所在的網域以外,不支援其他非 FQDN 的縮寫。
+ 所以如 <tt>mumble</tt> 這種不合格的機器名稱,必須在
+ <tt>mumble.foo.bar.edu</tt>,否則就會從網域的最底層開始找。
+ <p>這和先前的做法不同,也就是不用 <tt>mumble.bar.edu</tt> 和
+ <tt>mumble.edu</tt> 繼續搜尋。看一下 RFC 1535,裡面有提到為什麼之
+ 前的做法不好,甚至算是個安全漏洞。
+ <p>這裡有個不錯的解法,把
+ <htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
+ name="/etc/resolv.conf"> 裡的這一行:
- search foo.bar.edu bar.edu
+ domain foo.bar.edu
- <p>instead of the previous
+ 換成這一行:
- domain foo.bar.edu
+ search foo.bar.edu bar.edu
- <p>into your <htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
- name="/etc/resolv.conf"> file. However, make sure that the search order
- does not go beyond the ``boundary between local and public
- administration'', as RFC 1535 calls it.
+ 但是要確定搜尋順序不會違反 RFC 2535 所謂的 ``boundary between local
+ and public administration''。
- <heading>``Permission denied'' for all networking operations.</heading>
+ <heading>所有網路動作都會出現 ``Permission denied'' 錯誤訊息</heading>
- <p>If you have compiled your kernel with the <tt/IPFIREWALL/
- option, you need to be aware that the default policy as of
- 2.1.7R (this actually changed during 2.1-STABLE development)
- is to deny all packets that are not explicitly allowed.
+ <p>如果在編譯 kernel 時加了 <tt/IPFIREWALL/ 這個選項,要曉得 2.1.7R
+ 內定是拒絕所有未經核准的網路封包(但在開發 2.1-STABLE 時改掉了)。
- <p>If you had unintentionally misconfigured your system for
- firewalling, you can restore network operability by typing
- the following while logged in as root:
+ <p>如果不小心弄錯了 firewall 的設定,以 root 身份執行這個命令,接著
+ 網路功能就會正常:
ipfw add 65534 allow all from any to any
- <p>You can also set "firewall_type='open'" in <tt>/etc/rc.conf</tt>.
+ <p>也可以在 <tt>/etc/rc.conf</tt> 設 "firewall_type='open'" 這個選項。
- <p>For further information on configuring a FreeBSD firewall,
- see the <url url="../../handbook/firewalls.html" name="Handbook section">.
+ <p>如果想知道如何設定 FreeBSD firewall,請看 <url
+ url="../handbook/firewalls.html" name="Handbook 相關部份">。
- <heading>How much overhead does IPFW incur?</heading>
+ <heading>IPFW 會造成多大的網路延遲?</heading>
- <p>The answer to this depends mostly on your rule set and processor
- speed. For most applications dealing with ethernet and small
- rule sets, the answer is, negligible. For those of you that need
- actual measurements to satisfy your curiosity, read on.
+ <p>這個問題的答案大多要看你怎麼訂 firewall 規則、還有 CPU 速度。對大
+ 多數在 ethernet 上的程式及規則不多的情況下,延遲小到可以忽略。但如果
+ 你想要精確數字來滿足好奇心,繼續往下讀。
- <p>The following measurements were made using 2.2.5-STABLE on
- a 486-66. IPFW was modified to measure the time spent within
- the <tt/ip_fw_chk/ routine, displaying the results to the console
- every 1000 packets.
+ <p>下面是在 486-66 2.2.5-STABLE 上所作的測量,我們修改了 IPFW 原始碼
+ 來測量在 <tt/ip_fw_chk/ 函式上所花的時間,每處理 1000 個封包後就會在
+ console 上顯示結果。
- <p>Two rule sets, each with 1000 rules were tested. The first set
- was designed to demonstrate a worst case scenario by repeating the
- rule:
+ <p>測試了兩組,每組各有 1000 個規則。第一組重複下面規則,故意設計成
+ 最糟的情況:
ipfw add deny tcp from any to any 55555
- <p>This demonstrates worst case by causing most of IPFW's packet
- check routine to be executed before finally deciding that the
- packet does not match the rule (by virtue of the port number).
- Following the 999th iteration of this rule was an <tt>allow ip
- from any to any</tt>.
+ <p>藉由檢查 port number,這樣會使 IPFW 在決定某個封包不符合條件前執
+ 行大部份的檢查程式,因此造成最差的狀況。在重複這個規則 999 次後,接
+ 著是 <tt>allow ip from any to any</tt>。
- <p>The second set of rules were designed to abort the rule
- check quickly:
+ <p>第二組設計成以極快的速度跳過檢查規則:
ipfw add deny ip from to
- <p>The nonmatching source IP address for the above rule causes
- these rules to be skipped very quickly. As before, the 1000th
- rule was an <tt>allow ip from any to any</tt>.
+ <p>一碰到封包的來源不符合規則所述,會很快跳過檢查讓封包通過。和上面
+ 一樣,第 1000 個規則是 <tt>allow ip from any to any</tt>。
- <p>The per-packet processing overhead in the former case was
- approximately 2.703ms/packet, or roughly 2.7 microseconds per
- rule. Thus the theoretical packet processing limit with these
- rules is around 370 packets per second. Assuming 10Mbps ethernet
- and a ~1500 byte packet size, we would only be able to achieve a
- 55.5% bandwidth utilization.
+ <p>在第一種情況中,處理每一個封包所造成的延遲大約是 2.703 ms,所以每
+ 個規則大概會造成 2.7 microsecond 的延遲。所以在這些規則之下,理論上每
+ 秒最多可以處理 370 個封包。在 10Mbps ethernet 和一個封包大概 1500 byte
+ 的假設下,大概只會用到 55.5% 的網路頻寬。
- <p>For the latter case each packet was processed in
- approximately 1.172ms, or roughly 1.2 microseconds per rule.
- The theoretical packet processing limit here would be about
- 853 packets per second, which could consume 10Mbps ethernet
- bandwidth.
+ <p>第二種情況,每個封包花了大約 1.172ms,所以每條規則大約用了 1.2
+ microsecond。理論上每秒最多可以處理 853 個封包,耗盡 10Mbps 的頻寬。
- <p>The excessive number of rules tested and the nature of those
- rules do not provide a real-world scenario -- they were used only
- to generate the timing information presented here. Here are a
- few things to keep in mind when building an efficient rule set:
+ <p>上面測試用到的大量規則、及這些規則本身並不代表真實世界的情況,他們
+ 只是用來產生所表示的數據。若想要訂出一套有效率的規則,記得這幾件事:
- <item>Place an `established' rule early on to handle the
- majority of TCP traffic. Don't put any <tt>allow tcp</tt>
- statements before this rule.
+ <item>在最前面放一個專門處理大量 TCP 流量的可用規則,在這條前面不
+ 要放任何 <tt>allow tcp</tt> 的相關敘述。
- <item>Place heavily triggered rules earlier in the rule
- set than those rarely used (<bf>without changing the
- permissiveness of the firewall</bf>, of course). You can see
- which rules are used most often by examining the packet counting
- statistics with <tt>ipfw -a l</tt>.
+ <item>把常常觸發的規則放在前面,不常用到的則丟到後面(<bf>當然在不
+ 影響 firewall 出入允許設定的前提下</bf>)。執行 <tt>ipfw -a l</tt>
+ 就可看到封包的統計數目,來看最常用到那些規則。
- <heading>How can I redirect service requests from one machine to another?
+ <heading>要如何把對某台機器的網路服務要求(service request)轉向到另一台?
- <p>You can redirect FTP (and other service) request with the 'socket'
- package, available in the ports tree in category 'sysutils'.
- Simply replace the service's commandline to call socket instead, like so:
+ <p>在 ports 目錄的 sysutils 種類中有個叫 'socket' 的 package,可以幫
+ 你轉向 FTP 或其他類似的網路服務。只要把該網路服務的命令改成呼叫 socket
+ 即可,如下(在 <tt>/etc/inetd.conf</tt> 裡):
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
- <p>where 'ftp.foo.com' and 'ftp' are the host and port to redirect to,
- respectively.
+ <p>其中 'ftp.foo.com' 和 'ftp' 分別是被轉到的機器和 port 名稱。
- <heading>Where can I get a bandwidth management tool?</heading>
+ <heading>那裡可以找到管理頻寬的工具?</heading>
- <p>There are two bandwidth management tools available for FreeBSD.
+ <p>FreeBSD 上有兩套頻寬管理工具:
<url url="http://www.csl.sony.co.jp/person/kjc/programs.html"
- name="ALTQ"> is available for free; Bandwidth Manager from
- <url url="http://www.etinc.com" name="Emerging Technologies"> is
- a commercial product.
+ name="ALTQ"> 可以免費使用,
+ <url url="http://www.etinc.com" name="Emerging Technologies"> 出的
+ Bandwidth Manager 則是商用軟體。
- <heading>Why do I get ``/dev/bpf0: device not configured"?</heading>
+ <heading>怎麼會跑出 ``/dev/bpf0: device not configured'' 這個訊息?
+ </heading>
- <p>The Berkeley Packet Filter <htmlurl
- url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> driver
- needs to be enabled before running programs that utilize it.
- Add this to your kernel config file and build a new kernel:
+ <p>柏克萊封包過濾器(Berkeley Packet Filter) <htmlurl
+ url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)">
+ 在程式使用前必須在 kernel 打開它的驅動程式,把下面這一行加入 kernel
+ 設定檔中,編個新的 kernel:
pseudo-device bpfilter # Berkeley Packet Filter+ </verb>
- <p>Secondly, after rebooting you will have to create the device
- node. This can be accomplished by a change to the <tt>/dev</tt>
- directory, followed by the execution of:
+ <p>在重新開機之後,還要做出 device node,在 <tt>/dev</tt> 下執行:
- # sh MAKEDEV bpf0+ </verb></tscreen>
+ # sh MAKEDEV bpf0 </verb></tscreen>
+ <p>如果想要更進一步知道如何做出各種 device node,請看 <htmlurl
+ url="../handbook/kernelconfig:nodes.html"
+ name="handbook 中有關 device node 的說明">。
- <p>Please see the <htmlurl url="../../handbook/kernelconfig:nodes.html"
- name="handbook's entry on device nodes"> for more information
- on creating devices.