diff options
Diffstat (limited to 'FAQ/network.sgml')
| -rw-r--r-- | FAQ/network.sgml | 1159 |
1 files changed, 0 insertions, 1159 deletions
diff --git a/FAQ/network.sgml b/FAQ/network.sgml deleted file mode 100644 index 74da70bc10..0000000000 --- a/FAQ/network.sgml +++ /dev/null @@ -1,1159 +0,0 @@ -<!-- $Id: network.sgml,v 1.18 1998-11-22 14:03:32 jkh 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/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 <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/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> - |