850 lines
33 KiB
Text
850 lines
33 KiB
Text
<!-- $Id: network.sgml,v 1.4 1997-12-15 23:38:10 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="direct-at" name="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/handbook.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/userppp.html"
|
|
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/userppp.html"
|
|
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 <tt/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 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
|
|
<tt/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 <tt/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 <tt/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.
|
|
|
|
<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. 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>The only way to circumvent this is to put 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 may never initiate negotiations. If this is the case,
|
|
please report it as a bug (using send-pr). Ppp will need to be
|
|
adjusted so that the user can configure a variable delay before
|
|
initiating LCP negotiations.
|
|
|
|
<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 <tt/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
|
|
<tt/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, <tt/ppp/
|
|
executes a shell (or if you've passed any arguements, <tt/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 <tt/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 <tt/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 <tt/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 <tt/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>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 <tt/ppp/,
|
|
the relevent 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
|
|
above by default. If you want your box to run as a multicast router, you
|
|
will need to load the <tt/ip_mroute_mod/ loadable kernel module
|
|
and run <tt/mrouted/.
|
|
|
|
<p>For more information:
|
|
|
|
<verb>
|
|
Product Description Where
|
|
--------------- ----------------------- ---------------------------------------
|
|
faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt
|
|
imm/immserv IMage Multicast ftp.hawaii.edu:/paccom/imm.src.tar.Z
|
|
for jpg/gif images.
|
|
nv Network Video. ftp.parc.xerox.com:
|
|
/pub/net-reseach/exp/nv3.3alpha.tar.Z
|
|
vat LBL Visual Audio Tool. ftp.ee.lbl.gov:
|
|
/conferencing/vat/i386-vat.tar.Z
|
|
wb LBL White Board. ftp.ee.lbl.gov:
|
|
/conferencing/wb/i386-wb.tar.Z
|
|
mmcc MultiMedia Conference ftp.isi.edu:
|
|
Control program /confctrl/mmcc/mmcc-intel.tar.Z
|
|
rtpqual Tools for testing the ftp.psc.edu:/pub/net_tools/rtpqual.c
|
|
quality of RTP packets.
|
|
vat_nv_record Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z
|
|
and nv.
|
|
</verb>
|
|
|
|
<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">:
|
|
|
|
<verb>
|
|
Vendor Model
|
|
----------------------------------------------
|
|
ASUS PCI-L101-TB
|
|
Accton ENI1203
|
|
Cogent EM960PCI
|
|
Compex ENET32-PCI
|
|
D-Link DE-530
|
|
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>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>
|
|
|
|
</sect>
|
|
|