diff options
Diffstat (limited to 'zh_TW.Big5/FAQ/network.sgml')
| -rw-r--r-- | zh_TW.Big5/FAQ/network.sgml | 1168 |
1 files changed, 0 insertions, 1168 deletions
diff --git a/zh_TW.Big5/FAQ/network.sgml b/zh_TW.Big5/FAQ/network.sgml deleted file mode 100644 index 6e7085f6a3..0000000000 --- a/zh_TW.Big5/FAQ/network.sgml +++ /dev/null @@ -1,1168 +0,0 @@ -<!-- $Id: network.sgml,v 1.2 1999-02-16 14:20:18 vanilla Exp $ --> -<!-- The FreeBSD Documentation Project --> -<!-- Translate into Chinese by wing@cc.nsysu.edu.tw --> -<!-- English Version: 1.20 --> - - <sect> - <heading>Networking<label id="networking"></heading> - - <sect1> - <heading>我應該到哪邊找有關無磁碟開機 (diskless booting) 的資料?</heading> - - <p>無磁碟開機就是讓 FreeBSD 主機從網路上開機,並且從網路上的 server 上讀取 - 其他必要的檔案,而非由主機的硬碟上取得這些檔案。 詳細的資料可以參考 - <url url="../handbook/diskless.html" - name="FreeBSD 手冊的無磁碟開機篇"> - - <sect1> - <heading> - FreeBSD 的主機可以當作某個網路上的路由器 (router) 嗎 ? - </heading> - - <p>由於網際網路的標準化和程式設計的充分經驗之賜,我們 - 能夠在 FreeBSD 系統內建封包轉傳 (packet fowarding) 的功能。你可以 - 將這個功能打開,只要將這個變數設定為 - <tt/YES/ 在 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf" - name="rc.conf">這個檔案中 - - <verb> - gateway_enable=YES # Set to YES if this host will be a gateway - </verb> - - <p>這個選項會將 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> 變數設定 - <tt/net.inet.ip.forwarding/ 為 <tt/1/. - - <p>在大部分的狀況下, 你還必須再跑一個處理 routing 的程式,告訴網路上的其他 - 主機關於你的 router 設定的資料; FreeBSD - 出廠時便內附一個標準的 BSD routing 程式 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed" - name="routed">, 如果你的網路設定更為複雜,你可以試試看 - <em/GaTeD/ (可以以 FTP 方式由 <tt/ftp.gated.Merit.EDU/ 下載) - 這個程式自 3_5Alpha7 後支援 FreeBSD . - - <p>我們有必要告訴你,就算是 FreeBSD 以這種方式設定完成 - , 它還是無法完全滿足 Internet 對 router 的標準定義 - ;不過, 就日常使用而言它已經足夠應付使用者的需求了。 - - <sect1> - <heading>我可以透過 FreeBSD 將我的 Win95 機器連上 Internet 嗎?</heading> - - <p>基本上, 會問這種問題的人在家裡至少有兩台電腦, 一台跑 FreeBSD - 另外一台跑 Win95; 這個主意是將 FreeBSD 主機連上 Internet - ,然後透過這台 FreeBSD 主機,讓跑 Win95 的電腦能夠上網。 - 這個問題算是前一個問題的一個特例。 - - <p>這邊有重要的文件,教你怎麼把 FreeBSD 的主機設定成 - <url url="http://www.ssimicro.com/~jeremyc/ppp.html" - name="PPP Dialup Router"> - - <p><bf/注意:/ 在這種狀況下你至少要有兩個以上的固定 IP addresses - , 有時是三個以上或更多組 IP 同時使用, 視你的需求而定。 - 如果你沒有固定的 IP 可以使用,你可以考慮使用 private IP - 子網路,並安裝 <bf/proxies/ 例如 - <url url="http://squid.nlanr.net/Squid/" name="SQUID"> 或是 - <url url="http://www.tis.com/" name="the TIS firewall toolkit"> - 在你的 FreeBSD 主機上。 - - <p>另外可以參考 <ref id="natd">. - - <sect1> - <heading> - 為什麼我在 compile ISC 最新版的 BIND 程式時老是失敗? - </heading> - - <p>在 ``<tt/cdefs.h/'' 檔案中的定義與 FreeBSD 系統中內附 - 的檔案定義有所衝突。直接把 - <tt>compat/include/sys/cdefs.h</tt> 砍掉就可以了。 - - <sect1> - <heading>FreeBSD 支援 SLIP 和 PPP 嗎?</heading> - - <p>是的。 你可以查查 man pages 中關於 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach" - name="slattach">, <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?sliplogin" name="sliplogin">, - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppd" name="pppd"> 以及 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> 的說明. - <tt/pppd/ 和 <tt/ppp/ 都提供撥進及撥出的功能。 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin" - name="Sliplogin"> 專門處理有關撥入的功能,而 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach" - name="slattach"> 處理有關撥出的功能。 - - <p>這些程式有詳細的說明,你可以在 - <url url="../handbook/handbook.html" name="handbook">中找到: - - <itemize> - <item><url url="../handbook/slips.html" - name="SLIP (server 端) 的說明"> - - <item><url url="../handbook/slipc.html" - name="SLIP (client 端) 的說明"> - - <item><url url="../handbook/ppp.html" - name="PPP (kernel 模式) 的說明"> - - <item><url url="../handbook/userppp.html" - name="PPP (使用者模式) 的說明"> - </itemize> - - <p>如果你只能藉由"shell account"的方式上網的話, - 你可能會想看看 <htmlurl - url="http://www.freebsd.org/cgi/ports.cgi?^slirp" name="slirp"> - 這個軟體。 它可以讓你的電腦直接連上 (某些) 服務, - 例如 ftp 和 http 等等。 - - <sect1> - <heading> - FreeBSD 支援 NAT 或 Masquerading 嗎?<label id="natd"> - </heading> - - <p>如果你有一個近端的子網路(有一台以上的機器), 但是你的 Internet provider - 卻只分配一個 IP number 給你 - (或者你只分配到一個動態的 IP number), 你可以參考 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd" name="natd"> - 這個程式。 <tt/Natd/ 讓你可以透過這一個 IP number 讓整個子網路的電腦都能 - 連上 internet 。 - - <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" - name="ppp"> 這個程式也提供類似的功能 , 如果你下 - <tt/-alias/ 這個選項的話。 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library"> - 在這兩個處理方式中都會被使用到。 - - <sect1> - <heading> - 我不能使用 ppp ,我做錯了什麼嗎 ?<label id="userppp"> - </heading> - - <p>你應該先看看 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> 和 - <url url="../handbook/userppp.html" - name="ppp 使用說明">. 使用以下指令來打開記錄 (logging) 的功能 - - <verb> - set log Phase Chat Connect Carrier lcp ipcp ccp command - </verb> - - <p>這個命令可以在 <bf/ppp/ command prompt 或者是在 - <tt>/etc/ppp/ppp.conf</tt> 組態檔案中加入。 - (加在 <bf>default</bf> section 的開頭最好). - 確定在 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?syslog.conf" - name="/etc/syslog.conf"> 裡面有這麼一行: - - <verb> - !ppp - *.* /var/log/ppp.log - </verb> - - <p>而且<tt>/var/log/ppp.log</tt> 這個檔案存在。 如此一來 - 你可以從 log 檔案中知道到底發生了什麼事情。 - 先不用擔心檔案的內容你看不懂, 如果你要向人求救的話 - , 救你的人會看得懂的。 - - <p>如果你系統上的那份 ppp 不提供 "set log" - 的指令的話, 你應該去下載 - <url url="http://www.freebsd.org/~brian" name="最新版本">. - 這個版本在 FreeBSD 2.1.5 以上的版本都可以使用。 - - <sect2> - <heading>我一執行 ppp ,它就掛在那邊不動了</heading> - - <p>會發生這種情形通常是你的 hostname 沒有辦法解出來。 解決這個問題 - 最好的辦法是確定 <tt>/etc/hosts</tt> 會被你的 resolver 第一個參考到。 - 你可以修改<tt>/etc/host.conf</tt> - 並且把<tt>hosts</tt> 放到最前面. 接著, 只要把你的機器名稱放到 - <tt>/etc/hosts</tt> 裡面就可以了。 如果你沒有 - local network 的話, 修改 <tt>localhost</tt> 這一行: - - <verb> -127.0.0.1 foo.bar.com foo localhost - </verb> - - 否則, 就把你主機的資訊加入檔案中。 你可以參考 - 相關的 man pages 以獲得進一步的資訊。 - <p>如果你順利的完成這些動作, 你應該可以成功的執行 <tt>ping -c1 `hostname`</tt> - . - - <sect2> - <heading>Ppp 在 -auto 模式下不能撥號</heading> - - <p>首先確定你的內定路由 (default route) 是否有設定。 下 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?netstat"> - name="netstat -rn"> 這個指令, 你應該能夠看到如以下範例的兩個 entries : - - <verb> -Destination Gateway Flags Refs Use Netif Expire -default 10.0.0.2 UGSc 0 0 tun0 -10.0.0.2 10.0.0.1 UH 0 0 tun0 - </verb> - - <p>這些設定是假設您使用的 address 跟 handbook 裡面的設定, - 或是與 man page 的範例抑或是 ppp.conf.sample 這個檔案裡的設定相同. - 如果您沒有設定 default route, 那麼有可能您現在使用舊版本的 - <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?ppp" - name="ppp"> that doesn't understand the - word <tt/HISADDR/ in the ppp.conf file. 如果您的系統 - <bf/ppp/ 是在 FreeBSD 2.2.5 之前的話, 修改 - - <verb> - add 0 0 HISADDR - </verb> - - <p>這一行成為 - - <verb> - add 0 0 10.0.0.2 - </verb> - - <p>default route 這行沒有出現的另一個原因是 - 你設錯了 default router , 這個設定在 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf" - name="/etc/rc.conf"> 檔案中 (這個檔案在 release 2.2.2 前叫 - <tt>/etc/sysconfig</tt> ), 你需要加入這麼一行 - - <verb> - delete ALL - </verb> - - <p>在 <tt>ppp.conf</tt>中. 如果發生這種情形, 回到 handbook - <url url="../handbook/userppp:final.html" - name="Final system configuration"> 的說明中查詢. - - <sect2> - <heading>什麼叫做 "No route to host"</heading> - - <p>This error is usually due to a missin這個狀況通常是因為缺少了這段設定 - - <verb> - MYADDR: - delete ALL - add 0 0 HISADDR - </verb> - - <p>請檢查您的 <tt>/etc/ppp/ppp.linkup</tt> 檔案中是否有這些設定. 只有在您 - 使用動態 IP (dynamic IP) 或不知道您 gateway 的 IP 時才需要設定這個. - 如果您是使用互動模式(interactive mode) 的話, 您可以 - type the following after entering <tt/packet mode/ (packet mode is - indicated by the capitalized <bf/PPP/ in the prompt): - - <verb> - delete ALL - add 0 0 HISADDR - </verb> - - <p>您可以參考 handbook 中 <url url="../handbook/userppp:dynamicIP.html" - name="PPP and Dynamic IP addresses"> 有較詳盡的說明. - - - <sect2> - <heading>我的連線在等待三分鐘後切斷了</heading> - - <p>ppp 預設的 timeout 值是三分鐘. 可以用以下這行命令調整 - - <verb> - set timeout NNN - </verb> - - <p><bf/NNN/ 代表在沒有連線成功前等待幾秒才將連線關閉. - 如果 <bf/NNN/ 設為 0, 那麼將不會因為 timeout 而關閉連線,會一直等待下去 - . 你可以把這行命令放到 - <tt>ppp.conf</tt> 這個檔案裡面, 或是在 interactive mode 裡面輸入這個指令. - 也可以用 on the fly 的方式調整,在線路啟用並聯接到 - <bf/ppp/s 伺服器的線路時使用 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet"> - 或 <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl" - name="pppctl">. 參考 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man - page 以獲得更詳盡的資料. - - <sect2> - <heading>我的連線因為負荷太重而斷線</heading> - - <p>如果您設定了 Link Quality Reporting (LQR) , 就有可能 - 發生您和對方主機之間有太多的 LQR 封包遺失的現象. - Ppp 會因此判斷電話線路有問題. - , 並且決定切斷連線. 在 FreeBSD 2.2.5 版以前, - LQR 內定值是 enabled . 現在的內定值是 disabled. - LQR 可以用這一行命令取消 - - <verb> - disable lqr - </verb> - - <sect2> - <heading>我的連線會不定時的斷掉</heading> - - <p>有時候如果線路上有太多噪訊,甚至如果您使用了話中插撥的服務的話. - , 您的 modem 將或 hang 住,因為他誤認這些訊息是 lost carrier. - - <p>大部分的 modem 都有容忍暫時失去 carrier 的設定. - . 以 USR Sportster 為例, this is measured by the S10 register in - tenths of a second. 如果要讓您的 modem 能容忍更大的錯誤, 你可以在您的 dial string - 裡面加入以下的 send-expect 命令: - - <verb> - set dial "...... ATS10=10 OK ......" - </verb> - - <p>參考您的 modem 內附的說明書以取得更詳細的資料. - - <sect2> - <heading>在看到 Login OK! 的訊息以後就沒有反應了</heading> - - <p>在 FreeBSD 2.2.5 以前的版本上, 一但連線建立完成以後, - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" - name="ppp"> 會等對方的機器啟動 Line Control - Protocol (LCP). 很多 ISP 不會自動啟動這個訊息交換,而是等 - 待 cleint 端啟動. 要強迫 <bf/ppp/ 主動啟動 - LCP, 請下這個命令: - - <verb> - set openmode active - </verb> - - <p><bf/Note/: 通常如果兩邊都啟動訊息交換的話,通常不會造成任何副作用. - , 所以 openmode 目前內定值是啟動的. 然而, - 下一段將解釋在什麼狀況下這個設定 <bf/真的/ 會造成副作用. - - <sect2> - <heading>我一直看到 magic being the same 的錯誤訊息</heading> - - <p>Occasionally, just after connecting, you may see messages in - the log that say "magic is the same". Sometimes, these - messages are harmless, and sometimes one side or the other - exits. Most ppp implementations cannot survive this problem, and - even if the link seems to come up, you'll see repeated configure - requests and configure acknowledgements in the log file until - ppp eventually gives up and closes the connection. - - <p>This normally happens on server machines with slow disks that - are spawning a getty on the port, and executing ppp from a - login script or program after login. I've also heard reports - of it happening consistently when using slirp. The reason is - that in the time taken between getty exiting and ppp starting, the - client-side ppp starts sending Line Control Protocol (LCP) - packets. Because ECHO is still switched on for the port on - the server, the client ppp sees these packets "reflect" back. - - <p>One part of the LCP negotiation is to establish a magic number - for each side of the link so that "reflections" can be detected. - The protocol says that when the peer tries to negotiate - the same magic number, a NAK should be sent and a new magic - number should be chosen. During the period that the server - port has ECHO turned on, the client ppp sends LCP packets, - sees the same magic in the reflected packet and NAKs it. It - also sees the NAK reflect (which also means ppp must change - its magic). This produces a potentially enormous number of - magic number changes, all of which are happily piling into - the server's tty buffer. As soon as ppp starts on the server, - it's flooded with magic number changes and almost immediately - decides it's tried enough to negotiate LCP and gives up. - Meanwhile, the client, who no longer sees the reflections, - becomes happy just in time to see a hangup from the server. - - <p>This can be avoided by allowing the peer to start negotiating - with the following line in your ppp.conf file: - - <verb> - set openmode passive - </verb> - - <p>This tells ppp to wait for the server to initiate LCP - negotiations. Some servers however may never initiate negotiations. - If this is the case, you can do something like: - - <verb> - set openmode active 3 - </verb> - - <p>This tells ppp to be passive for 3 seconds, and then to start - sending LCP requests. If the peer starts sending requests during - this period, ppp will immediately respond rather than waiting for - the full 3 second period. - - <sect2> - <heading> - LCP negotiations continue 'till the connection is closed - </heading> - - <p>There is currently an implementation mis-feature in <bf/ppp/ - where it doesn't associate LCP, CCP & IPCP responses with - their original requests. As a result, if one <bf/ppp/ - implementation is more than 6 seconds slower than the other side, - the other side will send two additional LCP configuration requests. - This is fatal. - - Consider two implementations, <bf/A/ and <bf/B/. <bf/A/ starts - sending LCP requests immediately after connecting and <bf/B/ takes - 7 seconds to start. When <bf/B/ starts, <bf/A/ has sent 3 LCP - REQs. We're assuming the line has ECHO switched off, otherwise - we'd see magic number problems as described in the previous section. - <bf/B/ sends a REQ, then an ACK to the first of <bf/A/'s REQs. - This results in <bf/A/ entering the <bf/OPENED/ state and sending - and ACK (the first) back to <bf/B/. In the meantime, <bf/B/ sends - back two more ACKs in response to the two additional REQs sent by - <bf/A/ before <bf/B/ started up. <bf/B/ then receives the first - ACK from <bf/A/ and enters the <bf/OPENED/ state. <bf/A/ receives - the second ACK from <bf/B/ and goes back to the <bf/REQ-SENT/ state, - sending another (forth) REQ as per the RFC. It then receives the - third ACK and enters the <bf/OPENED/ state. In the meantime, - <bf/B/ receives the forth REQ from <bf/A/, resulting in it reverting - to the <bf/ACK-SENT/ state and sending another (second) REQ and - (forth) ACK as per the RFC. <bf/A/ gets the REQ, goes into - <bf/REQ-SENT/ and sends another REQ. It immediately receives the - following ACK and enters <bf/OPENED/. - - <p>This goes on 'till one side figures out that they're getting - nowhere and gives up. - - <p>The best way to avoid this is to configure one side to be - <bf/passive/ - that is, make one side wait for the other to start - negotiating. This can be done with the - - <verb> - set openmode passive - </verb> - - command. Care should be taken with this option. You should also - use the - - <verb> - set stopped N - </verb> - - command to limit the amount of time that <bf/ppp/ waits for the peer - to begin negotiations. Alternatively, the - - <verb> - set openmode active N - </verb> - - command (where <bf/N/ is the number of seconds to wait before - starting negotiations) can be used. Check the manual page for - details. - - <sect2> - <heading>Ppp locks up shortly after connecting</heading> - - <p>Prior to version 2.2.5 of FreeBSD, it was possible that your - link was disabled shortly after connection due to <bf/ppp/ - mis-handling Predictor1 compression negotiation. This would - only happen if both sides tried to negotiate different - Compression Control Protocols (CCP). This problem is now - corrected, but if you're still running an old version of - <bf/ppp/, the problem can be circumvented with the line - - <verb> - disable pred1 - </verb> - - <sect2> - <heading>Ppp locks up when I shell out to test it</heading> - - <p>When you execute the <tt/shell/ or <tt/!/ command, <bf/ppp/ - executes a shell (or if you've passed any arguements, <bf/ppp/ - will execute those arguements). Ppp will wait for the command - to complete before continuing. If you attempt to use the - ppp link while running the command, the link will appear to have - frozen. This is because <bf/ppp/ is waiting for the command - to complete. - - <p>If you wish to execute commands like this, use the - <tt/!bg/ command instead. This will execute the given command - in the background, and ppp can continue to service the link. - - <sect2> - <heading>Ppp over a null-modem cable never exits</heading> - - <p>There is no way for <bf/ppp/ to automatically determine that - a direct connection has been dropped. This is due to the - lines that are used in a null-modem serial cable. When using - this sort of connection, LQR should always be enabled with - the line - - <verb> - enable lqr - </verb> - - <p>LQR is accepted by default if negotiated by the peer. - - <sect2> - <heading>Why does ppp dial for no reason in -auto mode</heading> - - <p>If <bf/ppp/ is dialing unexpectedly, you must determine the - cause, and set up Dial filters (dfilters) to prevent such dialing. - - <p>To determine the cause, use the following line: - - <verb> - set log +tcp/ip - </verb> - - <p>This will log all traffic through the connection. The next - time the line comes up unexpectedly, you will see the reason - logged with a convenient timestamp next to it. - - <p>You can now disable dialing under these circumstances. Usually, - this sort of problem arises due to DNS lookups. To prevent - DNS lookups from establishing a connection (this will <bf/not/ - prevent <bf/ppp/ from passing the packets through an established - connection), use the following: - - <verb> - set dfilter 1 deny udp src eq 53 - set dfilter 2 deny udp dst eq 53 - set dfilter 3 permit 0/0 0/0 - </verb> - - <p>This is not always suitable, as it will effectively break your - demand-dial capabilities - most programs will need a DNS lookup - before doing any other network related things. - - <p>In the DNS case, you should try to determine what is actually - trying to resolve a host name. A lot of the time, - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail" - name="sendmail"> is the culprit. You should make sure that you tell - sendmail not to do any DNS lookups in its configuration file. See - the section on <ref id="ispmail" name="Mail Configuration"> for - details on how to create your own configuration file and what should - go into it. You may also want to add the following line to your - <bf/.mc/ file: - - <verb> - define(`confDELIVERY_MODE', `d')dnl - </verb> - - <p>This will make sendmail queue everything until the queue is - run (usually, sendmail is invoked with ``-bd -q30m'', telling it - to run the queue every 30 minutes) or until a ``sendmail -q'' - is done (perhaps from your ppp.linkup file). - - <sect2> - <heading>What do these CCP errors mean</heading> - - <p>I keep seeing the following errors in my log file: - - <verb> - CCP: CcpSendConfigReq - CCP: Received Terminate Ack (1) state = Req-Sent (6) - </verb> - - <p>This is because ppp is trying to negotiate Predictor1 - compression, and the peer does not want to negotiate any - compression at all. The messages are harmless, but if you - wish to remove them, you can disable Predictor1 compression - locally too: - - <verb> - disable pred1 - </verb> - - <sect2> - <heading>Ppp locks up during file transfers with IO errors</heading> - - <p>Under FreeBSD 2.2.2 and before, there was a bug in the tun - driver that prevents incoming packets of a size larger than - the tun interface's MTU size. Receipt of a packet greater than - the MTU size results in an IO error being logged via syslogd. - - <p>The ppp specification says that an MRU of 1500 should - <bf>always</bf> be accepted as a minimum, despite any LCP - negotiations, therefore it is possible that should you decrease - the MTU to less than 1500, your ISP will transmit packets of - 1500 regardless, and you will tickle this non-feature - locking - up your link. - - <p>The problem can be circumvented by never setting an MTU of - less than 1500 under FreeBSD 2.2.2 or before. - - <sect2> - <heading>Why doesn't ppp log my connection speed?</heading> - - <p>In order to log all lines of your modem ``conversation'', - you must enable the following: - - <verb> - set log +connect - </verb> - - <p>This will make - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> - log everything up until the last requested "expect" string. - - <p>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: - - <verb> - set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" - </verb> - - <p>Here, we get our CONNECT, send nothing, then expect a line-feed, - forcing <bf/ppp/ to read the whole CONNECT response. - - <sect2> - <heading>Ppp ignores the `\' character in my chat script</heading> - - <p>Ppp parses each line in your config files so that it can - interpret strings such as <tt/set phone "123 456 789"/ correctly - (and realize that the number is actually only <bf/one/ argument. - In order to specify a ``"'' character, you must escape it using - a backslash (``\''). - - <p>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>If you wish to actually send a ``\'' character to (say) your - modem, you'd need something like: - - <verb> - set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" - </verb> - - <p>resulting in the following sequence: - - <verb> - ATZ - OK - AT\X - OK - </verb> - - <p>or - - <verb> - set phone 1234567 - set dial "\"\" ATZ OK ATDT\\T" - </verb> - - <p>resulting in the following sequence: - - <verb> - ATZ - OK - ATDT1234567 - </verb> - - <sect2> - <heading>Ppp gets a seg-fault, but I see no <tt/ppp.core/ file</heading> - - <p>Ppp (or any other program for that matter) should never - dump core. Because ppp runs with an effective user id of 0, - the operating system will not write ppps core image to disk - before terminating it. If, however ppp <bf/is/ actually - termating due to a segmentation violation or some other - signal that normally causes core to be dumped, <bf/and/ you're - sure you're using the latest version (see the start of this - section), then you should do the following: - - <verb> - $ tar xfz ppp-*.src.tar.gz - $ cd ppp*/ppp - $ echo STRIP= >>Makefile - $ echo CFLAGS+=-g >>Makefile - $ make clean all - $ su - # make install - # chmod 555 /usr/sbin/ppp - </verb> - - <p>You will now have a debuggable version of ppp installed. You - will have to be root to run ppp as all of its privileges have - been revoked. When you start ppp, take a careful note of what - your current directory was at the time. - - <p>Now, if and when ppp receives the segmentation violation, it - will dump a core file called ppp.core. You should then do the - following: - - <verb> - $ su - # gdb /usr/sbin/ppp ppp.core - (gdb) bt - ..... - (gdb) f 0 - ..... - (gdb) i args - ..... - (gdb) l - ..... - </verb> - - <p>All of this information should be given alongside your - question, making it possible to diagnose the problem. - <p>If you're familiar with gdb, you may wish to find out some - other bits and pieces such as what actually caused the dump and - the addresses & values of the relevant variables. - - <sect2> - <heading> - The process that forces a dial in auto mode never connects - </heading> - - <p>This was a known problem with <bf/ppp/ set up to negotiate - a dynamic local IP number with the peer in auto mode. It is - fixed in the latest version - search the man page for <bf/iface/. - - <p>The problem was that when that initial program calls - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect" - name="connect(2)">, the IP number of the tun interface is - assigned to the socket endpoint. The kernel creates the first - outgoing packet and writes it to the tun device. <bf/Ppp/ then - reads the packet and establishes a connection. If, as a result - of <bf/ppp/s dynamic IP assignment, the interface address is changed, - the original socket endpoint will be invalid. Any subsequent - packets sent to the peer will usually be dropped. Even if - they aren't, any responses will not route back to the originating - machine as the IP number is no longer owned by that machine. - - <p>There are several theoretical ways to approach this problem. - It would be nicest if the peer would re-assign the same IP number - if possible <tt/:-)/ The current version of <bf/ppp/ does this, - but most other implementations don't. - - <p>The easiest method from our side would be to never change the - tun interface IP number, but instead to change all outgoing packets - so that the source IP number is changed from the interface IP to - the negotiated IP on the fly. This is essentially what the - <tt/iface-alias/ option in the latest version of <bf/ppp/ is - doing (with the help of <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?libalias" name="libalias(3)"> - and ppp's <bf/-alias/ switch) - it's maintaining all previous - interface addresses and aliasing them to the last negotiated address. - - <p>Another alternative (and probably the most reliable) would be - to implement a system call that changes all bound sockets from one - IP to another. <bf/Ppp/ would use this call to modify the - sockets of all existing programs when a new IP number is - negotiated. The same system call could be used by dhcp clients - when they are forced to re-bind() their sockets. - - <p>Yet another possibility is to allow an interface to be brought - up without an IP number. Outgoing packets would be given - an IP number of 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 <bf/ppp/ to change the source IP number, but only if - it's set to 255.255.255.255, and only the IP number and IP checksum - would need to change. This, however is a bit of a hack as - the kernel would be sending bad packets to an improperly - configured interface, on the assumption that some other mechanism - is capable of fixing things retrospectively. - - <sect2> - <heading>Why don't most games work with the -alias switch</heading> - - <p>The reason games and the like don't work when libalias is - in use is that the machine on the outside will try to open a - connection or send (unsolicited) UDP packets to the machine - on the inside. The packet alias software doesn't know that - it should send these packets to the interior machine. - - <p>To make things work, make sure that the only thing running - is the software that you're having problems with, then either - run tcpdump on the tun interface of the gateway or enable ppp - tcp/ip logging (``set log +tcp/ip'') on the gateway. - - <p>When you start the offending software, you should see packets - passing through the gateway machine. When something comes back - from the outside, it'll be dropped (that's the problem). Note - the port number of these packets then shut down the offending - software. Do this a few times to see if the port numbers are - consistent. If they are, then the following line in the relevant - section of /etc/ppp/ppp.conf will make the software functional: - - <verb> - alias port proto internalmachine:port port - </verb> - - <p>where ``proto'' is either ``tcp'' or ``udp'', - ``internalmachine'' is the machine that you want the packets - to be sent to and ``port'' is the destination port number of - the packets. - - <p>You won't be able to use the software on other machines - without changing the above command, and running the software - on two internal machines at the same time is out of the question - - after all, the outside world is seeing your entire internal - network as being just a single machine. - - <p>If the port numbers aren't consistent, there are three more - options: - - <p><bf>1)</bf> Submit support in libalias. Examples of ``special - cases'' can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c - is a good prototype). This usually involves reading certain - recognised outgoing packets, identifying the instruction that - tells the outside machine to initiate a connection back to the - internal machine on a specific (random) port and setting up a - ``route'' in the alias table so that the subsequent packets - know where to go. - - <p>This is the most difficult solution, but it is the best and - will make the software work with multiple machines. - - <p><bf>2)</bf> Use a proxy. The application may support socks5 - for example, or (as in the ``cvsup'' case) may have a ``passive'' - option that avoids ever requesting that the peer open connections - back to the local machine. - - <p><bf>3)</bf> Redirect everything to the internal machine using - ``alias addr''. This is the sledge-hammer approach. - - <sect2> - <heading>What are FCS errors ?</heading> - - <p>FCS stands for <bf/F/rame <bf/C/heck <bf/S/equence. Each - ppp packet has a checksum attached to ensure that the data - being received is the data being sent. If the FCS of an - incoming packet is incorrect, the packet is dropped and the - HDLC FCS count is increased. The HDLC error values can be - displayed using the <tt>show hdlc</tt> command. - - <p>If your link is bad (or if your serial driver is dropping - packets), you will see the occasional FCS error. This is not - usually worth worrying about although it does slow down the - compression protocols substantially. If you have an external - modem, make sure your cable is properly shielded from - interference - this may eradicate the problem. - - <p>If your link freezes as soon as you've connected and you see - a large number of FCS errors, this may be because your link is - not 8 bit clean. Make sure your modem is not using software - flow control (XON/XOFF). If your datalink <bf>must</bf> use - software flow control, use the command - <tt>set accmap 0x000a0000</tt> to tell <bf>ppp</bf> to escape - the ^Q and ^S characters. - - <p>Another reason for seeing too many FCS errors may be that - the remote end has stopped talking <bf/PPP/. You may want to - enable <tt/async/ logging at this point to determine if the - incoming data is actually a login or shell prompt. If you - have a shell prompt at the remote end, it's possible to - terminate ppp without dropping the line by using the - <tt>close lcp</tt> command (a following <tt>term</tt> command - will reconnect you to the shell on the remote machine. - - <p>If nothing in your log file indicates why the link might - have been terminated, you should ask the remote administrator - (your ISP?) why the session was terminated. - - <sect2> - <heading>None of this helps - I'm desperate !</heading> - - <p>If all else fails, send as much information as you can, - including your config files, how you're starting <bf/ppp/, - the relevant parts of your log file and the output of the - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat" - name="netstat -rn"> command (before and after connecting) to the - <url url="mailto:freebsd-questions@FreeBSD.org" - name="freebsd-questions@FreeBSD.org"> mailing list or the - <url url="news:comp.unix.bsd.freebsd.misc" - name="comp.unix.bsd.freebsd.misc"> news group, and someone - should point you in the right direction. - - <sect1> - <heading>我沒有辦法建立 <tt>/dev/ed0</tt> 這個 device!</heading> - - <p>在 Berkeley 網路架構中, 只有 kernel 程式碼可以直接存取網路界面卡. - 請參考 <tt>/etc/rc.network</tt> 這個檔案和 manual pages 取得與其他不同網路程式 - 更進一步的資訊. 如果你覺得你完全搞混了的話, 您應該找一本與其他 BSD 相關 - 作業系統網路管理有關書來參考; 除了少數顯著的不同外, FreeBSD 的網路管理 - 基本上和 SunOS 4.0 和 Ultrix 是一樣的. - - - <sect1> - <heading>我如何建立 Ethernet aliases?</heading> - - <p>把 ``<tt/netmask 0xffffffff/'' 加到你的 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?ifconfig" name="ifconfig"> - 命令列中,例如: - - <verb> - ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff - </verb> - - <sect1> - <heading>我如何指定我的 3C503 使用其他不同的的 network port?</heading> - - <p>如果您想使用其他的 port, 你必須在 - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig" - name="ifconfig"> 的命令中指定額外的參數. 內定的 - port 是 ``<tt/link0/''. 要使用 AUI port 代替 - BNC port 的話, 改用 ``<tt/link2/''. 這些 flags 應該改變 - ifconfig_* 的變數來指定,你可以在這個檔案裡面找到 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">. - - <sect1> - <heading>我在連上/輸出 FreeBSD 的 NFS 時出現問題.</heading> - - <p>某些 PC 的網路卡比其他的好(含蓄的說來) - 這種狀況在造成 NFS 這種對網路敏感的程式有時會出現問題. - - <p>參考 <url url="../handbook/nfs.html" name="the Handbook entry on NFS"> - 以獲得這個主題的更多資訊. - - <sect1> - <heading>為什麼我不能 NFS-mount Linux 的機器?</heading> - - <p>某些版本的 Linux NFS 程式碼只接受 privileged port 的 mount request - ; 試用這行指令看看 - - <verb> - mount -o -P linuxbox:/blah /mnt - </verb> - - <sect1> - <heading>W為什麼我不能 NFS-mount Sun 的機器?</heading> - - <p>跑 SunOS 4.X 的 Sun 工作站只接受來自 privileged port 的 mount request - ; 試用這行指令看看 - - <verb> - mount -o -P sunbox:/blah /mnt - </verb> - - <sect1> - <heading>我在使用 PPP 連線到 NeXTStep 機器時有問題.</heading> - - <p>把 TCP extensions 取消, 這個設定在 <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> 裡面. - 把以下這個值設成 NO: - - <verb> - tcp_extensions=NO - </verb> - - <p>Xylogic 的 Annex 主機也有相同的問題,您要做相同的修改才能連上 - 這些主機. - - <sect1> - <heading>我要怎樣才能把 IP multicast support 打開?</heading> - - <p>Multicast host operations are fully supported in FreeBSD 2.0 and - later by default. 如果您想將您的主機設定成 multicast router 的話, - 您必須重新 compile 您的 kernel, 加入 <tt>MROUTING</tt> - 的選項,並且執行 <tt/mrouted/. 如果您的<tt>/etc/rc.conf</tt> 裡面的 - <tt/mrouted_enable/ 這個參數是設定成"YES" 的話.FreeBSD 2.2 及之後的 - 版本會在開機時執行 <tt/mrouted/ . - - <p>MBONE 的各種工具可以在他們 ports 下所屬叫做 mbone目錄中找到. - 如果您在找視訊會議的工具如 <tt/vic/ 和 <tt/vat/ 的話, - 到那邊找找! - - <p>如果需要更進一部的訊息,找找 - <url url="http://www.mbone.com/" name="Mbone Information Web">. - - <sect1> - <heading>哪些網路卡是使用 DEC PCI chipset?</heading> - - <p>以下是 <url url="mailto:gfoster@driver.nsta.org" - name="Glen Foster">提供的清單: - - <verb> - Vendor Model - ---------------------------------------------- - ASUS PCI-L101-TB - Accton ENI1203 - Cogent EM960PCI - Compex ENET32-PCI - D-Link DE-530 - Dayna DP1203, DP2100 - DEC DE435 - Danpex EN-9400P3 - JCIS Condor JC1260 - Linksys EtherPCI - Mylex LNP101 - SMC EtherPower 10/100 (Model 9332) - SMC EtherPower (Model 8432) - TopWare TE-3500P - Zynx ZX342 - </verb> - - <sect1> - <heading>為什麼我的主機要提供 FQDN ?</heading> - - <p>You will probably find that the host is actually in a different - domain; for example, if you are in foo.bar.edu and you wish to reach - a host called ``mumble'' in the bar.edu domain, you will have to - refer to it by the fully-qualified domain name, ``mumble.bar.edu'', - instead of just ``mumble''. - - <p>Traditionally, this was allowed by BSD BIND resolvers. However - the current version of <htmlurl - url="http://www.freebsd.org/cgi/man.cgi?named" name="bind"> that ships - with FreeBSD no longer provides default abbreviations for non-fully - qualified domain names other than the domain you are in. - So an unqualified host <tt>mumble</tt> must either be found - as <tt>mumble.foo.bar.edu</tt>, or it will be searched for - in the root domain. - - <p>This is different from the previous behavior, where the - search continued across <tt>mumble.bar.edu</tt>, and - <tt>mumble.edu</tt>. Have a look at RFC 1535 for why this - was considered bad practice, or even a security hole. - - <p>As a good workaround, you can place the line - - <verb> - search foo.bar.edu bar.edu - </verb> - - <p>instead of the previous - - <verb> - domain foo.bar.edu - </verb> - - <p>into your <htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf" - name="/etc/resolv.conf"> file. However, make sure that the search order - does not go beyond the ``boundary between local and public - administration'', as RFC 1535 calls it. - - <sect1> - <heading>``Permission denied'' for all networking operations.</heading> - - <p>If you have compiled your kernel with the <tt/IPFIREWALL/ - option, you need to be aware that the default policy as of - 2.1.7R (this actually changed during 2.1-STABLE development) - is to deny all packets that are not explicitly allowed. - - <p>If you had unintentionally misconfigured your system for - firewalling, you can restore network operability by typing - the following while logged in as root: - - <verb> - ipfw add 65534 allow all from any to any - </verb> - - <p>You can also set "firewall_type='open'" in <tt>/etc/rc.conf</tt>. - - <p>For further information on configuring a FreeBSD firewall, - see the <url url="../handbook/firewalls.html" name="Handbook section">. - - <sect1> - <heading>How much overhead does IPFW incur?</heading> - - <p>The answer to this depends mostly on your rule set and processor - speed. For most applications dealing with ethernet and small - rule sets, the answer is, negligible. For those of you that need - actual measurements to satisfy your curiosity, read on. - - <p>The following measurements were made using 2.2.5-STABLE on - a 486-66. IPFW was modified to measure the time spent within - the <tt/ip_fw_chk/ routine, displaying the results to the console - every 1000 packets. - - <p>Two rule sets, each with 1000 rules were tested. The first set - was designed to demonstrate a worst case scenario by repeating the - rule: - - <verb> - ipfw add deny tcp from any to any 55555 - </verb> - - <p>This demonstrates worst case by causing most of IPFW's packet - check routine to be executed before finally deciding that the - packet does not match the rule (by virtue of the port number). - Following the 999th iteration of this rule was an <tt>allow ip - from any to any</tt>. - - <p>The second set of rules were designed to abort the rule - check quickly: - - <verb> - ipfw add deny ip from 1.2.3.4 to 1.2.3.4 - </verb> - - <p>The nonmatching source IP address for the above rule causes - these rules to be skipped very quickly. As before, the 1000th - rule was an <tt>allow ip from any to any</tt>. - - <p>The per-packet processing overhead in the former case was - approximately 2.703ms/packet, or roughly 2.7 microseconds per - rule. Thus the theoretical packet processing limit with these - rules is around 370 packets per second. Assuming 10Mbps ethernet - and a ~1500 byte packet size, we would only be able to achieve a - 55.5% bandwidth utilization. - - <p>For the latter case each packet was processed in - approximately 1.172ms, or roughly 1.2 microseconds per rule. - The theoretical packet processing limit here would be about - 853 packets per second, which could consume 10Mbps ethernet - bandwidth. - - <p>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: - - <itemize> - - <item>Place an `established' rule early on to handle the - majority of TCP traffic. Don't put any <tt>allow tcp</tt> - statements before this rule. - - <item>Place heavily triggered rules earlier in the rule - set than those rarely used (<bf>without changing the - permissiveness of the firewall</bf>, of course). You can see - which rules are used most often by examining the packet counting - statistics with <tt>ipfw -a l</tt>. - - </itemize> - - <sect1> - <heading>How can I redirect service requests from one machine to another? - </heading> - - <p>You can redirect FTP (and other service) request with the 'socket' - package, available in the ports tree in category 'sysutils'. - Simply replace the service's commandline to call socket instead, like so: - -<verb> -ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -</verb> - - <p>where 'ftp.foo.com' and 'ftp' are the host and port to redirect to, - respectively. - - <sect1> - <heading>Where can I get a bandwidth management tool?</heading> - - <p>There are two bandwidth management tools available for FreeBSD. - <url url="http://www.csl.sony.co.jp/person/kjc/programs.html" - name="ALTQ"> is available for free; Bandwidth Manager from - <url url="http://www.etinc.com" name="Emerging Technologies"> is - a commercial product. - - - <sect1> - <heading>Why do I get ``/dev/bpf0: device not configured"?</heading> - - <p>The Berkeley Packet Filter <htmlurl - url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> driver - needs to be enabled before running programs that utilize it. - Add this to your kernel config file and build a new kernel: - - <verb> - pseudo-device bpfilter # Berkeley Packet Filter+ </verb> - - <p>Secondly, after rebooting you will have to create the device - node. This can be accomplished by a change to the <tt>/dev</tt> - directory, followed by the execution of: - - <tscreen><verb> - # sh MAKEDEV bpf0+ </verb></tscreen> - - <p>Please see the <htmlurl url="../handbook/kernelconfig:nodes.html" - name="handbook's entry on device nodes"> for more information - on creating devices. - </sect> |