From 4eccc1e9878e83391a4294c7caf4791dd59826fa Mon Sep 17 00:00:00 2001 From: Foxfair Hu Date: Wed, 21 Apr 1999 05:26:08 +0000 Subject: 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 The translation of Handbook(new DocBook) is in progress , too. --- zh/FAQ/hackers.sgml | 648 ++++++++++++++------------- zh/FAQ/network.sgml | 1017 ++++++++++++++++++++----------------------- zh_TW.Big5/FAQ/hackers.sgml | 648 ++++++++++++++------------- zh_TW.Big5/FAQ/network.sgml | 1017 ++++++++++++++++++++----------------------- 4 files changed, 1600 insertions(+), 1730 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 @@ - + - + - For serious FreeBSD hackers only + 只給正經的 FreeBSD hacker 看 - - What are SNAPs and RELEASEs? - + SNAPs 和 RELEASEs 是什麼？ -

There are currently three active/semi-active branches in the FreeBSD +

目前有三個活躍/半活躍的分支在 FreeBSD 的 : - -

如同其他兩個，Right now, 以現在來說，The The - How do I make my own custom release? -

To make a release you need to do three things: First, you need to - be running a kernel with the driver configured - in. Add this to your kernel config file and build a new kernel: +

做 release 包括下面這三個步驟：首先，做出有 這個驅動程 + 式的可用 kernel。把下面這一行加到 kernel 設定檔，然後做出新的 + kernel 重新開機： pseudo-device vn #Vnode driver (turns a file into a device) -

Second, you have to have the whole CVS repository at hand. - To get this you can use - but in your supfile set the release name to cvs and remove any tag or - date fields: +

接著，你手上要有整個 CVS repository。可以參考 這篇文章，但在 supfile + 中把 release 名稱設成 cvs，再刪掉所有 tag 或 date 的欄位，如下： *default prefix=/home/ncvs @@ -72,12 +68,11 @@ doc-all -

Then run 然後執行 Finally, you need a chunk of empty space to build into. Let's - say it's in /some/big/filesystem, and from the example - above you've got the CVS repository in /home/ncvs: +

最後，硬碟要有相當大的空間來做 release。假設你想把它放在 + /some/big/filesystem 這裡，上面這個例子也把 CVS + repository 放在 /home/ncvs 了，接著： 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 -

An entire release will be built in - /some/big/filesystem/release and you will have a full FTP-type - installation in /some/big/filesystem/release/R/ftp when you're - done. If you want to build your SNAP along some other branch than - -current, you can also add 整個 release 會做在 /some/big/filesystem/release。結束 + 時 /some/big/filesystem/release/R/ftp 這個目錄可以直接用 + 來做為 FTP 安裝方式的來源。如果想做出 -current 以外分支的 SNAP， + 在上面 make release 這一行加 - How do I create customized installation disks? + 怎樣才能做出自己用的安裝磁片？ -

The entire process of creating installation disks and source and - binary archives is automated by various targets in - /usr/src/release/Makefile. 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. +

建立安裝磁片、還有做出 source/binary archive，都是由 + /usr/src/release/Makefile 裡面的各種 target 自動產生，這 + 個檔案裡的資訊應該足以開始。但是這個過程牽涉到 make world，所以會 + 用到相當多的時間和硬碟空間。 - ``make world'' clobbers my existing installed binaries. + ``make world'' 把原來裝的 binary 檔都換掉了。 -

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). +

沒錯，就是這樣子。如名字所示，``make world'' 會重新編譯系統內建 + 的每個 binary 檔，這樣在結束時就可確定有個一致且乾淨的環境(所以要 + 花上好一段時間)。 -

If the environment variable ${DESTDIR}. - Some random combination of shared libraries modifications and - program rebuilds can cause this to fail in ``在執行 ``${DESTDIR} 下的同樣目錄樹中。但在某些修 + 改 shared library 和重建 binary 的無特定情況下，這樣做可能會使 + `` - When my system boots, it says ``(bus speed defaulted)''. + 在系統開機時，出現 ``(bus speed defaulted)''。 -

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 ``Adaptec 1542 SCSI 卡允許使用者用軟體調整匯流排的存取速度。早 + 期的 1542 驅動程式試圖將它設成可用的最快速度，但後來發現在一些 + 機器上不能用，所以現在要在 kernel 設定中加 `` - Can I follow current with limited Internet access? -

Yes, you can do this +

可以，藉著 就 + 可以不用下傳所有的原始碼目錄樹。 - How did you split the distribution into 240k files? + 你是怎麼把發行版本中的檔案切成一個個 240k 的小檔案？ -

Newer BSD based systems have a ``在以 BSD 為主的較新系統中，split 有個 ``Here is an example from /usr/src/Makefile. +

這裡是 /usr/src/Makefile 中的一個例子： bin-tarball: @@ -160,166 +144,130 @@ - I've written a kernel extension, who do I send it to? + 我在 kernel 裡加了些新功能，要把它寄給誰？ -

Please take a look at +

請看一下 。 -

And thanks for the thought! +

同時也感謝你的費心！ - How are Plug N Play ISA cards detected and initialized? - -

By: - -

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 # 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 ``The IDs are two 32-bit fields (hence 2ˆ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. - -

The lower 32 bits are a serial #, 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. - -

The 32 bit groups can never be all zero. This allows the - wired-OR to show non-zero bits during the initial binary search. - -

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. - -

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. - -

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. - -

There is a lot of oversimplification above, but you should get - the general idea. - -

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 + ISA 的 Plug N Play 卡是怎麼偵測和初始化的？ + +

由 所寫： + +

簡單的說，當主機發出是否有 PnP 卡的詢問訊號時，所有的 PnP + 會在幾個固定的 I/O port 作回應。所以當偵測 PnP 的程式開始時，它 + 會先問有沒有 PnP 卡在，接著所有 PnP 卡會在它所讀的 port 以自己 + 的型號 # 作回答，這樣偵測程式就會得到一個 wired-OR ``yes'' + 的數字，其中至少會有一個 bit 是打開的。然後偵測程式會要求型號 + (由 Microsoft/Intel指定)小於 X 的卡``離線''，再去看是否還有卡回 + 答同樣的詢問，如果得到 ``一張卡的 ID 由兩個 32-bit(所以上面是 2ˆ64) + 8bit 偵錯 + 碼組成，第一個 32 bits 是用來區分各家廠商的。這些廠商沒有出來澄 + 清過，但看來應假設同一家出的不同種類的卡的廠商 ID 有可能不同。 + 用 32 bits 只來表示不同廠商的想法實在有點過頭了。 + +

第二個 32 bits 則是型號 &num、乙太網路位址、或一些使這張卡獨 + 特的資料。除非第一個 32 bits 不同，否則廠商不可能作出第二個 32 + bit 相同的兩張卡。所以在一台機器中可以有同樣的好幾張卡，然而他們 + 整個 64 bits 還是會都不一樣。 + +

這兩個 32 bit 永遠都不可能為零，這使得最開始 binary search 中 + 的 wired-OR 會得到一個非零數字。 + +

一旦系統區分出所有卡的 ID，接著會經由同樣的 port 一個個重新啟 + 動每張卡，接著找出已知介面卡所需的資源、有那些可以選的 interrupt + 等等。所有卡都會被掃描一次，來收集這些資料。 + +

這些資訊接著和硬碟上的 ECU 檔案、或 MLB BIOS 裡的資料結合在一 + 起，通常是綜合 ECU 和 MLB 裡的 BIOS PnP 資料，這些週邊並不支援真 + 正的 PnP，然而偵測程式在檢查 BIOS 和 ECU 資料後，它可以避免 PnP + 週邊和那些偵測不到的相衝突。 + +

接著再度拜訪這些 PnP 週邊，這次會把可用的 I/O、DMA、IRQ 和記 + 憶體映射的位址都指定給它們。這些週邊就會出現在所指定的地方，直到 + 下一次重新開機為止，不過也沒有人說不能把它們隨時移來移去。 + +

上面有相當多的簡化，但你應該已經了解大致的過程。 + +

Microsoft 把表示印表機狀態的幾個主要 port 拿來作 PnP，他們的 + 邏輯是沒有一張卡會在這些地方解碼作相反的 I/O cycles。但是我找到 + 一款早期仍在評估 PnP 提案時的 IBM 原廠 printer board，它的確去解 + 對這些狀態 port 的寫入資料，但是 MS ``說了就算''。所以它們的確有 + 對印表機狀態 port 寫入，還有讀取該位址 + - Does FreeBSD support architectures other than the x86? + FreeBSD 是否有支援 x86 以外的機器架構？ -

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 有幾群人士已經表示對發展多平台 FreeBSD 的興趣，其中 + FreeBSD/AXP (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 品質的軟體。若要相關狀況的消息，請加入 <freebsd-alpha@FreeBSD.ORG>. - Interest has also been expressed in a port of FreeBSD to - the SPARC architecture, join the <freebsd-sparc@FreeBSD.ORG> - if you are interested - in joining that project. For general discussion on new architectures, - join the <freebsd-platforms@FreeBSD.ORG> - . + 也有人表示過將 FreeBSD SPARC 版本的興趣，如果你想參加這個計畫， + 請加入 <freebsd-sparc@FreeBSD.ORG> + 。如果想要知道關於 + 新平台的討論，請加入 <freebsd-platforms@FreeBSD.ORG> + 。 - I need a major number for a device driver I've written. - -

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 - files.i386, a sample configuration file entry, and the - appropriate 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 - <freebsd-hackers@FreeBSD.ORG>. + 我剛剛寫了某個設備的驅動程式，能不能給它一個 major number？ + +

這要看你是否打算將這個驅動程式公開使用，如果是的話，請把它的原始 + 碼送一份給我們，還有 files.i386 修改的部份、kernel 設定 + 檔樣本、以及用來產生設備檔的 。 + 如果你不打算、或因為版權問題而不能公開的話，我們有特地保留 + character major number 32 和 block major number 8 給這方面的使用， + 直接用這兩個就好了。不論如何，我們都會很感激你能在 + <freebsd-hackers@FreeBSD.ORG> 發表驅動程式的消息。 - Alternative layout policies for directories - -

- 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.

+ 關於放置目錄和檔案 inode 作法上的相異 + +

在回答有關目錄放置方式不同的問題上，我在 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。不管怎樣， + 我的經驗指出這是一個已經充份實驗過的部份。

Kirk McKusick, September 1998

- Making the most of a kernel panic + 如何從 kernel panic 得到最多資訊？

- [This section was extracted from a mail written by on the - freebsd-current by , who fixed a few typos and added the bracketed - comments] + [這節是從 + 在 freebsd-current 上發表 + 的信中節錄， 修正了打字錯誤、再 + 加上括弧裡的注解。]

@@ -331,8 +279,7 @@ Cc: current@FreeBSD.ORG

- [<ben@rosengart.com> posted the following panic - message] + [<ben@rosengart.com> 發表了下面的 panic 訊息] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 @@ -350,112 +297,93 @@ Cc: current@FreeBSD.ORG > panic: page fault -

[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 - What you should do is this: +

當你看到像這樣的訊息時，只把它拷一份送上來是不夠的。我在上 + 面特地標明的 instruction pointer 值相當重要，不幸的是它會因設 + 定而不同。換句話說，這個值會跟你用的 kernel image 檔而變動。如 + 果是用某個 snapshot 版本的 GENERIC kernel，也許其他人可以追蹤 + 到出問題的函式，但如果你是用自訂的 kernel，那麼只有要做的事包括這些： - Write down the instruction pointer value. Note that the - When the system reboots, do the following: + 把 instruction pointer 的值記下來。注意在前面的 當系統重新開機後，執行這道命令： -% nm /kernel.that.caused.the.panic | grep f0xxxxxx +% nm /(造成 panic 的 kernel 檔案) | grep f0xxxxxx - where % 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 的函式列表。這樣比直接找到出問題的函式 + 來得差，但至少好過什麼都沒有。 -

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. +

我常常看到人們顯示一大片 panic 訊息，但很少看到有人花一點時間 + 把 instruction pointer 和 kernel symbol table 中的函式比較一下。 -

The best way to track down the cause of a panic is by - capturing a crash dump, then using 要追蹤出造成 panic 原因的最好方法是先做出 crash dump，然後用 + - In any case, the method I normally use is this: + 不管是那一種，我通常是用這個方法： - 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.) - Use 寫好 kernel 設定檔。如果你需要用 kernel debugger，在設定 + 檔中加上 `options DDB' 這個選項。(當我懷疑有出現無窮迴圈時，通 + 常會用這個來設定中斷點。) + 用 cd /sys/compile/KERNELCONFIG; make - Wait for kernel to finish compiling. + 等 kernel 編譯出來 cp kernel / - reboot + 重新開機 -

[Note: Now that FreeBSD 3.x kernels are Elf by default, - you should use - -

Note that YOU DO To make sure you capture a crash dump, you need edit - /etc/rc.conf and set /etc/rc.conf, the /var/crash. - -

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 /var/crash to hold the dump. - Alternatively, you run Once you have recovered the crash dump, you can get a stack - trace with [注意：現在 FreeBSD 3.x kernel 內定是 ELF 格式，所以應該 + 用 + +

注意你要確定能抓到 crash dump，先編輯 /etc/rc.conf，將 + /etc/rc.conf + 裡有設 /var/crash。 + +

注意：FreeBSD 的 crash dump 通常和機器裡的實際記憶體一樣大， + 就像如果有 64MB 記憶體，crash dump 大小就是 64MB。所以要確定 + /var/crash 下有足夠的空間，或是可以手動執行 一旦發現有了 crash dump，就可以用 @@ -463,30 +391,94 @@ Cc: current@FreeBSD.ORG (gdb) where -

Note that there may be several screens worth of information; - ideally you should use Now, if you're really insane and have a second computer, you - can also configure [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] +

要注意可能會出現好幾個螢幕的可用資訊，你可以用 好啦，如果你有第二台電腦而且有夠瘋狂，可以將 [Bill 附注：我忘了提到一點：如果你有啟動 DDB 而 kernel 也 + 已經進入除錯器，可以在 DDB 命令列下打 `panic'，強迫產生 panic(還 + 有 crash dump)。也有可能在 panic 階段時再進入除錯器，如果這樣的話 + ，輸入 `continue'，接著它就會完成 crash dump。 -ed] + + + dlsym() 對 ELF 執行檔不能用! + +

在 ELF 一系列的工具中，內定是不會讓 dynamic linker 看到執行檔 + 裡定義了那些 symbol。所以 dlsym() 沒有辦法用藉由呼叫 + dlopen(NULL, flags) 取得的 handle，用它去搜尋有那些 + symbol 一定會失敗。 + +

如果你想要用 dlsym() 找出某個 process 的主執行檔中 + 有那些 symbol，則要在 link 時對 + 加上 -export-dynamic 這個參數。 + + + 增加或減少 kernel 能定址的空間 + +

系統的內定是，FreeBSD 3.x kernel 能定址到 256 MB，4.x 則是 + 1 GB。如果是網路負荷相當重的伺服器(就像大型 FTP 或 HTTP 伺服器)， + 256 MB 可能會不大夠。 + +

要怎麼增加定址空間呢? 要從兩方面著手。首先告訴 kernel 本身要 + 保留較大空間; 其次，既然是在定址空間的最上面載入 kernel，所以還 + 要調低載入的位址，否則就會超過定址範圍。 + +

增加 src/sys/i386/include/pmap.h 裡的 +#ifndef NKPDE +#ifdef SMP +#define NKPDE 254 /* addressable number of page tables/pde's */ +#else +#define NKPDE 255 /* addressable number of page tables/pde's */ +#endif /* SMP */ +#endif + + +

要算出 要解決第二個問題，必須自行算出 kernel 被載入的位址：求出 + 0x100100000 減掉定址空間大小的值(以 byte 為單位)，如 1 GB 大小就 + 是 0xc0100000。把 src/sys/i386/conf/Makefile.i386 裡的 + src/sys/i386/conf/kernel.script 中)，如下： + + +OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") +OUTPUT_ARCH(i386) +ENTRY(btext) +SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib); +SECTIONS +{ + /* Read-only sections, merged into text segment: */ + . = 0xc0100000 + SIZEOF_HEADERS; + .interp : { *(.interp) } + + +

然後重新 config 和做出新的 kernel。在執行像 /usr/include/vm/ + 下，再手動編譯 注意：kernel 所能定址的空間大小必須是 4 megabytes 的倍數。 + +

[ + 加上這一段：我認為 kernel 定址空間大小應該是 2 的乘冪，但不大確 + 定這一點。舊的啟動程式會動到 high order address bits，記得它假設 + 至少有 256 MB。] + 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 @@ - + - + - Networking + 網路設定 我應該到哪邊找有關無磁碟開機 (diskless booting) 的資料?

無磁碟開機就是讓 FreeBSD 主機從網路上開機,並且從網路上的 server 上讀取 其他必要的檔案,而非由主機的硬碟上取得這些檔案。 詳細的資料可以參考 - @@ -92,19 +92,19 @@ name="slattach"> 處理有關撥出的功能。

這些程式有詳細的說明,你可以在 - 中找到: + 中找到: - - - - @@ -139,8 +139,8 @@

你應該先看看 和 - . 使用以下指令來打開記錄 (logging) 的功能 + 。使用以下指令來打開記錄 (logging) 的功能 set log Phase Chat Connect Carrier lcp ipcp ccp command @@ -200,43 +200,42 @@ default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 -

這些設定是假設您使用的 address 跟 handbook 裡面的設定, - 或是與 man page 的範例抑或是 ppp.conf.sample 這個檔案裡的設定相同. - 如果您沒有設定 default route, 那麼有可能您現在使用舊版本的 - that doesn't understand the - word 這些設定是假設您使用的 address 跟 handbook 裡面的、或是 man + page 的範例、或者和 ppp.conf.sample 裡的設定相同。如果您沒有設定 + default route，那麼有可能您現在使用舊版本的 ，舊的 + ppp 會看不懂 ppp.conf 裡的 add 0 0 HISADDR -

這一行成為 +

成為 add 0 0 10.0.0.2 -

default route 這行沒有出現的另一個原因是 - 你設錯了 default router , 這個設定在 - 檔案中 (這個檔案在 release 2.2.2 前叫 - /etc/sysconfig ), 你需要加入這麼一行 +

default route 這行沒有出現的另一個原因是你設錯了 default + router，這個設定在 檔案中(這個檔案在 release 2.2.2 前叫 + /etc/sysconfig)，你需要在 ppp.conf 中加入這 + 麼一行 delete ALL -

在 ppp.conf中. 如果發生這種情形, 回到 handbook - 的說明中查詢. +

如果發生這種情形, 回到 handbook + 的說明中查詢。 什麼叫做 "No route to host" -

This error is usually due to a missin這個狀況通常是因為缺少了這段設定 +

這個狀況通常是因為缺少了這段設定 MYADDR: @@ -244,274 +243,295 @@ default 10.0.0.2 UGSc 0 0 tun0 add 0 0 HISADDR -

請檢查您的 /etc/ppp/ppp.linkup 檔案中是否有這些設定. 只有在您 - 使用動態 IP (dynamic IP) 或不知道您 gateway 的 IP 時才需要設定這個. - 如果您是使用互動模式(interactive mode) 的話, 您可以 - type the following after entering 請檢查您的 /etc/ppp/ppp.linkup 檔案中是否有這些設定。 + 只有在您使用動態 IP(dynamic IP) 或不知道您 gateway 的 IP 時才需要 + 設定這個。如果您是使用 interactive mode 的話, 您可以在進入 packet + mode 後輸入如下命令(如果 ppp 提示符號變成大寫的 delete ALL add 0 0 HISADDR -

您可以參考 handbook 中 有較詳盡的說明. - +

您可以參考 handbook 中 的部份，有較詳盡的說明。 - 我的連線在等待三分鐘後切斷了 + 我的連線在三分鐘後自動斷掉了 -

ppp 預設的 timeout 值是三分鐘. 可以用以下這行命令調整 +

ppp 預設的 timeout 值是三分鐘。可以用以下這行命令調整 set timeout NNN -

ppp.conf 這個檔案裡面, 或是在 interactive mode 裡面輸入這個指令. - 也可以用 on the fly 的方式調整,在線路啟用並聯接到 - - 或 . 參考 - man - page 以獲得更詳盡的資料. +

這代表如果在 ppp.conf 這個檔案裡面，或是在 + interactive mode 裡面輸入這個指令，也可以用 或 + 連到 man page + 以獲得更詳盡的資料. 我的連線因為負荷太重而斷線 -

如果您設定了 Link Quality Reporting (LQR) , 就有可能 - 發生您和對方主機之間有太多的 LQR 封包遺失的現象. - Ppp 會因此判斷電話線路有問題. - , 並且決定切斷連線. 在 FreeBSD 2.2.5 版以前, - LQR 內定值是 enabled . 現在的內定值是 disabled. - LQR 可以用這一行命令取消 +

如果您設定要用 Link Quality Reporting(LQR)，您和對方主機之間就 + 有可能遺失太多的 LQR 封包。Ppp 會因此判斷電話線路有問題，然後就會 + 切斷連線。在 FreeBSD 2.2.5 版以前，內定會使用 LQR，現在的內定值是 + 不用。LQR 可以用這一行命令取消 disable lqr - 我的連線會不定時的斷掉 + ppp 會不定時的斷線 -

有時候如果線路上有太多噪訊,甚至如果您使用了話中插撥的服務的話. - , 您的 modem 將或 hang 住,因為他誤認這些訊息是 lost carrier. +

有時候如果線路上有太多雜訊，甚至如果您使用了電話插撥服務的話， + 您的數據機將會掛斷電話，因為它誤認這些訊息是 lost carrier。 -

大部分的 modem 都有容忍暫時失去 carrier 的設定. - . 以 USR Sportster 為例, this is measured by the S10 register in - tenths of a second. 如果要讓您的 modem 能容忍更大的錯誤, 你可以在您的 dial string - 裡面加入以下的 send-expect 命令: +

大部分的數據機都有容忍暫時失去 carrier 的設定。以 USR Sportster + 為例，失去 carrier 和掛斷電話之間的時間，是以 1/10 秒為單位存在 + S10 暫存器中。如果要讓您的數據機能容忍更長的時間，你可以在 dial + string 裡面加入以下 "送出命令 - 等待字串" 的部份： set dial "...... ATS10=10 OK ......" -

參考您的 modem 內附的說明書以取得更詳細的資料. +

參考數據機內附的說明書以取得更詳細的資料。 + + + 連線會不定時當掉 + +

許多人的連線會毫無來由的卡住，首先要做的是找出連線那一方當掉。 + +

如果用的是外接數據機，就用 知道是本地或對方出問題後，就有兩種可能： + + + 對方的機器沒有回應 + +

在這方面能作的相當有限，大部份的 ISP 會因為你不是用 Microsoft + 作業系統而不願幫忙。可以在 首先，用下面兩道命令關掉所有本地的壓縮功能： + + + disable pred1 deflate deflate24 protocomp acfcomp shortseq vj + deny pred1 deflate deflate24 protocomp acfcomp shortseq vj + + +

然後重新連線，確定這樣不會有所不同。如果反而有進步或甚至將問題 + 解決掉，就用試誤法來找出是那個設定造成的。這樣在聯絡 ISP 時就可以 + 提供相當有用的資料（雖然會很容易看出你不是用 Microsoft 的產品）。 + +

在聯絡 ISP 之前，打開本地的非同步記錄功能，接著就等連線再度當掉， + 這可能會用到相當大的硬碟空間。最後從連接埠讀進的資料可能會相當有用， + 它通常是 ASCII 文字，甚至有可能會說明問題出在那裡(``Memory fault, + core dumped''?)。 + +

如果 ISP 願意協助的話，應該會在他們那一端也打開記錄功能，那麼在 + 下次連線當掉時，就可以告訴你為何會出問題。很歡迎將詳細內容送到 ，甚至要 + 求 ISP 直接向我連絡。 + + + 自己的 Ppp 當掉了 +

這裡能做的最多就是重新編譯 ppp：在 Makefile 最後面加上 + 將結果送到 . 在看到 Login OK! 的訊息以後就沒有反應了 -

在 FreeBSD 2.2.5 以前的版本上, 一但連線建立完成以後, - 會等對方的機器啟動 Line Control - Protocol (LCP). 很多 ISP 不會自動啟動這個訊息交換,而是等 - 待 cleint 端啟動. 要強迫 在 FreeBSD 2.2.5 以前的版本上，一旦連線建立完成以後， + + 會等對方的機器啟動 Line Control Protocol (LCP)。很多 ISP 不會自動 + 啟動，而是等待由 client 端來啟動。要強迫 set openmode active -

我一直看到 magic being the same 的錯誤訊息 -

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. - -

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. - -

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. - -

This can be avoided by allowing the peer to start negotiating - with the following line in your ppp.conf file: +

有時就在連上之後，在記錄檔會看到 "magic is the same" 的訊息。通 + 常這些是無害的，有時候某一端則會斷線。大多數的 ppp 實作無法解決這個 + 問題，就算似乎連上了，在記錄檔也可以看到一直重複的 configure request + 和 configure acknowledgement 之類的溝通訊息，ppp 最後會放棄而關掉連 + 線。 + +

會發生這種問題的通常情況是，伺服器用速度慢的硬碟、在通訊埠上執行 + getty、並且等到使用者登入後才用 script 或程式執行 ppp；也有聽說用 + slirp 就一定會發生類似問題的報告。原因是在 getty 結束和 ppp 開始執行 + 的這段時間內，client 端的 ppp 開始送出 Line Control Protocol(LCP) 封 + 包，由於伺服器通訊埠的 ECHO 仍在打開狀態，client 端的 ppp 就會看到送 + 出去的封包被 "反彈" 回來。 + +

在用 LCP 溝通時，有部份是要連線兩邊分別建立自己的 magic number， + 來偵測及避免封包被 "反彈" 回來的狀況。協定標準中說當對方試圖用和自己 + 相同的 magic number 溝通時，要送給對方一個 NAK 的訊號（表示不接受）， + 接著對方就會選另一個數字。但在伺服器通訊埠 ECHO 仍打開的這段期間， + client 端的 ppp 送出 LCP 封包，看到相同的 magic number，於是送出 + NAK 訊號。這個 NAK 也會被 "反彈" 回來，被誤認由對方送出，因此 client + 端會改變自己的 magic number。這樣 magic number 的變動次數會非常地多， + 並且也全都存在對方的終端機緩衝區中。當伺服器啟動 ppp 時，它馬上就 + 被 magic number 的大量更動所淹沒，並且（幾乎是立刻）決定已經試夠了 + LCP 而放棄；在這期間，client 端雖然再也看不到被反彈的封包，但卻來得 + 及看到伺服器把電話線掛掉。 + +

允許讓對方來作 LCP 溝通可以避免這種情形，在 ppp.conf 中加下面這 + 一行： set openmode passive -

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: +

這行告訴 ppp 由對方來啟動 LCP，不過有些伺服器永遠都不會主動溝通 + ，在這種情況下，可以這麼設定： set openmode active 3 -

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. +

這是要 ppp 等個三秒鐘，然後再開始送 LCP 相關要求。如果對方在這 + 段時間送出 LCP 封包，ppp 就不會等足三秒而立刻回應。 - LCP negotiations continue 'till the connection is closed - - -

There is currently an implementation mis-feature in This goes on 'till one side figures out that they're getting - nowhere and gives up. - -

The best way to avoid this is to configure one side to be - + +

目前 假設有兩端 這種惡性循環會一直持續著，直到有一方發現自己在原地打轉而放棄繼續 + 下去。 + +

避免這種情況的最好方式，是將某一端設成 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 set openmode active N - command (where - Ppp locks up shortly after connecting + Ppp 在連線後就卡住了 -

Prior to version 2.2.5 of FreeBSD, it was possible that your - link was disabled shortly after connection due to 在 FreeBSD 2.2.5 之前的版本，有可能因為 disable pred1 - Ppp locks up when I shell out to test it + 用 shell 跳出 Ppp 做測試時，連線似乎卡住了 -

When you execute the 在用 If you wish to execute commands like this, use the - 如果想執行程式，用 - Ppp over a null-modem cable never exits + 在 null-modem 線上建立的 Ppp 好像不會自動斷線 -

There is no way for 由於 null-modem 本身用的線材， enable lqr -

LQR is accepted by default if negotiated by the peer. +

內定是會接受 LQR，如果對方用它來溝通的話。 - Why does ppp dial for no reason in -auto mode + 為什麼 ppp 在 -auto 模式下會無緣無故播號？ -

If 如果 To determine the cause, use the following line: +

要找出原因，先用這個命令： set log +tcp/ip -

This will log all traffic through the connection. The next - time the line comes up unexpectedly, you will see the reason - logged with a convenient timestamp next to it. +

這樣會記錄經由連線的所有資料。下次如果又無故播號，就可以從記錄 + 旁邊的時間很快找到原因。 -

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 現在可以避免因為這些原因播號。通常是在作 DNS 查詢時才會發生這種 + 問題，要避免因 DNS 查詢而連線（這樣 set dfilter 1 deny udp src eq 53 @@ -519,117 +539,99 @@ default 10.0.0.2 UGSc 0 0 tun0 set dfilter 3 permit 0/0 0/0 -

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. +

這種做法並不永遠適用，因為它事實上使得你無法用 demand-dial 功能 + － 大部份程式在做網路相關動作前都會用到 DNS 查詢。 -

In the DNS case, you should try to determine what is actually - trying to resolve a host name. A lot of the time, - 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 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 - 在 DNS 這個情況下，應該試著找出到底是誰想要解出主機名稱，通常幾 + 乎都是由 所造成，所以要在 sendmail 設定檔中指示它不要做任何 + DNS 查詢。在 中有詳細說明如何作出 + 自己的設定檔、及裡面應該放那些設定，你也許想要將下一行加入 define(`confDELIVERY_MODE', `d')dnl -

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). +

這會使 sendmail 先擋著所有信件，直到送信時再一齊送出去（通常 + sendmail 執行時是用 ``-bd -q30m'' 這個參數，告訴它每三十分鐘才送信） + 或是有人執行 ``sendmail -q''（也許可以放在 ppp.linkup 裡）。 - What do these CCP errors mean + 這些 CCP 錯誤訊息是指？ -

I keep seeing the following errors in my log file: +

我在 log 檔一直看到這些錯誤訊息： CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) -

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: +

這是因為 ppp 試圖作 Predictor1 壓縮方面的溝通，但對方的機器卻完 + 全不用壓縮功能。這些訊息是無害的，但如果不想看到它的話，可以把本地 + ppp 的 Predictor1 壓縮也一起關掉： disable pred1 - Ppp locks up during file transfers with IO errors + 傳檔案時發生 IO 錯誤，然後 Ppp 就掛掉了 -

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. +

在 FreeBSD 2.2.2 及先前的版本中，tun 的驅動程式有個問題，它不會 + 接收那些大過 tun 介面 MTU 的封包。如果收到比 MTU 大的封包，它會用 + syslogd 記錄為 IO 錯誤。 -

The ppp specification says that an MRU of 1500 should - always 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. +

但 ppp 規格中有提到，不管 LCP 溝通的結果如何，MRU 最小的可接受 + 值永遠是 1500。所以有可能你不小心將 MTU 調低於 1500，ISP + 會不理它而送出 1500 大小的封包，然後就會觸發上述的 "功能"。 -

The problem can be circumvented by never setting an MTU of - less than 1500 under FreeBSD 2.2.2 or before. +

在 FreeBSD 2.2.2 及之前的版本中，永遠不要將 MTU 調低於 1500，就 + 可以解決這個問題。 - Why doesn't ppp log my connection speed? + 為什麼 ppp 不會記錄我的連線速度？ -

In order to log all lines of your modem ``conversation'', - you must enable the following: +

如果要記錄電腦和數據機間的每一行 ``對話''，用下一行打開： set log +connect -

This will make - - log everything up until the last requested "expect" string. +

這會使 記錄所有資料，直到播號字串最後一個等待的數據機傳回值 + 為止。 -

If you wish to see your connect speed and are using PAP or CHAP - (and therefore 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: +

如果使用 PAP 或 CHAP (因為沒有 "set login" 命令，所以設定檔中 + CONNECT 之後就不會看到任何對話)，想要看到連線速度的話，確定 ppp + 等待的數據機傳回值是 CONNECT 這一整行，像這樣： set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" -

Here, we get our CONNECT, send nothing, then expect a line-feed, - forcing 這樣在看到 CONNECT 後不會送出任何東西，接著再等個換行字元，強 + 迫 - Ppp ignores the `\' character in my chat script + Ppp 不理會 chat script 中的 `\' 字元 -

Ppp parses each line in your config files so that it can - interpret strings such as Ppp 會去分析設定檔中的每一行，這樣它才會正確解讀像是 + 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'' ``\T'' + 的跳脫字元（見 man page），必須重新解譯該參數。在這種雙重分析之下， + 你必須記得用正確的跳脫數目。 -

If you wish to actually send a ``\'' character to (say) your - modem, you'd need something like: +

假設要對數據機送出 ``\'' 這個字元，應該像是： set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" -

resulting in the following sequence: +

這樣則會得到下面這串： ATZ @@ -638,14 +640,14 @@ default 10.0.0.2 UGSc 0 0 tun0 OK -

or +

如果是 set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" -

resulting in the following sequence: +

則會得到下面結果： ATZ @@ -654,16 +656,14 @@ default 10.0.0.2 UGSc 0 0 tun0 - Ppp gets a seg-fault, but I see no + Ppp 碰到了 seg-fault，但找不到 -

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 Ppp (或任何類似的程式) 應該不可能有 core dump。由於 ppp 執行時 + 的 effective user id 是 0 (即以 root 身份執行)，作業系統在終止 ppp + 前不會對磁碟寫它的 core 映像檔。如果 ppp $ tar xfz ppp-*.src.tar.gz @@ -676,14 +676,11 @@ default 10.0.0.2 UGSc 0 0 tun0 # chmod 555 /usr/sbin/ppp -

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. +

你現在已經裝上可以用來除錯的 ppp 版本，由於權限上沒有作特別設定， + 所以必須以 root 來執行 ppp，順便也要注意是在那個目錄執行的。 -

Now, if and when ppp receives the segmentation violation, it - will dump a core file called ppp.core. You should then do the - following: +

現在如果 ppp 碰到了 segmentation violation，就會將 coredump 存在 + ppp.core 檔中，接下來就是： $ su @@ -698,177 +695,149 @@ default 10.0.0.2 UGSc 0 0 tun0 ..... -

All of this information should be given alongside your - question, making it possible to diagnose the problem. -

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. +

根據你的問題來取得相關資料，就可以診斷問題出在那裡。 + +

如果熟悉 gdb，也許會想找出其他的詳細資料，像是那個動作造成 + dump、及相關變數的位址及數值等。 - The process that forces a dial in auto mode never connects + 在 -auto 模式下，使 ppp 播號的程式在連線後卻連不到目的地 -

This was a known problem with The problem was that when that initial program calls - , 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. There are several theoretical ways to approach this problem. - It would be nicest if the peer would re-assign the same IP number - if possible The 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 - - and ppp's Another alternative (and probably the most reliable) would be - to implement a system call that changes all bound sockets from one - IP to another. Yet another possibility is to allow an interface to be brought - up without an IP number. Outgoing packets would be given - an IP number of 255.255.255.255 up until the first SIOCAIFADDR - ioctl is done. This would result in fully binding the socket. It - would be up to 這是設定 當用到網路的程式呼叫 + 時，socket endpoint 會設成 tun 這個界面的 IP，kernel 接著產生要送出 + 去的第一個封包，把它傳給 tun，理論上，有好幾種方法可以解決這個問題。如果 ISP 願意每次都提供相同 + IP 當然是最好 從 client 端最容易的解決方式是，永遠都不要改變 tun 界面的 IP 值， + 但是將所有出去的封包來源 IP 從原先的 tun 界面 IP 改為連線時取得的 + IP，基本上這就是最新版 和執行 ppp 時的 另一種方法（可能是最可靠）是寫個可以修改所有 socket endpoint 值的 + system call。當拿到新的 IP 時，還有一個可能則是允許不用 IP，就可以啟用某個網路界面。送出去的封包 + 來源 IP 會設成 255.255.255.255，直到 SIOCAIFADDR 這個 ioctl 第一次執 + 行完成為止。這樣會完全連結 socket 的兩端，而由 - Why don't most games work with the -alias switch - -

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. - -

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. - -

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: + 為何玩大多數遊戲時，都不能使用 -alias 這個參數？ + +

遊戲或類似程式不能和 libalias 搭配使用的原因是，外面的機器試著對 + 著內部的機器開啟連線、或（不請自來地）送出 UDP 封包，而 alias 封包的 + 軟體不知道它應該把這些封包送到裡面的機器去。 + +

解決的方式是，先確定現在只有執行那個會出問題的程式，然後在 + gateway 機器上對 tun 界面執行 tcpdump、或在上面打開記錄 tcp/ip 的功 + 能（``set log +tcp/ip''）。 + +

在啟動出問題的程式時，應該會在 gateway 機器上看到有封包通過，當外 + 界有傳回封包時則會被丟掉（這就是問題所在）。記下這些封包要送到目的地 + 的那個埠，然後關掉程式。重複幾次，看看是否都要送到同樣固定的埠，如果 + 是的話，在 /etc/ppp/ppp.conf 相關位置加上這一行，就可使程式正確運作： alias port proto internalmachine:port port -

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. +

其中 ``proto'' 是 ``tcp'' 或 ``udp''，``internalmachine'' 是要接 + 收這些封包的機器，``port'' 則是這些封包要送到那個埠。 -

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. +

如果要在其他機器上執行同樣程式，必須重複同樣過程修改上一行設定， + 否則就不能正常使用；也不可能在兩台內部機器上同時使用－畢竟外界只是把 + 這個內部網路看成一台機器而已。 -

If the port numbers aren't consistent, there are three more - options: +

如果封包不一定送到同樣的埠，你有三種選擇： -

1) 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. +

1) 在 libalias 加入對它的支援， + /usr/src/lib/libalias/alias_*.c 有一些 ``特例'' 的示範（alias_ftp.c + 是個不錯的原型檔）。通常是讀取某些可以認得出的外送封包，找出要外面連 + 到內部機器某個埠的指令，然後在 alias 表中設定 ``route''，以後再收到 + 這種封包就知道要往那裡送。 -

This is the most difficult solution, but it is the best and - will make the software work with multiple machines. +

這是最困難的解法，但也是最好的，並且還可以在多台機器上用同樣程式。 -

2) 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. +

2) 使用 proxy。舉例來說，該應用程式也許支援 socks5，或是 + 有個 ``passive'' 的選項（像是 ``cvsup''）可以避免對方向內部機器提出 + 連線的要求。 -

3) Redirect everything to the internal machine using - ``alias addr''. This is the sledge-hammer approach. +

3) 用 ``alias addr'' 把所有資料都轉給內部機器，這是最後 + 才用的暴力法。 + + + 那裡可以找到常用埠的列表？ + +

現在還沒有，但可以將這些弄成一個名單（如果有人感興趣的話）： + + + Quake +

Quake 是說用 UDP 6112 這個埠，所以如果 Quake 伺服器的 IP 是 + hostmachine，那麼 + alias port udp hostmachine:6112 6112 這一行應該就可以正 + 常運作。如果想用其他方式， + 有 Quake 對 proxy 支援的說明。 + - What are FCS errors ? - -

FCS stands for show hdlc command. - -

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. - -

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 must use - software flow control, use the command - set accmap 0x000a0000 to tell ppp to escape - the ^Q and ^S characters. - -

Another reason for seeing too many FCS errors may be that - the remote end has stopped talking close lcp command (a following term command - will reconnect you to the shell on the remote machine. - -

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. + 什麼是 FCS 錯誤？ + +

FCS 是 show hdlc 便可看到 HDLC 裡的各種錯誤計數值。 + +

不良線路(或封包被串列埠的驅動程式丟掉)有時候就會發生 FCS 錯誤， + 雖然它的確會大大拖慢壓縮協定，不過通常這沒什麼大不了。如果你用的 + 是外接數據機，確定有保護線路不受外界干擾 － 這樣說不定就解決了。 + +

如果在連上時馬上就凍住、並且還看到一大堆 FCS 錯誤的話，有可能 + 是因為你的連線並非是 8 bit clean。確定數據機不是用軟體流程控制 + (XON/XOFF)，如果你的連線一定要用軟體流程控制的話，用 + set accmap 0x000a0000 這道命令告訴 ppp 跳過 ^Q + 和 ^S 這兩個字元。 + +

看到一大堆 FCS 錯誤的另一個原因，是連線另一端不再使用 close lcp、接著 term 就可以重新連接到對 + 方機器的 shell 下，而不用掛掉電話線。 + +

如果記錄檔裡沒有任何資訊可以指示連線為何斷掉，那麼就該問問另一 + 端的管理員(你的 ISP？) 怎麼會這樣結束。 - None of this helps - I'm desperate ! - -

If all else fails, send as much information as you can, - including your config files, how you're starting command (before and after connecting) to the - mailing list or the + 沒有一個方法可以用，我完蛋了啦！ + +

如果上面說的都沒用，就盡可能找出所有資訊，這包括了設定檔、如何 + 啟動 + 輸出結果，把這些送到 mailing list 或 news group, and someone - should point you in the right direction. + name="comp.unix.bsd.freebsd.misc"> newsgroup，這樣應該就會有人指點 + 正確的方向。 我沒有辦法建立 /dev/ed0 這個 device! @@ -908,7 +877,7 @@ default 10.0.0.2 UGSc 0 0 tun0

某些 PC 的網路卡比其他的好(含蓄的說來) 這種狀況在造成 NFS 這種對網路敏感的程式有時會出現問題. -

參考 +

參考 以獲得這個主題的更多資訊. @@ -989,180 +958,154 @@ default 10.0.0.2 UGSc 0 0 tun0 - 為什麼我的主機要提供 FQDN ? - -

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''. - -

Traditionally, this was allowed by BSD BIND resolvers. However - the current version of 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 mumble must either be found - as mumble.foo.bar.edu, or it will be searched for - in the root domain. - -

This is different from the previous behavior, where the - search continued across mumble.bar.edu, and - mumble.edu. Have a look at RFC 1535 for why this - was considered bad practice, or even a security hole. - -

As a good workaround, you can place the line + 為什麼要用 FQDN 才能連到其他機器？ + +

你也許會發現要連的機器其實是在另一個網域。舉個例子，假設你是在 + foo.bar.edu 這個網域中，想要連到在 bar.edu 裡一台叫 ``mumble'' 的 + 機器，則必須用 Fully-Qualified Domain Name，也就是 + ``mumble.bar.edu''，而不是只用 ``mumble'' 來指向它。 + +

傳統的 BSD BIND resolver 允許用這種方式解出機器的位址，但是 + FreeBSD 內附 版本 + 的內定方式，則是除了你所在的網域以外，不支援其他非 FQDN 的縮寫。 + 所以如 mumble 這種不合格的機器名稱，必須在 + mumble.foo.bar.edu，否則就會從網域的最底層開始找。 + +

這和先前的做法不同，也就是不用 mumble.bar.edu 和 + mumble.edu 繼續搜尋。看一下 RFC 1535，裡面有提到為什麼之 + 前的做法不好，甚至算是個安全漏洞。 + +

這裡有個不錯的解法，把 + 裡的這一行： - search foo.bar.edu bar.edu + domain foo.bar.edu -

instead of the previous + 換成這一行： - domain foo.bar.edu + search foo.bar.edu bar.edu -

into your 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''。 - ``Permission denied'' for all networking operations. + 所有網路動作都會出現 ``Permission denied'' 錯誤訊息 -

If you have compiled your kernel with the 如果在編譯 kernel 時加了 If you had unintentionally misconfigured your system for - firewalling, you can restore network operability by typing - the following while logged in as root: +

如果不小心弄錯了 firewall 的設定，以 root 身份執行這個命令，接著 + 網路功能就會正常： ipfw add 65534 allow all from any to any -

You can also set "firewall_type='open'" in /etc/rc.conf. +

也可以在 /etc/rc.conf 設 "firewall_type='open'" 這個選項。 -

For further information on configuring a FreeBSD firewall, - see the . +

如果想知道如何設定 FreeBSD firewall，請看 。 - How much overhead does IPFW incur? + IPFW 會造成多大的網路延遲？ -

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. +

這個問題的答案大多要看你怎麼訂 firewall 規則、還有 CPU 速度。對大 + 多數在 ethernet 上的程式及規則不多的情況下，延遲小到可以忽略。但如果 + 你想要精確數字來滿足好奇心，繼續往下讀。 -

The following measurements were made using 2.2.5-STABLE on - a 486-66. IPFW was modified to measure the time spent within - the 下面是在 486-66 2.2.5-STABLE 上所作的測量，我們修改了 IPFW 原始碼 + 來測量在 Two rule sets, each with 1000 rules were tested. The first set - was designed to demonstrate a worst case scenario by repeating the - rule: +

測試了兩組，每組各有 1000 個規則。第一組重複下面規則，故意設計成 + 最糟的情況： ipfw add deny tcp from any to any 55555 -

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 allow ip - from any to any. +

藉由檢查 port number，這樣會使 IPFW 在決定某個封包不符合條件前執 + 行大部份的檢查程式，因此造成最差的狀況。在重複這個規則 999 次後，接 + 著是 allow ip from any to any。 -

The second set of rules were designed to abort the rule - check quickly: +

第二組設計成以極快的速度跳過檢查規則： ipfw add deny ip from 1.2.3.4 to 1.2.3.4 -

The nonmatching source IP address for the above rule causes - these rules to be skipped very quickly. As before, the 1000th - rule was an allow ip from any to any. +

一碰到封包的來源不符合規則所述，會很快跳過檢查讓封包通過。和上面 + 一樣，第 1000 個規則是 allow ip from any to any。 -

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. +

在第一種情況中，處理每一個封包所造成的延遲大約是 2.703 ms，所以每 + 個規則大概會造成 2.7 microsecond 的延遲。所以在這些規則之下，理論上每 + 秒最多可以處理 370 個封包。在 10Mbps ethernet 和一個封包大概 1500 byte + 的假設下，大概只會用到 55.5% 的網路頻寬。 -

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. +

第二種情況，每個封包花了大約 1.172ms，所以每條規則大約用了 1.2 + microsecond。理論上每秒最多可以處理 853 個封包，耗盡 10Mbps 的頻寬。 -

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: +

上面測試用到的大量規則、及這些規則本身並不代表真實世界的情況，他們 + 只是用來產生所表示的數據。若想要訂出一套有效率的規則，記得這幾件事： - Place an `established' rule early on to handle the - majority of TCP traffic. Don't put any allow tcp - statements before this rule. + 在最前面放一個專門處理大量 TCP 流量的可用規則，在這條前面不 + 要放任何 allow tcp 的相關敘述。 - Place heavily triggered rules earlier in the rule - set than those rarely used (without changing the - permissiveness of the firewall, of course). You can see - which rules are used most often by examining the packet counting - statistics with ipfw -a l. + 把常常觸發的規則放在前面，不常用到的則丟到後面(當然在不 + 影響 firewall 出入允許設定的前提下)。執行 ipfw -a l + 就可看到封包的統計數目，來看最常用到那些規則。 - How can I redirect service requests from one machine to another? + 要如何把對某台機器的網路服務要求(service request)轉向到另一台？ -

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: +

在 ports 目錄的 sysutils 種類中有個叫 'socket' 的 package，可以幫 + 你轉向 FTP 或其他類似的網路服務。只要把該網路服務的命令改成呼叫 socket + 即可，如下(在 /etc/inetd.conf 裡)： ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -

where 'ftp.foo.com' and 'ftp' are the host and port to redirect to, - respectively. - +

其中 'ftp.foo.com' 和 'ftp' 分別是被轉到的機器和 port 名稱。 + - Where can I get a bandwidth management tool? + 那裡可以找到管理頻寬的工具？ -

There are two bandwidth management tools available for FreeBSD. +

FreeBSD 上有兩套頻寬管理工具： is available for free; Bandwidth Manager from - is - a commercial product. - + name="ALTQ"> 可以免費使用， + 出的 + Bandwidth Manager 則是商用軟體。 - Why do I get ``/dev/bpf0: device not configured"? + 怎麼會跑出 ``/dev/bpf0: device not configured'' 這個訊息？ + -

The Berkeley Packet Filter driver - needs to be enabled before running programs that utilize it. - Add this to your kernel config file and build a new kernel: +

柏克萊封包過濾器(Berkeley Packet Filter) + 在程式使用前必須在 kernel 打開它的驅動程式，把下面這一行加入 kernel + 設定檔中，編個新的 kernel： pseudo-device bpfilter # Berkeley Packet Filter+ -

Secondly, after rebooting you will have to create the device - node. This can be accomplished by a change to the /dev - directory, followed by the execution of: +

在重新開機之後，還要做出 device node，在 /dev 下執行： - # sh MAKEDEV bpf0+ + # sh MAKEDEV bpf0 + +

如果想要更進一步知道如何做出各種 device node，請看 。 -

Please see the for more information - on creating devices. diff --git a/zh_TW.Big5/FAQ/hackers.sgml b/zh_TW.Big5/FAQ/hackers.sgml index 3ddcd8a408..99fc61bd7d 100644 --- a/zh_TW.Big5/FAQ/hackers.sgml +++ b/zh_TW.Big5/FAQ/hackers.sgml @@ -1,58 +1,54 @@ - + - + - For serious FreeBSD hackers only + 只給正經的 FreeBSD hacker 看 - - What are SNAPs and RELEASEs? - + SNAPs 和 RELEASEs 是什麼？ -

There are currently three active/semi-active branches in the FreeBSD +

目前有三個活躍/半活躍的分支在 FreeBSD 的 : - -

如同其他兩個，Right now, 以現在來說，The The - How do I make my own custom release? -

To make a release you need to do three things: First, you need to - be running a kernel with the driver configured - in. Add this to your kernel config file and build a new kernel: +

做 release 包括下面這三個步驟：首先，做出有 這個驅動程 + 式的可用 kernel。把下面這一行加到 kernel 設定檔，然後做出新的 + kernel 重新開機： pseudo-device vn #Vnode driver (turns a file into a device) -

Second, you have to have the whole CVS repository at hand. - To get this you can use - but in your supfile set the release name to cvs and remove any tag or - date fields: +

接著，你手上要有整個 CVS repository。可以參考 這篇文章，但在 supfile + 中把 release 名稱設成 cvs，再刪掉所有 tag 或 date 的欄位，如下： *default prefix=/home/ncvs @@ -72,12 +68,11 @@ doc-all -

Then run 然後執行 Finally, you need a chunk of empty space to build into. Let's - say it's in /some/big/filesystem, and from the example - above you've got the CVS repository in /home/ncvs: +

最後，硬碟要有相當大的空間來做 release。假設你想把它放在 + /some/big/filesystem 這裡，上面這個例子也把 CVS + repository 放在 /home/ncvs 了，接著： 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 -

An entire release will be built in - /some/big/filesystem/release and you will have a full FTP-type - installation in /some/big/filesystem/release/R/ftp when you're - done. If you want to build your SNAP along some other branch than - -current, you can also add 整個 release 會做在 /some/big/filesystem/release。結束 + 時 /some/big/filesystem/release/R/ftp 這個目錄可以直接用 + 來做為 FTP 安裝方式的來源。如果想做出 -current 以外分支的 SNAP， + 在上面 make release 這一行加 - How do I create customized installation disks? + 怎樣才能做出自己用的安裝磁片？ -

The entire process of creating installation disks and source and - binary archives is automated by various targets in - /usr/src/release/Makefile. 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. +

建立安裝磁片、還有做出 source/binary archive，都是由 + /usr/src/release/Makefile 裡面的各種 target 自動產生，這 + 個檔案裡的資訊應該足以開始。但是這個過程牽涉到 make world，所以會 + 用到相當多的時間和硬碟空間。 - ``make world'' clobbers my existing installed binaries. + ``make world'' 把原來裝的 binary 檔都換掉了。 -

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). +

沒錯，就是這樣子。如名字所示，``make world'' 會重新編譯系統內建 + 的每個 binary 檔，這樣在結束時就可確定有個一致且乾淨的環境(所以要 + 花上好一段時間)。 -

If the environment variable ${DESTDIR}. - Some random combination of shared libraries modifications and - program rebuilds can cause this to fail in ``在執行 ``${DESTDIR} 下的同樣目錄樹中。但在某些修 + 改 shared library 和重建 binary 的無特定情況下，這樣做可能會使 + `` - When my system boots, it says ``(bus speed defaulted)''. + 在系統開機時，出現 ``(bus speed defaulted)''。 -

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 ``Adaptec 1542 SCSI 卡允許使用者用軟體調整匯流排的存取速度。早 + 期的 1542 驅動程式試圖將它設成可用的最快速度，但後來發現在一些 + 機器上不能用，所以現在要在 kernel 設定中加 `` - Can I follow current with limited Internet access? -

Yes, you can do this +

可以，藉著 就 + 可以不用下傳所有的原始碼目錄樹。 - How did you split the distribution into 240k files? + 你是怎麼把發行版本中的檔案切成一個個 240k 的小檔案？ -

Newer BSD based systems have a ``在以 BSD 為主的較新系統中，split 有個 ``Here is an example from /usr/src/Makefile. +

這裡是 /usr/src/Makefile 中的一個例子： bin-tarball: @@ -160,166 +144,130 @@ - I've written a kernel extension, who do I send it to? + 我在 kernel 裡加了些新功能，要把它寄給誰？ -

Please take a look at +

請看一下 。 -

And thanks for the thought! +

同時也感謝你的費心！ - How are Plug N Play ISA cards detected and initialized? - -

By: - -

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 # 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 ``The IDs are two 32-bit fields (hence 2ˆ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. - -

The lower 32 bits are a serial #, 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. - -

The 32 bit groups can never be all zero. This allows the - wired-OR to show non-zero bits during the initial binary search. - -

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. - -

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. - -

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. - -

There is a lot of oversimplification above, but you should get - the general idea. - -

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 + ISA 的 Plug N Play 卡是怎麼偵測和初始化的？ + +

由 所寫： + +

簡單的說，當主機發出是否有 PnP 卡的詢問訊號時，所有的 PnP + 會在幾個固定的 I/O port 作回應。所以當偵測 PnP 的程式開始時，它 + 會先問有沒有 PnP 卡在，接著所有 PnP 卡會在它所讀的 port 以自己 + 的型號 # 作回答，這樣偵測程式就會得到一個 wired-OR ``yes'' + 的數字，其中至少會有一個 bit 是打開的。然後偵測程式會要求型號 + (由 Microsoft/Intel指定)小於 X 的卡``離線''，再去看是否還有卡回 + 答同樣的詢問，如果得到 ``一張卡的 ID 由兩個 32-bit(所以上面是 2ˆ64) + 8bit 偵錯 + 碼組成，第一個 32 bits 是用來區分各家廠商的。這些廠商沒有出來澄 + 清過，但看來應假設同一家出的不同種類的卡的廠商 ID 有可能不同。 + 用 32 bits 只來表示不同廠商的想法實在有點過頭了。 + +

第二個 32 bits 則是型號 &num、乙太網路位址、或一些使這張卡獨 + 特的資料。除非第一個 32 bits 不同，否則廠商不可能作出第二個 32 + bit 相同的兩張卡。所以在一台機器中可以有同樣的好幾張卡，然而他們 + 整個 64 bits 還是會都不一樣。 + +

這兩個 32 bit 永遠都不可能為零，這使得最開始 binary search 中 + 的 wired-OR 會得到一個非零數字。 + +

一旦系統區分出所有卡的 ID，接著會經由同樣的 port 一個個重新啟 + 動每張卡，接著找出已知介面卡所需的資源、有那些可以選的 interrupt + 等等。所有卡都會被掃描一次，來收集這些資料。 + +

這些資訊接著和硬碟上的 ECU 檔案、或 MLB BIOS 裡的資料結合在一 + 起，通常是綜合 ECU 和 MLB 裡的 BIOS PnP 資料，這些週邊並不支援真 + 正的 PnP，然而偵測程式在檢查 BIOS 和 ECU 資料後，它可以避免 PnP + 週邊和那些偵測不到的相衝突。 + +

接著再度拜訪這些 PnP 週邊，這次會把可用的 I/O、DMA、IRQ 和記 + 憶體映射的位址都指定給它們。這些週邊就會出現在所指定的地方，直到 + 下一次重新開機為止，不過也沒有人說不能把它們隨時移來移去。 + +

上面有相當多的簡化，但你應該已經了解大致的過程。 + +

Microsoft 把表示印表機狀態的幾個主要 port 拿來作 PnP，他們的 + 邏輯是沒有一張卡會在這些地方解碼作相反的 I/O cycles。但是我找到 + 一款早期仍在評估 PnP 提案時的 IBM 原廠 printer board，它的確去解 + 對這些狀態 port 的寫入資料，但是 MS ``說了就算''。所以它們的確有 + 對印表機狀態 port 寫入，還有讀取該位址 + - Does FreeBSD support architectures other than the x86? + FreeBSD 是否有支援 x86 以外的機器架構？ -

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 有幾群人士已經表示對發展多平台 FreeBSD 的興趣，其中 + FreeBSD/AXP (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 品質的軟體。若要相關狀況的消息，請加入 <freebsd-alpha@FreeBSD.ORG>. - Interest has also been expressed in a port of FreeBSD to - the SPARC architecture, join the <freebsd-sparc@FreeBSD.ORG> - if you are interested - in joining that project. For general discussion on new architectures, - join the <freebsd-platforms@FreeBSD.ORG> - . + 也有人表示過將 FreeBSD SPARC 版本的興趣，如果你想參加這個計畫， + 請加入 <freebsd-sparc@FreeBSD.ORG> + 。如果想要知道關於 + 新平台的討論，請加入 <freebsd-platforms@FreeBSD.ORG> + 。 - I need a major number for a device driver I've written. - -

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 - files.i386, a sample configuration file entry, and the - appropriate 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 - <freebsd-hackers@FreeBSD.ORG>. + 我剛剛寫了某個設備的驅動程式，能不能給它一個 major number？ + +

這要看你是否打算將這個驅動程式公開使用，如果是的話，請把它的原始 + 碼送一份給我們，還有 files.i386 修改的部份、kernel 設定 + 檔樣本、以及用來產生設備檔的 。 + 如果你不打算、或因為版權問題而不能公開的話，我們有特地保留 + character major number 32 和 block major number 8 給這方面的使用， + 直接用這兩個就好了。不論如何，我們都會很感激你能在 + <freebsd-hackers@FreeBSD.ORG> 發表驅動程式的消息。 - Alternative layout policies for directories - -

- 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.

+ 關於放置目錄和檔案 inode 作法上的相異 + +

在回答有關目錄放置方式不同的問題上，我在 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。不管怎樣， + 我的經驗指出這是一個已經充份實驗過的部份。

Kirk McKusick, September 1998

- Making the most of a kernel panic + 如何從 kernel panic 得到最多資訊？

- [This section was extracted from a mail written by on the - freebsd-current by , who fixed a few typos and added the bracketed - comments] + [這節是從 + 在 freebsd-current 上發表 + 的信中節錄， 修正了打字錯誤、再 + 加上括弧裡的注解。]

@@ -331,8 +279,7 @@ Cc: current@FreeBSD.ORG

- [<ben@rosengart.com> posted the following panic - message] + [<ben@rosengart.com> 發表了下面的 panic 訊息] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 @@ -350,112 +297,93 @@ Cc: current@FreeBSD.ORG > panic: page fault -

[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 - What you should do is this: +

當你看到像這樣的訊息時，只把它拷一份送上來是不夠的。我在上 + 面特地標明的 instruction pointer 值相當重要，不幸的是它會因設 + 定而不同。換句話說，這個值會跟你用的 kernel image 檔而變動。如 + 果是用某個 snapshot 版本的 GENERIC kernel，也許其他人可以追蹤 + 到出問題的函式，但如果你是用自訂的 kernel，那麼只有要做的事包括這些： - Write down the instruction pointer value. Note that the - When the system reboots, do the following: + 把 instruction pointer 的值記下來。注意在前面的 當系統重新開機後，執行這道命令： -% nm /kernel.that.caused.the.panic | grep f0xxxxxx +% nm /(造成 panic 的 kernel 檔案) | grep f0xxxxxx - where % 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 的函式列表。這樣比直接找到出問題的函式 + 來得差，但至少好過什麼都沒有。 -

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. +

我常常看到人們顯示一大片 panic 訊息，但很少看到有人花一點時間 + 把 instruction pointer 和 kernel symbol table 中的函式比較一下。 -

The best way to track down the cause of a panic is by - capturing a crash dump, then using 要追蹤出造成 panic 原因的最好方法是先做出 crash dump，然後用 + - In any case, the method I normally use is this: + 不管是那一種，我通常是用這個方法： - 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.) - Use 寫好 kernel 設定檔。如果你需要用 kernel debugger，在設定 + 檔中加上 `options DDB' 這個選項。(當我懷疑有出現無窮迴圈時，通 + 常會用這個來設定中斷點。) + 用 cd /sys/compile/KERNELCONFIG; make - Wait for kernel to finish compiling. + 等 kernel 編譯出來 cp kernel / - reboot + 重新開機 -

[Note: Now that FreeBSD 3.x kernels are Elf by default, - you should use - -

Note that YOU DO To make sure you capture a crash dump, you need edit - /etc/rc.conf and set /etc/rc.conf, the /var/crash. - -

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 /var/crash to hold the dump. - Alternatively, you run Once you have recovered the crash dump, you can get a stack - trace with [注意：現在 FreeBSD 3.x kernel 內定是 ELF 格式，所以應該 + 用 + +

注意你要確定能抓到 crash dump，先編輯 /etc/rc.conf，將 + /etc/rc.conf + 裡有設 /var/crash。 + +

注意：FreeBSD 的 crash dump 通常和機器裡的實際記憶體一樣大， + 就像如果有 64MB 記憶體，crash dump 大小就是 64MB。所以要確定 + /var/crash 下有足夠的空間，或是可以手動執行 一旦發現有了 crash dump，就可以用 @@ -463,30 +391,94 @@ Cc: current@FreeBSD.ORG (gdb) where -

Note that there may be several screens worth of information; - ideally you should use Now, if you're really insane and have a second computer, you - can also configure [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] +

要注意可能會出現好幾個螢幕的可用資訊，你可以用 好啦，如果你有第二台電腦而且有夠瘋狂，可以將 [Bill 附注：我忘了提到一點：如果你有啟動 DDB 而 kernel 也 + 已經進入除錯器，可以在 DDB 命令列下打 `panic'，強迫產生 panic(還 + 有 crash dump)。也有可能在 panic 階段時再進入除錯器，如果這樣的話 + ，輸入 `continue'，接著它就會完成 crash dump。 -ed] + + + dlsym() 對 ELF 執行檔不能用! + +

在 ELF 一系列的工具中，內定是不會讓 dynamic linker 看到執行檔 + 裡定義了那些 symbol。所以 dlsym() 沒有辦法用藉由呼叫 + dlopen(NULL, flags) 取得的 handle，用它去搜尋有那些 + symbol 一定會失敗。 + +

如果你想要用 dlsym() 找出某個 process 的主執行檔中 + 有那些 symbol，則要在 link 時對 + 加上 -export-dynamic 這個參數。 + + + 增加或減少 kernel 能定址的空間 + +

系統的內定是，FreeBSD 3.x kernel 能定址到 256 MB，4.x 則是 + 1 GB。如果是網路負荷相當重的伺服器(就像大型 FTP 或 HTTP 伺服器)， + 256 MB 可能會不大夠。 + +

要怎麼增加定址空間呢? 要從兩方面著手。首先告訴 kernel 本身要 + 保留較大空間; 其次，既然是在定址空間的最上面載入 kernel，所以還 + 要調低載入的位址，否則就會超過定址範圍。 + +

增加 src/sys/i386/include/pmap.h 裡的 +#ifndef NKPDE +#ifdef SMP +#define NKPDE 254 /* addressable number of page tables/pde's */ +#else +#define NKPDE 255 /* addressable number of page tables/pde's */ +#endif /* SMP */ +#endif + + +

要算出 要解決第二個問題，必須自行算出 kernel 被載入的位址：求出 + 0x100100000 減掉定址空間大小的值(以 byte 為單位)，如 1 GB 大小就 + 是 0xc0100000。把 src/sys/i386/conf/Makefile.i386 裡的 + src/sys/i386/conf/kernel.script 中)，如下： + + +OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") +OUTPUT_ARCH(i386) +ENTRY(btext) +SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib); +SECTIONS +{ + /* Read-only sections, merged into text segment: */ + . = 0xc0100000 + SIZEOF_HEADERS; + .interp : { *(.interp) } + + +

然後重新 config 和做出新的 kernel。在執行像 /usr/include/vm/ + 下，再手動編譯 注意：kernel 所能定址的空間大小必須是 4 megabytes 的倍數。 + +

[ + 加上這一段：我認為 kernel 定址空間大小應該是 2 的乘冪，但不大確 + 定這一點。舊的啟動程式會動到 high order address bits，記得它假設 + 至少有 256 MB。] + diff --git a/zh_TW.Big5/FAQ/network.sgml b/zh_TW.Big5/FAQ/network.sgml index 040ce418a5..3c551d4368 100644 --- a/zh_TW.Big5/FAQ/network.sgml +++ b/zh_TW.Big5/FAQ/network.sgml @@ -1,17 +1,17 @@ - + - + - Networking + 網路設定 我應該到哪邊找有關無磁碟開機 (diskless booting) 的資料?

無磁碟開機就是讓 FreeBSD 主機從網路上開機,並且從網路上的 server 上讀取 其他必要的檔案,而非由主機的硬碟上取得這些檔案。 詳細的資料可以參考 - @@ -92,19 +92,19 @@ name="slattach"> 處理有關撥出的功能。

這些程式有詳細的說明,你可以在 - 中找到: + 中找到: - - - - @@ -139,8 +139,8 @@

你應該先看看 和 - . 使用以下指令來打開記錄 (logging) 的功能 + 。使用以下指令來打開記錄 (logging) 的功能 set log Phase Chat Connect Carrier lcp ipcp ccp command @@ -200,43 +200,42 @@ default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 -

這些設定是假設您使用的 address 跟 handbook 裡面的設定, - 或是與 man page 的範例抑或是 ppp.conf.sample 這個檔案裡的設定相同. - 如果您沒有設定 default route, 那麼有可能您現在使用舊版本的 - that doesn't understand the - word 這些設定是假設您使用的 address 跟 handbook 裡面的、或是 man + page 的範例、或者和 ppp.conf.sample 裡的設定相同。如果您沒有設定 + default route，那麼有可能您現在使用舊版本的 ，舊的 + ppp 會看不懂 ppp.conf 裡的 add 0 0 HISADDR -

這一行成為 +

成為 add 0 0 10.0.0.2 -

default route 這行沒有出現的另一個原因是 - 你設錯了 default router , 這個設定在 - 檔案中 (這個檔案在 release 2.2.2 前叫 - /etc/sysconfig ), 你需要加入這麼一行 +

default route 這行沒有出現的另一個原因是你設錯了 default + router，這個設定在 檔案中(這個檔案在 release 2.2.2 前叫 + /etc/sysconfig)，你需要在 ppp.conf 中加入這 + 麼一行 delete ALL -

在 ppp.conf中. 如果發生這種情形, 回到 handbook - 的說明中查詢. +

如果發生這種情形, 回到 handbook + 的說明中查詢。 什麼叫做 "No route to host" -

This error is usually due to a missin這個狀況通常是因為缺少了這段設定 +

這個狀況通常是因為缺少了這段設定 MYADDR: @@ -244,274 +243,295 @@ default 10.0.0.2 UGSc 0 0 tun0 add 0 0 HISADDR -

請檢查您的 /etc/ppp/ppp.linkup 檔案中是否有這些設定. 只有在您 - 使用動態 IP (dynamic IP) 或不知道您 gateway 的 IP 時才需要設定這個. - 如果您是使用互動模式(interactive mode) 的話, 您可以 - type the following after entering 請檢查您的 /etc/ppp/ppp.linkup 檔案中是否有這些設定。 + 只有在您使用動態 IP(dynamic IP) 或不知道您 gateway 的 IP 時才需要 + 設定這個。如果您是使用 interactive mode 的話, 您可以在進入 packet + mode 後輸入如下命令(如果 ppp 提示符號變成大寫的 delete ALL add 0 0 HISADDR -

您可以參考 handbook 中 有較詳盡的說明. - +

您可以參考 handbook 中 的部份，有較詳盡的說明。 - 我的連線在等待三分鐘後切斷了 + 我的連線在三分鐘後自動斷掉了 -

ppp 預設的 timeout 值是三分鐘. 可以用以下這行命令調整 +

ppp 預設的 timeout 值是三分鐘。可以用以下這行命令調整 set timeout NNN -

ppp.conf 這個檔案裡面, 或是在 interactive mode 裡面輸入這個指令. - 也可以用 on the fly 的方式調整,在線路啟用並聯接到 - - 或 . 參考 - man - page 以獲得更詳盡的資料. +

這代表如果在 ppp.conf 這個檔案裡面，或是在 + interactive mode 裡面輸入這個指令，也可以用 或 + 連到 man page + 以獲得更詳盡的資料. 我的連線因為負荷太重而斷線 -

如果您設定了 Link Quality Reporting (LQR) , 就有可能 - 發生您和對方主機之間有太多的 LQR 封包遺失的現象. - Ppp 會因此判斷電話線路有問題. - , 並且決定切斷連線. 在 FreeBSD 2.2.5 版以前, - LQR 內定值是 enabled . 現在的內定值是 disabled. - LQR 可以用這一行命令取消 +

如果您設定要用 Link Quality Reporting(LQR)，您和對方主機之間就 + 有可能遺失太多的 LQR 封包。Ppp 會因此判斷電話線路有問題，然後就會 + 切斷連線。在 FreeBSD 2.2.5 版以前，內定會使用 LQR，現在的內定值是 + 不用。LQR 可以用這一行命令取消 disable lqr - 我的連線會不定時的斷掉 + ppp 會不定時的斷線 -

有時候如果線路上有太多噪訊,甚至如果您使用了話中插撥的服務的話. - , 您的 modem 將或 hang 住,因為他誤認這些訊息是 lost carrier. +

有時候如果線路上有太多雜訊，甚至如果您使用了電話插撥服務的話， + 您的數據機將會掛斷電話，因為它誤認這些訊息是 lost carrier。 -

大部分的 modem 都有容忍暫時失去 carrier 的設定. - . 以 USR Sportster 為例, this is measured by the S10 register in - tenths of a second. 如果要讓您的 modem 能容忍更大的錯誤, 你可以在您的 dial string - 裡面加入以下的 send-expect 命令: +

大部分的數據機都有容忍暫時失去 carrier 的設定。以 USR Sportster + 為例，失去 carrier 和掛斷電話之間的時間，是以 1/10 秒為單位存在 + S10 暫存器中。如果要讓您的數據機能容忍更長的時間，你可以在 dial + string 裡面加入以下 "送出命令 - 等待字串" 的部份： set dial "...... ATS10=10 OK ......" -

參考您的 modem 內附的說明書以取得更詳細的資料. +

參考數據機內附的說明書以取得更詳細的資料。 + + + 連線會不定時當掉 + +

許多人的連線會毫無來由的卡住，首先要做的是找出連線那一方當掉。 + +

如果用的是外接數據機，就用 知道是本地或對方出問題後，就有兩種可能： + + + 對方的機器沒有回應 + +

在這方面能作的相當有限，大部份的 ISP 會因為你不是用 Microsoft + 作業系統而不願幫忙。可以在 首先，用下面兩道命令關掉所有本地的壓縮功能： + + + disable pred1 deflate deflate24 protocomp acfcomp shortseq vj + deny pred1 deflate deflate24 protocomp acfcomp shortseq vj + + +

然後重新連線，確定這樣不會有所不同。如果反而有進步或甚至將問題 + 解決掉，就用試誤法來找出是那個設定造成的。這樣在聯絡 ISP 時就可以 + 提供相當有用的資料（雖然會很容易看出你不是用 Microsoft 的產品）。 + +

在聯絡 ISP 之前，打開本地的非同步記錄功能，接著就等連線再度當掉， + 這可能會用到相當大的硬碟空間。最後從連接埠讀進的資料可能會相當有用， + 它通常是 ASCII 文字，甚至有可能會說明問題出在那裡(``Memory fault, + core dumped''?)。 + +

如果 ISP 願意協助的話，應該會在他們那一端也打開記錄功能，那麼在 + 下次連線當掉時，就可以告訴你為何會出問題。很歡迎將詳細內容送到 ，甚至要 + 求 ISP 直接向我連絡。 + + + 自己的 Ppp 當掉了 +

這裡能做的最多就是重新編譯 ppp：在 Makefile 最後面加上 + 將結果送到 . 在看到 Login OK! 的訊息以後就沒有反應了 -

在 FreeBSD 2.2.5 以前的版本上, 一但連線建立完成以後, - 會等對方的機器啟動 Line Control - Protocol (LCP). 很多 ISP 不會自動啟動這個訊息交換,而是等 - 待 cleint 端啟動. 要強迫 在 FreeBSD 2.2.5 以前的版本上，一旦連線建立完成以後， + + 會等對方的機器啟動 Line Control Protocol (LCP)。很多 ISP 不會自動 + 啟動，而是等待由 client 端來啟動。要強迫 set openmode active -

我一直看到 magic being the same 的錯誤訊息 -

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. - -

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. - -

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. - -

This can be avoided by allowing the peer to start negotiating - with the following line in your ppp.conf file: +

有時就在連上之後，在記錄檔會看到 "magic is the same" 的訊息。通 + 常這些是無害的，有時候某一端則會斷線。大多數的 ppp 實作無法解決這個 + 問題，就算似乎連上了，在記錄檔也可以看到一直重複的 configure request + 和 configure acknowledgement 之類的溝通訊息，ppp 最後會放棄而關掉連 + 線。 + +

會發生這種問題的通常情況是，伺服器用速度慢的硬碟、在通訊埠上執行 + getty、並且等到使用者登入後才用 script 或程式執行 ppp；也有聽說用 + slirp 就一定會發生類似問題的報告。原因是在 getty 結束和 ppp 開始執行 + 的這段時間內，client 端的 ppp 開始送出 Line Control Protocol(LCP) 封 + 包，由於伺服器通訊埠的 ECHO 仍在打開狀態，client 端的 ppp 就會看到送 + 出去的封包被 "反彈" 回來。 + +

在用 LCP 溝通時，有部份是要連線兩邊分別建立自己的 magic number， + 來偵測及避免封包被 "反彈" 回來的狀況。協定標準中說當對方試圖用和自己 + 相同的 magic number 溝通時，要送給對方一個 NAK 的訊號（表示不接受）， + 接著對方就會選另一個數字。但在伺服器通訊埠 ECHO 仍打開的這段期間， + client 端的 ppp 送出 LCP 封包，看到相同的 magic number，於是送出 + NAK 訊號。這個 NAK 也會被 "反彈" 回來，被誤認由對方送出，因此 client + 端會改變自己的 magic number。這樣 magic number 的變動次數會非常地多， + 並且也全都存在對方的終端機緩衝區中。當伺服器啟動 ppp 時，它馬上就 + 被 magic number 的大量更動所淹沒，並且（幾乎是立刻）決定已經試夠了 + LCP 而放棄；在這期間，client 端雖然再也看不到被反彈的封包，但卻來得 + 及看到伺服器把電話線掛掉。 + +

允許讓對方來作 LCP 溝通可以避免這種情形，在 ppp.conf 中加下面這 + 一行： set openmode passive -

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: +

這行告訴 ppp 由對方來啟動 LCP，不過有些伺服器永遠都不會主動溝通 + ，在這種情況下，可以這麼設定： set openmode active 3 -

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. +

這是要 ppp 等個三秒鐘，然後再開始送 LCP 相關要求。如果對方在這 + 段時間送出 LCP 封包，ppp 就不會等足三秒而立刻回應。 - LCP negotiations continue 'till the connection is closed - - -

There is currently an implementation mis-feature in This goes on 'till one side figures out that they're getting - nowhere and gives up. - -

The best way to avoid this is to configure one side to be - + +

目前 假設有兩端 這種惡性循環會一直持續著，直到有一方發現自己在原地打轉而放棄繼續 + 下去。 + +

避免這種情況的最好方式，是將某一端設成 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 set openmode active N - command (where - Ppp locks up shortly after connecting + Ppp 在連線後就卡住了 -

Prior to version 2.2.5 of FreeBSD, it was possible that your - link was disabled shortly after connection due to 在 FreeBSD 2.2.5 之前的版本，有可能因為 disable pred1 - Ppp locks up when I shell out to test it + 用 shell 跳出 Ppp 做測試時，連線似乎卡住了 -

When you execute the 在用 If you wish to execute commands like this, use the - 如果想執行程式，用 - Ppp over a null-modem cable never exits + 在 null-modem 線上建立的 Ppp 好像不會自動斷線 -

There is no way for 由於 null-modem 本身用的線材， enable lqr -

LQR is accepted by default if negotiated by the peer. +

內定是會接受 LQR，如果對方用它來溝通的話。 - Why does ppp dial for no reason in -auto mode + 為什麼 ppp 在 -auto 模式下會無緣無故播號？ -

If 如果 To determine the cause, use the following line: +

要找出原因，先用這個命令： set log +tcp/ip -

This will log all traffic through the connection. The next - time the line comes up unexpectedly, you will see the reason - logged with a convenient timestamp next to it. +

這樣會記錄經由連線的所有資料。下次如果又無故播號，就可以從記錄 + 旁邊的時間很快找到原因。 -

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 現在可以避免因為這些原因播號。通常是在作 DNS 查詢時才會發生這種 + 問題，要避免因 DNS 查詢而連線（這樣 set dfilter 1 deny udp src eq 53 @@ -519,117 +539,99 @@ default 10.0.0.2 UGSc 0 0 tun0 set dfilter 3 permit 0/0 0/0 -

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. +

這種做法並不永遠適用，因為它事實上使得你無法用 demand-dial 功能 + － 大部份程式在做網路相關動作前都會用到 DNS 查詢。 -

In the DNS case, you should try to determine what is actually - trying to resolve a host name. A lot of the time, - 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 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 - 在 DNS 這個情況下，應該試著找出到底是誰想要解出主機名稱，通常幾 + 乎都是由 所造成，所以要在 sendmail 設定檔中指示它不要做任何 + DNS 查詢。在 中有詳細說明如何作出 + 自己的設定檔、及裡面應該放那些設定，你也許想要將下一行加入 define(`confDELIVERY_MODE', `d')dnl -

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). +

這會使 sendmail 先擋著所有信件，直到送信時再一齊送出去（通常 + sendmail 執行時是用 ``-bd -q30m'' 這個參數，告訴它每三十分鐘才送信） + 或是有人執行 ``sendmail -q''（也許可以放在 ppp.linkup 裡）。 - What do these CCP errors mean + 這些 CCP 錯誤訊息是指？ -

I keep seeing the following errors in my log file: +

我在 log 檔一直看到這些錯誤訊息： CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) -

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: +

這是因為 ppp 試圖作 Predictor1 壓縮方面的溝通，但對方的機器卻完 + 全不用壓縮功能。這些訊息是無害的，但如果不想看到它的話，可以把本地 + ppp 的 Predictor1 壓縮也一起關掉： disable pred1 - Ppp locks up during file transfers with IO errors + 傳檔案時發生 IO 錯誤，然後 Ppp 就掛掉了 -

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. +

在 FreeBSD 2.2.2 及先前的版本中，tun 的驅動程式有個問題，它不會 + 接收那些大過 tun 介面 MTU 的封包。如果收到比 MTU 大的封包，它會用 + syslogd 記錄為 IO 錯誤。 -

The ppp specification says that an MRU of 1500 should - always 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. +

但 ppp 規格中有提到，不管 LCP 溝通的結果如何，MRU 最小的可接受 + 值永遠是 1500。所以有可能你不小心將 MTU 調低於 1500，ISP + 會不理它而送出 1500 大小的封包，然後就會觸發上述的 "功能"。 -

The problem can be circumvented by never setting an MTU of - less than 1500 under FreeBSD 2.2.2 or before. +

在 FreeBSD 2.2.2 及之前的版本中，永遠不要將 MTU 調低於 1500，就 + 可以解決這個問題。 - Why doesn't ppp log my connection speed? + 為什麼 ppp 不會記錄我的連線速度？ -

In order to log all lines of your modem ``conversation'', - you must enable the following: +

如果要記錄電腦和數據機間的每一行 ``對話''，用下一行打開： set log +connect -

This will make - - log everything up until the last requested "expect" string. +

這會使 記錄所有資料，直到播號字串最後一個等待的數據機傳回值 + 為止。 -

If you wish to see your connect speed and are using PAP or CHAP - (and therefore 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: +

如果使用 PAP 或 CHAP (因為沒有 "set login" 命令，所以設定檔中 + CONNECT 之後就不會看到任何對話)，想要看到連線速度的話，確定 ppp + 等待的數據機傳回值是 CONNECT 這一整行，像這樣： set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" -

Here, we get our CONNECT, send nothing, then expect a line-feed, - forcing 這樣在看到 CONNECT 後不會送出任何東西，接著再等個換行字元，強 + 迫 - Ppp ignores the `\' character in my chat script + Ppp 不理會 chat script 中的 `\' 字元 -

Ppp parses each line in your config files so that it can - interpret strings such as Ppp 會去分析設定檔中的每一行，這樣它才會正確解讀像是 + 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'' ``\T'' + 的跳脫字元（見 man page），必須重新解譯該參數。在這種雙重分析之下， + 你必須記得用正確的跳脫數目。 -

If you wish to actually send a ``\'' character to (say) your - modem, you'd need something like: +

假設要對數據機送出 ``\'' 這個字元，應該像是： set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" -

resulting in the following sequence: +

這樣則會得到下面這串： ATZ @@ -638,14 +640,14 @@ default 10.0.0.2 UGSc 0 0 tun0 OK -

or +

如果是 set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" -

resulting in the following sequence: +

則會得到下面結果： ATZ @@ -654,16 +656,14 @@ default 10.0.0.2 UGSc 0 0 tun0 - Ppp gets a seg-fault, but I see no + Ppp 碰到了 seg-fault，但找不到 -

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 Ppp (或任何類似的程式) 應該不可能有 core dump。由於 ppp 執行時 + 的 effective user id 是 0 (即以 root 身份執行)，作業系統在終止 ppp + 前不會對磁碟寫它的 core 映像檔。如果 ppp $ tar xfz ppp-*.src.tar.gz @@ -676,14 +676,11 @@ default 10.0.0.2 UGSc 0 0 tun0 # chmod 555 /usr/sbin/ppp -

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. +

你現在已經裝上可以用來除錯的 ppp 版本，由於權限上沒有作特別設定， + 所以必須以 root 來執行 ppp，順便也要注意是在那個目錄執行的。 -

Now, if and when ppp receives the segmentation violation, it - will dump a core file called ppp.core. You should then do the - following: +

現在如果 ppp 碰到了 segmentation violation，就會將 coredump 存在 + ppp.core 檔中，接下來就是： $ su @@ -698,177 +695,149 @@ default 10.0.0.2 UGSc 0 0 tun0 ..... -

All of this information should be given alongside your - question, making it possible to diagnose the problem. -

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. +

根據你的問題來取得相關資料，就可以診斷問題出在那裡。 + +

如果熟悉 gdb，也許會想找出其他的詳細資料，像是那個動作造成 + dump、及相關變數的位址及數值等。 - The process that forces a dial in auto mode never connects + 在 -auto 模式下，使 ppp 播號的程式在連線後卻連不到目的地 -

This was a known problem with The problem was that when that initial program calls - , 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. There are several theoretical ways to approach this problem. - It would be nicest if the peer would re-assign the same IP number - if possible The 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 - - and ppp's Another alternative (and probably the most reliable) would be - to implement a system call that changes all bound sockets from one - IP to another. Yet another possibility is to allow an interface to be brought - up without an IP number. Outgoing packets would be given - an IP number of 255.255.255.255 up until the first SIOCAIFADDR - ioctl is done. This would result in fully binding the socket. It - would be up to 這是設定 當用到網路的程式呼叫 + 時，socket endpoint 會設成 tun 這個界面的 IP，kernel 接著產生要送出 + 去的第一個封包，把它傳給 tun，理論上，有好幾種方法可以解決這個問題。如果 ISP 願意每次都提供相同 + IP 當然是最好 從 client 端最容易的解決方式是，永遠都不要改變 tun 界面的 IP 值， + 但是將所有出去的封包來源 IP 從原先的 tun 界面 IP 改為連線時取得的 + IP，基本上這就是最新版 和執行 ppp 時的 另一種方法（可能是最可靠）是寫個可以修改所有 socket endpoint 值的 + system call。當拿到新的 IP 時，還有一個可能則是允許不用 IP，就可以啟用某個網路界面。送出去的封包 + 來源 IP 會設成 255.255.255.255，直到 SIOCAIFADDR 這個 ioctl 第一次執 + 行完成為止。這樣會完全連結 socket 的兩端，而由 - Why don't most games work with the -alias switch - -

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. - -

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. - -

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: + 為何玩大多數遊戲時，都不能使用 -alias 這個參數？ + +

遊戲或類似程式不能和 libalias 搭配使用的原因是，外面的機器試著對 + 著內部的機器開啟連線、或（不請自來地）送出 UDP 封包，而 alias 封包的 + 軟體不知道它應該把這些封包送到裡面的機器去。 + +

解決的方式是，先確定現在只有執行那個會出問題的程式，然後在 + gateway 機器上對 tun 界面執行 tcpdump、或在上面打開記錄 tcp/ip 的功 + 能（``set log +tcp/ip''）。 + +

在啟動出問題的程式時，應該會在 gateway 機器上看到有封包通過，當外 + 界有傳回封包時則會被丟掉（這就是問題所在）。記下這些封包要送到目的地 + 的那個埠，然後關掉程式。重複幾次，看看是否都要送到同樣固定的埠，如果 + 是的話，在 /etc/ppp/ppp.conf 相關位置加上這一行，就可使程式正確運作： alias port proto internalmachine:port port -

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. +

其中 ``proto'' 是 ``tcp'' 或 ``udp''，``internalmachine'' 是要接 + 收這些封包的機器，``port'' 則是這些封包要送到那個埠。 -

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. +

如果要在其他機器上執行同樣程式，必須重複同樣過程修改上一行設定， + 否則就不能正常使用；也不可能在兩台內部機器上同時使用－畢竟外界只是把 + 這個內部網路看成一台機器而已。 -

If the port numbers aren't consistent, there are three more - options: +

如果封包不一定送到同樣的埠，你有三種選擇： -

1) 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. +

1) 在 libalias 加入對它的支援， + /usr/src/lib/libalias/alias_*.c 有一些 ``特例'' 的示範（alias_ftp.c + 是個不錯的原型檔）。通常是讀取某些可以認得出的外送封包，找出要外面連 + 到內部機器某個埠的指令，然後在 alias 表中設定 ``route''，以後再收到 + 這種封包就知道要往那裡送。 -

This is the most difficult solution, but it is the best and - will make the software work with multiple machines. +

這是最困難的解法，但也是最好的，並且還可以在多台機器上用同樣程式。 -

2) 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. +

2) 使用 proxy。舉例來說，該應用程式也許支援 socks5，或是 + 有個 ``passive'' 的選項（像是 ``cvsup''）可以避免對方向內部機器提出 + 連線的要求。 -

3) Redirect everything to the internal machine using - ``alias addr''. This is the sledge-hammer approach. +

3) 用 ``alias addr'' 把所有資料都轉給內部機器，這是最後 + 才用的暴力法。 + + + 那裡可以找到常用埠的列表？ + +

現在還沒有，但可以將這些弄成一個名單（如果有人感興趣的話）： + + + Quake +

Quake 是說用 UDP 6112 這個埠，所以如果 Quake 伺服器的 IP 是 + hostmachine，那麼 + alias port udp hostmachine:6112 6112 這一行應該就可以正 + 常運作。如果想用其他方式， + 有 Quake 對 proxy 支援的說明。 + - What are FCS errors ? - -

FCS stands for show hdlc command. - -

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. - -

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 must use - software flow control, use the command - set accmap 0x000a0000 to tell ppp to escape - the ^Q and ^S characters. - -

Another reason for seeing too many FCS errors may be that - the remote end has stopped talking close lcp command (a following term command - will reconnect you to the shell on the remote machine. - -

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. + 什麼是 FCS 錯誤？ + +

FCS 是 show hdlc 便可看到 HDLC 裡的各種錯誤計數值。 + +

不良線路(或封包被串列埠的驅動程式丟掉)有時候就會發生 FCS 錯誤， + 雖然它的確會大大拖慢壓縮協定，不過通常這沒什麼大不了。如果你用的 + 是外接數據機，確定有保護線路不受外界干擾 － 這樣說不定就解決了。 + +

如果在連上時馬上就凍住、並且還看到一大堆 FCS 錯誤的話，有可能 + 是因為你的連線並非是 8 bit clean。確定數據機不是用軟體流程控制 + (XON/XOFF)，如果你的連線一定要用軟體流程控制的話，用 + set accmap 0x000a0000 這道命令告訴 ppp 跳過 ^Q + 和 ^S 這兩個字元。 + +

看到一大堆 FCS 錯誤的另一個原因，是連線另一端不再使用 close lcp、接著 term 就可以重新連接到對 + 方機器的 shell 下，而不用掛掉電話線。 + +

如果記錄檔裡沒有任何資訊可以指示連線為何斷掉，那麼就該問問另一 + 端的管理員(你的 ISP？) 怎麼會這樣結束。 - None of this helps - I'm desperate ! - -

If all else fails, send as much information as you can, - including your config files, how you're starting command (before and after connecting) to the - mailing list or the + 沒有一個方法可以用，我完蛋了啦！ + +

如果上面說的都沒用，就盡可能找出所有資訊，這包括了設定檔、如何 + 啟動 + 輸出結果，把這些送到 mailing list 或 news group, and someone - should point you in the right direction. + name="comp.unix.bsd.freebsd.misc"> newsgroup，這樣應該就會有人指點 + 正確的方向。 我沒有辦法建立 /dev/ed0 這個 device! @@ -908,7 +877,7 @@ default 10.0.0.2 UGSc 0 0 tun0

某些 PC 的網路卡比其他的好(含蓄的說來) 這種狀況在造成 NFS 這種對網路敏感的程式有時會出現問題. -

參考 +

參考 以獲得這個主題的更多資訊. @@ -989,180 +958,154 @@ default 10.0.0.2 UGSc 0 0 tun0 - 為什麼我的主機要提供 FQDN ? - -

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''. - -

Traditionally, this was allowed by BSD BIND resolvers. However - the current version of 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 mumble must either be found - as mumble.foo.bar.edu, or it will be searched for - in the root domain. - -

This is different from the previous behavior, where the - search continued across mumble.bar.edu, and - mumble.edu. Have a look at RFC 1535 for why this - was considered bad practice, or even a security hole. - -

As a good workaround, you can place the line + 為什麼要用 FQDN 才能連到其他機器？ + +

你也許會發現要連的機器其實是在另一個網域。舉個例子，假設你是在 + foo.bar.edu 這個網域中，想要連到在 bar.edu 裡一台叫 ``mumble'' 的 + 機器，則必須用 Fully-Qualified Domain Name，也就是 + ``mumble.bar.edu''，而不是只用 ``mumble'' 來指向它。 + +

傳統的 BSD BIND resolver 允許用這種方式解出機器的位址，但是 + FreeBSD 內附 版本 + 的內定方式，則是除了你所在的網域以外，不支援其他非 FQDN 的縮寫。 + 所以如 mumble 這種不合格的機器名稱，必須在 + mumble.foo.bar.edu，否則就會從網域的最底層開始找。 + +

這和先前的做法不同，也就是不用 mumble.bar.edu 和 + mumble.edu 繼續搜尋。看一下 RFC 1535，裡面有提到為什麼之 + 前的做法不好，甚至算是個安全漏洞。 + +

這裡有個不錯的解法，把 + 裡的這一行： - search foo.bar.edu bar.edu + domain foo.bar.edu -

instead of the previous + 換成這一行： - domain foo.bar.edu + search foo.bar.edu bar.edu -

into your 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''。 - ``Permission denied'' for all networking operations. + 所有網路動作都會出現 ``Permission denied'' 錯誤訊息 -

If you have compiled your kernel with the 如果在編譯 kernel 時加了 If you had unintentionally misconfigured your system for - firewalling, you can restore network operability by typing - the following while logged in as root: +

如果不小心弄錯了 firewall 的設定，以 root 身份執行這個命令，接著 + 網路功能就會正常： ipfw add 65534 allow all from any to any -

You can also set "firewall_type='open'" in /etc/rc.conf. +

也可以在 /etc/rc.conf 設 "firewall_type='open'" 這個選項。 -

For further information on configuring a FreeBSD firewall, - see the . +

如果想知道如何設定 FreeBSD firewall，請看 。 - How much overhead does IPFW incur? + IPFW 會造成多大的網路延遲？ -

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. +

這個問題的答案大多要看你怎麼訂 firewall 規則、還有 CPU 速度。對大 + 多數在 ethernet 上的程式及規則不多的情況下，延遲小到可以忽略。但如果 + 你想要精確數字來滿足好奇心，繼續往下讀。 -

The following measurements were made using 2.2.5-STABLE on - a 486-66. IPFW was modified to measure the time spent within - the 下面是在 486-66 2.2.5-STABLE 上所作的測量，我們修改了 IPFW 原始碼 + 來測量在 Two rule sets, each with 1000 rules were tested. The first set - was designed to demonstrate a worst case scenario by repeating the - rule: +

測試了兩組，每組各有 1000 個規則。第一組重複下面規則，故意設計成 + 最糟的情況： ipfw add deny tcp from any to any 55555 -

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 allow ip - from any to any. +

藉由檢查 port number，這樣會使 IPFW 在決定某個封包不符合條件前執 + 行大部份的檢查程式，因此造成最差的狀況。在重複這個規則 999 次後，接 + 著是 allow ip from any to any。 -

The second set of rules were designed to abort the rule - check quickly: +

第二組設計成以極快的速度跳過檢查規則： ipfw add deny ip from 1.2.3.4 to 1.2.3.4 -

The nonmatching source IP address for the above rule causes - these rules to be skipped very quickly. As before, the 1000th - rule was an allow ip from any to any. +

一碰到封包的來源不符合規則所述，會很快跳過檢查讓封包通過。和上面 + 一樣，第 1000 個規則是 allow ip from any to any。 -

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. +

在第一種情況中，處理每一個封包所造成的延遲大約是 2.703 ms，所以每 + 個規則大概會造成 2.7 microsecond 的延遲。所以在這些規則之下，理論上每 + 秒最多可以處理 370 個封包。在 10Mbps ethernet 和一個封包大概 1500 byte + 的假設下，大概只會用到 55.5% 的網路頻寬。 -

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. +

第二種情況，每個封包花了大約 1.172ms，所以每條規則大約用了 1.2 + microsecond。理論上每秒最多可以處理 853 個封包，耗盡 10Mbps 的頻寬。 -

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: +

上面測試用到的大量規則、及這些規則本身並不代表真實世界的情況，他們 + 只是用來產生所表示的數據。若想要訂出一套有效率的規則，記得這幾件事： - Place an `established' rule early on to handle the - majority of TCP traffic. Don't put any allow tcp - statements before this rule. + 在最前面放一個專門處理大量 TCP 流量的可用規則，在這條前面不 + 要放任何 allow tcp 的相關敘述。 - Place heavily triggered rules earlier in the rule - set than those rarely used (without changing the - permissiveness of the firewall, of course). You can see - which rules are used most often by examining the packet counting - statistics with ipfw -a l. + 把常常觸發的規則放在前面，不常用到的則丟到後面(當然在不 + 影響 firewall 出入允許設定的前提下)。執行 ipfw -a l + 就可看到封包的統計數目，來看最常用到那些規則。 - How can I redirect service requests from one machine to another? + 要如何把對某台機器的網路服務要求(service request)轉向到另一台？ -

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: +

在 ports 目錄的 sysutils 種類中有個叫 'socket' 的 package，可以幫 + 你轉向 FTP 或其他類似的網路服務。只要把該網路服務的命令改成呼叫 socket + 即可，如下(在 /etc/inetd.conf 裡)： ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -

where 'ftp.foo.com' and 'ftp' are the host and port to redirect to, - respectively. - +

其中 'ftp.foo.com' 和 'ftp' 分別是被轉到的機器和 port 名稱。 + - Where can I get a bandwidth management tool? + 那裡可以找到管理頻寬的工具？ -

There are two bandwidth management tools available for FreeBSD. +

FreeBSD 上有兩套頻寬管理工具： is available for free; Bandwidth Manager from - is - a commercial product. - + name="ALTQ"> 可以免費使用， + 出的 + Bandwidth Manager 則是商用軟體。 - Why do I get ``/dev/bpf0: device not configured"? + 怎麼會跑出 ``/dev/bpf0: device not configured'' 這個訊息？ + -

The Berkeley Packet Filter driver - needs to be enabled before running programs that utilize it. - Add this to your kernel config file and build a new kernel: +

柏克萊封包過濾器(Berkeley Packet Filter) + 在程式使用前必須在 kernel 打開它的驅動程式，把下面這一行加入 kernel + 設定檔中，編個新的 kernel： pseudo-device bpfilter # Berkeley Packet Filter+ -

Secondly, after rebooting you will have to create the device - node. This can be accomplished by a change to the /dev - directory, followed by the execution of: +

在重新開機之後，還要做出 device node，在 /dev 下執行： - # sh MAKEDEV bpf0+ + # sh MAKEDEV bpf0 + +

如果想要更進一步知道如何做出各種 device node，請看 。 -

Please see the for more information - on creating devices. -- cgit v1.2.3