1274 lines
53 KiB
Text
1274 lines
53 KiB
Text
<!-- $Id: network.sgml,v 1.25 1999-05-15 02:24:47 brian Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<sect>
|
|
<heading>Networking<label id="networking"></heading>
|
|
|
|
<sect1>
|
|
<heading>Where can I get information on ``diskless booting''?</heading>
|
|
|
|
<p>``Diskless booting'' means that the FreeBSD box is booted over a
|
|
network, and reads the necessary files from a server instead of
|
|
its hard disk. For full details, please read
|
|
<url url="../handbook/diskless.html"
|
|
name="the Handbook entry on diskless booting">
|
|
|
|
<sect1>
|
|
<heading>
|
|
Can a FreeBSD box be used as a dedicated network router?
|
|
</heading>
|
|
|
|
<p>Internet standards and good engineering practice prohibit us from
|
|
providing packet forwarding by default in FreeBSD. You can
|
|
however enable this feature by changing the following variable to
|
|
<tt/YES/ in <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>This option will put the <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> variable
|
|
<tt/net.inet.ip.forwarding/ to <tt/1/.
|
|
|
|
<p>In most cases, you will also need to run a routing process to
|
|
tell other systems on your network about your router; FreeBSD
|
|
comes with the standard BSD routing daemon
|
|
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
|
|
name="routed">, or for more complex situations you may want to try
|
|
<em/GaTeD/ (available by FTP from <tt/ftp.gated.Merit.EDU/) which
|
|
supports FreeBSD as of 3_5Alpha7.
|
|
|
|
<p>It is our duty to warn you that, even when FreeBSD is configured
|
|
in this way, it does not completely comply with the Internet
|
|
standard requirements for routers; however, it comes close enough
|
|
for ordinary usage.
|
|
|
|
<sect1>
|
|
<heading>Can I connect my Win95 box to the Internet via FreeBSD?</heading>
|
|
|
|
<p>Typically, people who ask this question have two PC's at home, one
|
|
with FreeBSD and one with Win95; the idea is to use the FreeBSD
|
|
box to connect to the Internet and then be able to access the
|
|
Internet from the Windows95 box through the FreeBSD box. This
|
|
is really just a special case of the previous question.
|
|
|
|
<p>There's a useful document available which explains how to set
|
|
FreeBSD up as a <url url="http://www.ssimicro.com/~jeremyc/ppp.html"
|
|
name="PPP Dialup Router">
|
|
|
|
<p><bf/NOTE:/ This requires having at least two fixed IP addresses
|
|
available, and possibly three or more, depending on how much
|
|
work you want to go through to set up the Windows box. As an
|
|
alternative, if you don't have a fixed IP, you can use one of
|
|
the private IP subnets and install <bf/proxies/ such as
|
|
<url url="http://squid.nlanr.net/Squid/" name="SQUID"> and
|
|
<url url="http://www.tis.com/" name="the TIS firewall toolkit">
|
|
on your FreeBSD box.
|
|
|
|
<p>See also the section on <ref id="natd">.
|
|
|
|
<sect1>
|
|
<heading>
|
|
Why does recompiling the latest BIND from ISC fail?
|
|
</heading>
|
|
|
|
<p>There is a conflict between the ``<tt/cdefs.h/'' file in the
|
|
distribution and the one shipped with FreeBSD. Just remove
|
|
<tt>compat/include/sys/cdefs.h</tt>.
|
|
|
|
<sect1>
|
|
<heading>Does FreeBSD support SLIP and PPP?</heading>
|
|
|
|
<p>Yes. See the man pages for
|
|
<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"> and
|
|
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">.
|
|
<tt/pppd/ and <tt/ppp/ provide support for both incoming and outgoing
|
|
connections. <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
|
|
name="Sliplogin"> deals exclusively with incoming connections and
|
|
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
|
|
name="slattach"> deals exclusively with outgoing connections.
|
|
|
|
<p>These programs are described in the following sections of the
|
|
<url url="../handbook/index.html" name="handbook">:
|
|
|
|
<itemize>
|
|
<item><url url="../handbook/slips.html"
|
|
name="Handbook entry on SLIP (server side)">
|
|
|
|
<item><url url="../handbook/slipc.html"
|
|
name="Handbook entry on SLIP (client side)">
|
|
|
|
<item><url url="../handbook/ppp.html"
|
|
name="Handbook entry on PPP (kernel version)">
|
|
|
|
<item><url url="../handbook/ppp-and-slip.html#USERPPP"
|
|
name="Handbook entry on PPP (user-mode version)">
|
|
</itemize>
|
|
|
|
<p>If you only have access to the Internet through a "shell
|
|
account", you may want to have a look at the <htmlurl
|
|
url="http://www.freebsd.org/cgi/ports.cgi?^slirp" name="slirp">
|
|
package. It can provide you with (limited) access to services
|
|
such as ftp and http direct from your local machine.
|
|
|
|
<sect1>
|
|
<heading>
|
|
Does FreeBSD support NAT or Masquerading<label id="natd">
|
|
</heading>
|
|
|
|
<p>If you have a local subnet (one or more local machines), but have
|
|
been allocated only a single IP number from your Internet provider
|
|
(or even if you receive a dynamic IP number), you may want to look at
|
|
the <htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd" name="natd">
|
|
program. <tt/Natd/ allows you to connect an entire subnet to the
|
|
internet using only a single IP number.
|
|
|
|
<p>The <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
|
|
name="ppp"> program has similar functionality built in via
|
|
the <tt/-alias/ switch. The <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library">
|
|
is used in both cases.
|
|
|
|
<sect1>
|
|
<heading>
|
|
I can't make ppp work. What am I doing wrong ?<label id="userppp">
|
|
</heading>
|
|
|
|
<p>You should first read the <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> and
|
|
the <url url="../handbook/ppp-and-slip.html#USERPPP"
|
|
name="ppp section of the handbook">. Enable logging with the command
|
|
|
|
<verb>
|
|
set log Phase Chat Connect Carrier lcp ipcp ccp command
|
|
</verb>
|
|
|
|
<p>This command may be typed at the <bf/ppp/ command prompt or
|
|
it may be entered in the <tt>/etc/ppp/ppp.conf</tt> configuration file
|
|
(the start of the <bf>default</bf> section is the best place to put it).
|
|
Make sure that <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
|
|
name="/etc/syslog.conf"> contains the lines
|
|
|
|
<verb>
|
|
!ppp
|
|
*.* /var/log/ppp.log
|
|
</verb>
|
|
|
|
<p>and that the file <tt>/var/log/ppp.log</tt> exists. You can
|
|
now find out a lot about what's going on from the log file.
|
|
Don't worry if it doesn't all make sense. If you need to
|
|
get help from someone, it may make sense to them.
|
|
|
|
<p>If your version of ppp doesn't understand the "set log"
|
|
command, you should download the
|
|
<url url="http://www.freebsd.org/~brian" name="latest version">.
|
|
It will build on FreeBSD version 2.1.5 and higher.
|
|
|
|
<sect2>
|
|
<heading>Ppp just hangs when I run it</heading>
|
|
|
|
<p>This is usually because your hostname won't resolve. The best
|
|
way to fix this is to make sure that <tt>/etc/hosts</tt> is
|
|
consoluted by your resolver first by editing <tt>/etc/host.conf</tt>
|
|
and putting the <tt>hosts</tt> line first. Then, simply put an
|
|
entry in <tt>/etc/hosts</tt> for your local machine. If you have
|
|
no local network, change your <tt>localhost</tt> line:
|
|
|
|
<verb>
|
|
127.0.0.1 foo.bar.com foo localhost
|
|
</verb>
|
|
|
|
Otherwise, simply add another entry for your host. Consult the
|
|
relevant man pages for more details.
|
|
<p>You should be able to successfully <tt>ping -c1 `hostname`</tt>
|
|
when you're done.
|
|
|
|
<sect2>
|
|
<heading>Ppp won't dial in -auto mode</heading>
|
|
|
|
<p>First, check that you've got a default route. By running <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?netstat">
|
|
name="netstat -rn">, you should see two entries like this:
|
|
|
|
<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/ppp-and-slip.html#USERPPP-FINAL"
|
|
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/ppp-and-slip.html#USERPPP-DYNAMICIP"
|
|
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>My connection hangs after a random amount of time</heading>
|
|
|
|
<p>Many people experience hung connections with no apparent
|
|
explaination. The first thing to establish is which side of the
|
|
link is hung.
|
|
|
|
<p>If you are using an external modem, you can simply try using
|
|
<tt/ping/ to see if the <tt/TD/ light is flashing when you
|
|
transmit data. If it flashes (and the <tt/RD/ light doesn't), the
|
|
problem is with the remote end. If <tt/TD/ doesn't flash, the problem
|
|
is local. With an internal modem, you'll need to use the <tt/set
|
|
server/ command in your <tt/ppp.conf/ file. When the hang occurs,
|
|
connect to ppp using pppctl. If your network connection suddenly
|
|
revives (ppp was revived due to the activity on the diagnostic socket)
|
|
or if you can't connect (assuming the <tt/set socket/ command
|
|
succeeded at startup time), the problem is local. If you can connect
|
|
and things are still hung, enable local async logging with <tt/set log
|
|
local async/ and use <tt/ping/ from another window or terminal to make
|
|
use of the link. The async logging will show you the data being
|
|
transmitted and received on the link. If data is going out and not
|
|
coming back, the problem is remote.
|
|
|
|
<p>Having established whether the problem is local or remote,
|
|
you now have two possibilities:
|
|
|
|
<sect3>
|
|
<heading>The remote end isn't responding</heading>
|
|
|
|
<p>There's very little you can do about this. Most ISPs will
|
|
refuse to help if you're not running a Microsoft OS. You can
|
|
<tt/enable lqr/ in your <tt/ppp.conf/ file, allowing ppp to
|
|
detect the remote failure and hang up, but this detection is
|
|
relatively slow and therefore not that useful. You may want
|
|
to avoid telling your ISP that you're running user-ppp....
|
|
|
|
<p>First, try disabling all local compression by adding the
|
|
following to your configuration:
|
|
|
|
<verb>
|
|
disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
|
|
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
|
|
</verb>
|
|
|
|
<p>Then reconnect to ensure that this makes no difference.
|
|
If things improve or if the problem is solved completely,
|
|
determine which setting makes the difference through trial
|
|
and error. This will provide good amunition when you contact
|
|
your ISP (although it may make it apparent that you're not
|
|
running a Microsoft product).
|
|
|
|
<p>Before contacting your ISP, enable async logging locally
|
|
and wait until the connection hangs again. This may use up
|
|
quite a bit of disk space. The last data read from the port
|
|
may be of interest. It is usually ascii data, and may even
|
|
describe the problem (``Memory fault, core dumped'' ?).
|
|
|
|
<p>If your ISP is helpful, they should be able to enable logging
|
|
on their end, then when the next link drop occurs, they may be
|
|
able to tell you why their side is having a problem. Feel free
|
|
to send the details to <url url="mailto:brian@Awfulhak.org"
|
|
name="brian@Awfulhak.org">, or even to ask your ISP to
|
|
contact me directly.
|
|
|
|
<sect3>
|
|
<heading>Ppp is hung</heading>
|
|
<p>Your best bet here is to rebuild ppp by adding <tt/CFLAGS+=-g/
|
|
and <tt/STRIP=/ to the end of the Makefile, then doing a
|
|
<tt/make clean && make && make install/. When
|
|
ppp hangs, find the ppp process id with <tt/ps ajxww | fgrep ppp/
|
|
and run <tt/gdb ppp PID/. From the gdb prompt, you can then use
|
|
<tt/bt/ to get a stack trace.
|
|
|
|
<p>Send the results to <url url="mailto:brian@Awfulhak.org"
|
|
name="brian@Awfulhak.org">.
|
|
|
|
<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.
|
|
|
|
<sect3>
|
|
<heading>Has anybody made a list of useful port numbers ?</heading>
|
|
|
|
<p>Not yet, but this is intended to grow into such a list (if
|
|
any interest is shown).
|
|
|
|
<itemize>
|
|
<item><bf>Quake</bf>
|
|
<p>Quake is reported to use UDP port 6112, so a line saying
|
|
<tt>alias port udp hostmachine:6112 6112</tt> where
|
|
<tt>hostmachine</tt> is the quake server IP should do the job.
|
|
<p>Alternatively, you may want to take a look at
|
|
<htmlurl url="http://www.battle.net/support/proxy/"
|
|
name="www.battle.net"> for Quake proxy support.
|
|
</itemize>
|
|
|
|
<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.
|
|
|
|
<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>
|
|
|