diff options
Diffstat (limited to 'zh_TW.Big5/FAQ/network.sgml')
| -rw-r--r-- | zh_TW.Big5/FAQ/network.sgml | 1158 |
1 files changed, 1158 insertions, 0 deletions
diff --git a/zh_TW.Big5/FAQ/network.sgml b/zh_TW.Big5/FAQ/network.sgml new file mode 100644 index 0000000000..8cbbaa5ac9 --- /dev/null +++ b/zh_TW.Big5/FAQ/network.sgml @@ -0,0 +1,1158 @@ +<!-- $Id: network.sgml,v 1.1.1.1 1999-01-30 23:20:34 vanilla Exp $ --> +<!-- The FreeBSD Documentation Project --> +<!-- Translate into Chinese by wing@cc.nsysu.edu.tw --> +<!-- English Version: 1.18 --> + + <sect> + <heading>Networking<label id="networking"></heading> + + <sect1> + <heading>我應該到哪邊找有關無磁碟開機 (diskless booting) 的資料?</heading> + + <p>無磁碟開機就是讓 FreeBSD 主機從網路上開機,並且從網路上的 server 上讀取 + 其他必要的檔案,而非由主機的硬碟上取得這些檔案。 詳細的資料可以參考 + its hard disk. For full details, please read + <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>This is assuming that you've used the addresses from the + handbook, the man page or from the ppp.conf.sample file. + If you haven't got a default route, it may be because you're + running an old version of <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. If your version of + <bf/ppp/ is from before FreeBSD 2.2.5, change the + + <verb> + add 0 0 HISADDR + </verb> + + <p>line to one saying + + <verb> + add 0 0 10.0.0.2 + </verb> + + <p>Another reason for the default route line being missing is that + you have mistakenly set up a default router in your + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf" + name="/etc/rc.conf"> file (this file was called + <tt>/etc/sysconfig</tt> prior to release 2.2.2), and you have + omitted the line saying + + <verb> + delete ALL + </verb> + + <p>from <tt>ppp.conf</tt>. If this is the case, go back to the + <url url="../handbook/userppp:final.html" + name="Final system configuration"> section of the handbook. + + <sect2> + <heading>What does "No route to host" mean</heading> + + <p>This error is usually due to a missing + + <verb> + MYADDR: + delete ALL + add 0 0 HISADDR + </verb> + + <p>section in your <tt>/etc/ppp/ppp.linkup</tt> file. This is + only necessary if you have a dynamic IP address or don't know the + address of your gateway. If you're using interactive mode, you can + type the following after entering <tt/packet mode/ (packet mode is + indicated by the capitalized <bf/PPP/ in the prompt): + + <verb> + delete ALL + add 0 0 HISADDR + </verb> + + <p>Refer to the <url url="../handbook/userppp:dynamicIP.html" + name="PPP and Dynamic IP addresses"> section of the handbook + for further details. + + <sect2> + <heading>My connection drops after about 3 minutes</heading> + + <p>The default ppp timeout is 3 minutes. This can be adjusted + with the line + + <verb> + set timeout NNN + </verb> + + <p>where <bf/NNN/ is the number of seconds of inactivity before the + connection is closed. If <bf/NNN/ is zero, the connection is + never closed due to a timeout. It is possible to put this command in + the <tt>ppp.conf</tt> file, or to type it at the prompt in + interactive mode. It is also possible to adjust it on the fly while + the line is active by connecting to <bf/ppp/s server socket using + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet"> + or <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl" + name="pppctl">. Refer to the + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man + page for further details. + + <sect2> + <heading>My connection drops under heavy load</heading> + + <p>If you have Link Quality Reporting (LQR) configured, it is + possible that too many LQR packets are lost between your + machine and the peer. Ppp deduces that the line must therefore + be bad, and disconnects. Prior to FreeBSD version 2.2.5, + LQR was enabled by default. It is now disabled by default. + LQR can be disabled with the line + + <verb> + disable lqr + </verb> + + <sect2> + <heading>My connection drops after a random amount of time</heading> + + <p>Sometimes, on a noisy phone line or even on a line with + call waiting enabled, your modem may hang up because it + thinks (incorrectly) that it lost carrier. + + <p>There's a setting on most modems for determining how tolerant + it should be to temporary losses of carrier. On a USR + Sportster for example, this is measured by the S10 register in + tenths of a second. To make your modem more forgiving, you could + add the following send-expect sequence to your dial string: + + <verb> + set dial "...... ATS10=10 OK ......" + </verb> + + <p>Refer to your modem manual for details. + + <sect2> + <heading>Nothing happens after the Login OK! message</heading> + + <p>Prior to FreeBSD version 2.2.5, once the link was established, + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" + name="ppp"> would wait for the peer to initiate the Line Control + Protocol (LCP). Many ISPs will not initiate negotiations and + expect the client to do so. To force <bf/ppp/ to initiate + the LCP, use the following line: + + <verb> + set openmode active + </verb> + + <p><bf/Note/: It usually does no harm if both sides initiate + negotiation, so openmode is now active by default. However, + the next section explains when it <bf/does/ do some harm. + + <sect2> + <heading>I keep seeing errors about 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>I can't create a <tt>/dev/ed0</tt> device!</heading> + + <p>In the Berkeley networking framework, network interfaces are only + directly accessible by kernel code. Please see the + <tt>/etc/rc.network</tt> file and the manual pages for the various + network programs mentioned there for more information. If this + leaves you totally confused, then you should pick up a book + describing network administration on another BSD-related + operating system; with few significant exceptions, administering + networking on FreeBSD is basically the same as on SunOS 4.0 or + Ultrix. + + <sect1> + <heading>How can I setup Ethernet aliases?</heading> + + <p>Add ``<tt/netmask 0xffffffff/'' to your <htmlurl + url="http://www.freebsd.org/cgi/man.cgi?ifconfig" name="ifconfig"> + command-line like the following: + + <verb> + ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff + </verb> + + <sect1> + <heading>How do I get my 3C503 to use the other network port?</heading> + + <p>If you want to use the other ports, you'll have to specify an + additional parameter on the + <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig" + name="ifconfig"> command line. The + default port is ``<tt/link0/''. To use the AUI port instead of + the BNC one, use ``<tt/link2/''. These flags should be specified + using the ifconfig_* variables in <htmlurl + url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">. + + <sect1> + <heading>I'm having problems with NFS to/from FreeBSD.</heading> + + <p>Certain PC network cards are better than others (to put it + mildly) and can sometimes cause problems with network intensive + applications like NFS. + + <p>See <url url="../handbook/nfs.html" name="the Handbook entry on NFS"> + for more information on this topic. + + <sect1> + <heading>Why can't I NFS-mount from a Linux box?</heading> + + <p>Some versions of the Linux NFS code only accept mount requests + from a privileged port; try + + <verb> + mount -o -P linuxbox:/blah /mnt + </verb> + + <sect1> + <heading>Why can't I NFS-mount from a Sun box?</heading> + + <p>Sun workstations running SunOS 4.X only accept mount requests + from a privileged port; try + + <verb> + mount -o -P sunbox:/blah /mnt + </verb> + + <sect1> + <heading>I'm having problems talking PPP to NeXTStep machines.</heading> + + <p>Try disabling the TCP extensions in <htmlurl + url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> by + changing the following variable to NO: + + <verb> + tcp_extensions=NO + </verb> + + <p>Xylogic's Annex boxes are also broken in this regard and you must + use the above change to connect thru them. + + <sect1> + <heading>How do I enable IP multicast support?</heading> + + <p>Multicast host operations are fully supported in FreeBSD 2.0 and + later by default. If you want your box to run as a multicast router, + you will need to recompile your kernel with the <tt>MROUTING</tt> + option and run <tt/mrouted/. FreeBSD 2.2 and later will start + <tt/mrouted/ at boot time if the flag <tt/mrouted_enable/ is set + to "YES" in <tt>/etc/rc.conf</tt>. + + <p>MBONE tools are available in their own ports category, mbone. If + you are looking for the conference tools <tt/vic/ and <tt/vat/, + look there! + + <p>For more information, see the + <url url="http://www.mbone.com/" name="Mbone Information Web">. + + <sect1> + <heading>Which network cards are based on the DEC PCI chipset?</heading> + + <p>Here is a list compiled by <url url="mailto:gfoster@driver.nsta.org" + name="Glen Foster">, with some more modern additions: + + <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>Why do I have to use the FQDN for hosts on my site?</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. + + + </sect> + |