1158 lines
46 KiB
Text
1158 lines
46 KiB
Text
<!-- $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>
|
|
|