diff --git a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml index 9a84ff1fe9..90da0350d6 100644 --- a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2664 +1,2681 @@ PPP and SLIP - - If your connection to the Internet is through a modem, or you wish to - provide other people with dialup connections to the Internet using - FreeBSD, you have the option of using PPP or SLIP. Furthermore, two - varieties of PPP are provided: user (sometimes - referred to as iijppp) and - kernel. The procedures for configuring both types of - PPP, and for setting up SLIP are described in this chapter. - + + Restructured, reorganized, and updated by &a.jim;, + 1 March 2000. + + + Synopsis + + If you are connecting to the Internet via modem, or wish to + provide dialup connections to the Internet for others using FreeBSD, + you have the option of using PPP or SLIP. + + This chapter covers three varieties of PPP; + user, kernel, and + PPPoE (PPP over Ethernet). It also covers + setting up a SLIP client and server. + + The first variety of PPP that will be covered is User PPP. User + PPP was introduced into FreeBSD in 2.0.5-RELEASE as an addition to + the already existing kernel implementation of PPP. + + You may be wondering what the main difference is between User + PPP and kernel PPP. The answer is simple; user PPP does not run as + a daemon, and can run as and when desired. No PPP interface needs + to be compiled into ther kernel; it runs as a user process, and uses + the tunnel device driver (tun) to get data + into and out of the kernel. + + From here on out in this chapter, user ppp will simply be + referred to as ppp unless a distinction needs to be made between it + and and any other PPP software such as pppd. + Unless otherwise stated, all of the commands explained in this + section should be executed as root. + + - Setting up User PPP - - User PPP was introduced to FreeBSD in release 2.0.5 as an addition - to the existing kernel implementation of PPP. So, what is different - about this new PPP that warrants its addition? To quote from the manual - page: - -
- This is a user process PPP software package. Normally, PPP is - implemented as a part of the kernel (e.g. as managed by - pppd) and it is thus somewhat hard to debug and/or - modify its behavior. However, in this implementation PPP is done as a - user process with the help of the tunnel device driver - (tun). -
- - In essence, this means that rather than running a PPP daemon, the - ppp program can be run as and when desired. No PPP interface needs to - be compiled into the kernel, as the program can use the generic tunnel - device to get data into and out of the kernel. - - From here on out, user ppp will be referred to simply as ppp unless - a distinction needs to be made between it and any other PPP - client/server software such as pppd. Unless - otherwise stated, all commands in this section should be executed as - root. - - There are a large number of enhancements in version 2 of ppp. You - can discover what version you have by running ppp with no arguments and - typing show version at the prompt. It is a simple - matter to upgrade to the latest version of ppp (under any version of - FreeBSD) by downloading the latest archive via www.Awfulhak.org. - + Using User PPP + + Originally contributed by &a.brian;, with input + from &a.nik;, &a.dirkvangulik;, and &a.pjc;. + - Before you start - - This document assumes you are in roughly this position: - - You have an account with an Internet Service Provider (ISP) which - lets you use PPP. Further, you have a modem (or other device) - connected and configured correctly which allows you to connect to your - ISP. - - You are going to need the following information to hand: - - - - Your ISPs phone number(s). - + User PPP - - Your login name and password. This can be either a regular - unix style login/password pair, or a PPP PAP or CHAP - login/password pair. - + + Assumptions - - The IP addresses of one or more nameservers. Normally, you - will be given two IP numbers. You must have - this information for PPP version 1.x - unless you run your own nameserver. From version 2 onwards, - PPP supports nameserver address - negotiation. If your ISP supports this, then using the command - enable dns in your config file will tell - PPP to set the nameservers for - you. - - - - The following information may have been supplied by your ISP, but - is not strictly necessary: - - - - The IP address of your ISP's gateway. The gateway is the - machine to which you will connect and will be set up as your - default route. If your ISP hasn't given you - this number, we can make one up and your ISP's PPP server will - tell us the correct value when we connect. - - This IP number is referred to as HISADDR - by ppp. - + This document assumes you have the following: - - Your ISP's netmask. If your ISP hasn't given you this - information, you can safely use a netmask of + + An account with an Internet Service Provider (ISP) which + you connect to using PPP. Further, you have a modem or + other device connected to your system and configured + correctly, which allows you to connect to your ISP. + + + + The dialup number(s) of your ISP. + + + + Your login name and password. This can be either a + regular unix style login and password pair, or a PAP or CHAP + login and password pair. + + + + The IP address(es) of one or more name servers. + Normally, you will be given two IP addresses by your ISP to + use for this. If they have not given you at least one, then + you can use the enable dns command in + your ppp.conf file to tell + ppp to set the name servers for + you. + + + + The following information may be supplied by your ISP, but + is not completely necessary: + + + + The IP address of your ISP's gateway. The gateway is + the machine to which you will connect and will be set up as + your default route. If you do not have + this information, we can make one up and your ISP's PPP + server will tell us the correct value when we connect. + + This IP number is referred to as + HISADDR by + ppp. + + + + The netmask you should use. If your ISP has not + provided you with one, you can safely use 255.255.255.0. - - If your ISP allocates you a static IP address and hostname - then you can enter this information. Otherwise, we simply let the - peer assign whatever IP number it sees fit. - - - - If you do not have any of the required information, contact your - ISP and make sure they provide it to you. - + + + + If your ISP provides you with a static IP address and + hostname, you can enter it. Otherwise, we simply let the + peer assign whatever IP address it sees fit. + + + + If you do not have any of the required information, contact + your ISP and make sure they provide it to you. + - - Building a ppp ready kernel - - As the description states, ppp uses the kernel - tun device. It is necessary to make sure - that your kernel has support for this device compiled in. - - To check this, go to your kernel compile directory - (/sys/i386/conf or - /sys/pc98/conf) and examine your kernel - configuration file. It needs to have the line + + Preparing the Kernel + + As previously mentioned, ppp + users the tun device. It is necessary + to make sure that your kernel has support for this device + compiled into it. + + To check, go to your kernel compile directory + (/sys/i386/conf or + /sys/pc98/conf) and examine your + configuration file. It should have the following line somewhere + in it: -pseudo-device tun 1 - - in it somewhere. The stock GENERIC kernel has - this as standard, so if you have not installed a custom kernel or you - do not have a /sys directory, you do not have to - change anything. - - If your kernel configuration file does not have this line in it, - or you need to configure more than one tun device (for example, if you - are setting up a server and could have 16 dialup ppp connections at - any one time then you will need to use 16 instead - of 1), then you should add the line, re-compile, - re-install and boot the new kernel. Please refer to the Configuring the FreeBSD Kernel section - for more information on kernel configuration. - - You can check how many tunnel devices your current kernel has by - typing the following: +pseudo-device tun 1 + + If this line is not present, you will need to add it to the + configuration file and recompile your kernel. The stock + GENERIC kernel has this included, so if you + have not installed a custom kernel or do not have a + /sys directory, you do not have to change + anything. If you do need to recompile your kernel, please refer + to the kernel configuration + section for more information. + + You can check how many tunnel devices your current kernel + has by typing the following: - &prompt.root; ifconfig -a + &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - - - This case shows four tunnel devices, two of which are currently - configured and being used. It should be noted that the - RUNNING flag above indicates that the interface has - been used at some point—it is not an error if your interface - does not show up as RUNNING. - - If you have a kernel without the tun device, and you can not - rebuild it for some reason, all is not lost. You should be able to - dynamically load the code. Refer to the appropriate - &man.modload.8; and &man.lkm.4; pages for further details. - - You may also wish to take this opportunity to configure a - firewall. Details can be found in the Firewalls section. - - - - Check the tun device - - Most users will only require one tun - device (/dev/tun0). If you have used more (i.e., - a number other than 1 in the - pseudo-device line in the kernel configuration - file) then alter all references to tun0 below - to reflect whichever device number you are using. - - The easiest way to make sure that the - tun0 device is configured correctly is to - re-make it. To do this, execute the following commands: - - &prompt.root; cd /dev + + This case shows four tunnel devices, two of which are + currently configured and being used. It should be noted that + the RUNNING flag above indicates that the + interface has been used at some point—it is not an error + if your interface does not show up as + RUNNING. + + If for some reason you have a kernel that does not have the + tun device in it and cannot recompile + the kernel, all is not lost. You should be able to dynamically + load the code. Please refer to the appropriate + &man.modload.8; and &man.lkm.4; man pages for further + details. + + + + Check the <devicename>tun</devicename> device + + Under normal circumstances, most users will only require one + tun device + (/dev/tun0). If you have specified more + than one on the pseudo-device line for + tun in your kernel configuration file, + then alter all references to tun0 below + to reflect whichever device number you are using (e.g., + tun2). + + The easiest way to make sure that the + tun0 device is configured correctly, + is to remake the device. This process is quite easy. To remake + the device, do the following: + + &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 - - If you require 16 tunnel devices in your kernel, you will need to - create more than just tun0: - - &prompt.root; cd /dev + + If you need 16 tunnel devices in your kernel, you will need + to create them. This can be done by executing the following + commands: + + &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 - - Also, to confirm that the kernel is configured correctly, the - following command should give the indicated output: - - &prompt.root; ifconfig tun0 -tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 - - The RUNNING flag may not yet be set, in which - case you will see: - - &prompt.root; ifconfig tun0 -tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - - - - Name Resolution Configuration - - The resolver is the part of the system that turns IP addresses - into hostnames and vice versa. It can be configured to look for maps - that describe IP to hostname mappings in one of two places. The first - is a file called /etc/hosts (man 5 - hosts). The second is the Internet Domain Name Service - (DNS), a distributed data base, the discussion of which is beyond the - scope of this document. - - This section describes briefly how to configure your - resolver. - - The resolver is a set of system calls that do the name mappings, - but you have to tell them where to find their information. You do - this by first editing the file /etc/host.conf. - Do not call this file - /etc/hosts.conf (note the extra - s) as the results can be confusing. + + To confirm that the kernel is configured correctly, issue + the follow command and compare the results: + + &prompt.root; ifconfig tun0 +tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mut 1500 + + The RUNNING flag may not yet be set, in + which case you will see: + + &prompt.root; ifconfig tun0 +tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 + - Edit the <filename>/etc/host.conf</filename> file + Name Resolution Configuration + + The resolver is the part of the system that turns IP + addresses into hostnames and vice versa. It can be configured + to look for maps that describe IP to hostname mappings in one of + two places. The first is a file called + /etc/hosts. Read &man.hosts.5; for more + information. The second is the Internet Domain Name Service + (DNS), a distributed data base, the discussion of which is + beyond the scope of this document. + + The resolver is a set of system calls that do the name + mappings, but you have to tell them where to find their + information. You do this by first editing the file + /etc/host.conf. Do not + call this file /etc/hosts.conf (note the + extra s) as the results can be + confusing. - This file should contain the following two lines (in this - order): - - + + Edit <filename>/etc/host.conf</filename> + + This file should contain the following two lines (in this + order): + + hosts bind - - These instructs the resolver to first look in the file - /etc/hosts, and then to consult the DNS if the - name was not found. - + + These instruct the resolver to first look in the file + /etc/hosts, and then to consult the DNS + if the name was not found. + - - Edit the <filename>/etc/hosts</filename>(5) file - - This file should contain the IP addresses and names of machines - on your network. At a bare minimum it should contain entries for - the machine which will be running ppp. Assuming that your machine - is called foo.bar.com with the IP - address 10.0.0.1, - /etc/hosts should contain: - - -127.0.0.1 localhost -10.0.0.1 foo.bar.com foo - - The first line defines the alias localhost as a - synonym for the current machine. Regardless of your own IP address, - the IP address for this line should always be 127.0.0.1. The second line maps the name - foo.bar.com (and the shorthand - foo) to the IP address + Edit <filename>/etc/hosts</filename> + + This file should contain the IP addresses and names of + machines on your network. At a bare minimum it should contain + entries for the machine which will be running ppp. Assuming + that your machine is called foo.bar.com with the IP address 10.0.0.1, + /etc/hosts should contain: + + +127.0.0.1 localhost.bar.com localhost +127.0.0.1 localhost.bar.com. +10.0.0.1 foo.bar.com foo +10.0.0.1 foo.bar.com. + + The first two lines define the alias + localhost as a synonym for the current + machine. Regardless of your own IP address, the IP address + for this line should always be 127.0.0.1. The second two lines map + the name foo.bar.com (and the + shorthand foo) to the IP address 10.0.0.1. - - If your provider allocates you a static IP address and name, - then use these in place of the If your provider allocates you a static IP address and + name, use them in place of the 10.0.0.1 entry. - - - - Edit the <filename>/etc/resolv.conf</filename> file + - /etc/resolv.conf tells the resolver how to - behave. If you are running your own DNS, you may leave this file - empty. Normally, you will need to enter the following - line(s): - - + + Edit <filename>/etc/resolv.conf</filename> + + The /etc/resolv.conf file tells the + resolver how to behave. If you are running your own DNS, you + may leave this file empty. Normally, you will need to enter + the following line(s): + + +domain bar.com nameserver x.x.x.x -nameserver y.y.y.y -domain bar.com - - The x.x.x.x and - y.y.y.y - addresses are those given to you by your ISP. Add as many - nameserver lines as your ISP provides. The - domain line defaults to your hostname's domain, - and is probably unnecessary. Refer to the - resolv.conf manual page for details of other - possible entries in this file. - - If you are running PPP version 2 or greater, the enable - dns command will tell PPP to request that your ISP - confirms the nameserver values. If your ISP supplies different - addresses (or if there are no nameserver lines in - /etc/resolv.conf), PPP will rewrite the file - with the ISP-supplied values. +nameserver y.y.y.y + + The x.x.x.x and + y.y.y.y + addresses are those given to you by your ISP. Add as many + nameserver lines as your ISP provides. The + domain line defaults to your hostname's + domain, and is probably unnecessary. Refer to the + &man.resolv.conf.5; manual page for details of other possible + entries in this file. + + If you are running PPP version 2 or greater, the + enable dns command will tell PPP to request + that your ISP confirms the nameserver values. If your ISP + supplies different addresses (or if there are no nameserver + lines in /etc/resolv.conf), PPP will + rewrite the file with the ISP-supplied values. + - - - - <command>ppp</command> Configuration - - Both user ppp and pppd (the kernel level - implementation of PPP) use configuration files located in the - /etc/ppp directory. The sample configuration - files provided are a good reference for user ppp, so don't delete - them. - - Configuring ppp requires that you edit a number - of files, depending on your requirements. What you put in them - depends to some extent on whether your ISP allocates IP addresses - statically (i.e., you get given one IP address, and always use that - one) or dynamically (i.e., your IP address can be different for each - PPP session). - - - PPP and Static IP addresses - You will need to create a configuration file called - /etc/ppp/ppp.conf. It should look similar to - the example below. + + <application>PPP</application> Configuration + + Both ppp and pppd + (the kernel level implementation of PPP) use the configuration + files located in the /etc/ppp directory. + The sample configuration files provided are a good reference, + so do not delete them. - - Lines that end in a : start in the first - column, all other lines should be indented as shown using spaces - or tabs. - + Configuring ppp requires that you edit a + number of files, depending on your requirements. What you put + in them depends to some extent on whether your ISP allocates IP + addresses statically (i.e., you get given one IP address, and + always use that one) or dynamically (i.e., your IP address + changes each time you connect to your ISP). - + + PPP and Static IP Addresses + + You will need to create a configuration file called + /etc/ppp/ppp.conf. It should look + similar to the example below. + + + Lines that end in a : start in the + first column, all other lines should be indented as shown + using spaces or tabs. + + + 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: -6 set phone "(0123) 456 7890" +6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns - Do not include the line numbers, they are just for reference in - this discussion. - - - - Line 1: - - - Identifies the default entry. Commands in this entry are - executed automatically when ppp is run. - - - - - Line 2: - - - Identifies the device to which the modem is connected. - COM1: is - /dev/cuaa0 and - COM2: is - /dev/cuaa1. - - - - - Line 3: - - - Sets the speed you want to connect at. If 115200 doesn't - work (it should with any reasonably new modem), try 38400 - instead. - - - - - Line 4: - - - The dial string. User PPP uses an expect-send syntax - similar to the &man.chat.8; program. Refer to the - manual page for information on the features of this - language. - - - - - Line 5: - - - Identifies an entry for a provider called - “provider”. - - - - - Line 6: - - - Sets the phone number for this provider. Multiple phone - numbers may be specified using the : or - | character as a separator. The difference - between these separators is described in &man.ppp.8;. - To summarize, if you want to rotate through the numbers, use - the :. If you want to always attempt to - dial the first number first and only use the other numbers if - the first number fails, use the |. Always - quote the entire set of phone numbers as shown. - - - - - Line 7: - - - The login string is of the same chat-like syntax as the - dial string. In this example, the string works for a service - whose login session looks like this: - - J. Random Provider + Do not include the line numbers, they are just for + reference in this discussion. + + + + Line 1: + + + Identifies the default entry. Commands in this + entry are executed automatically when ppp is run. + + + + + Line 2: + + + Identifies the device to which the modem is + connected. COM1 is + /dev/cuaa0 and + COM2 is + /dev/cuaa1. + + + + + Line 3: + + + Sets the speed you want to connect at. If 115200 + does not work (it should with any reasonably new modem), + try 38400 instead. + + + + + Line 4: + + + The dial string. User PPP uses an expect-send + syntax similar to the &man.chat.8; program. Refer to + the manual page for information on the features of this + language. + + + + + Line 5: + + + Identifies an entry for a provider called + “provider”. + + + + + Line 6: + + + Sets the phone number for this provider. Multiple + phone numbers may be specified using the colon + (:) or pipe character + (|)as a separator. The difference + between the two separators is described in &man.ppp.8;. + To summarize, if you want to rotate through the numbers, + use a colon. If you want to always attempt to dial the + first number first and only use the other numbers if the + first number fails, use the pipe character. Always + quote the entire set of phone numbers as shown. + + + + + Line 7: + + + The login string is of the same chat-like syntax as + the dial string. In this example, the string works for + a service whose login session looks like this: + + J. Random Provider login: foo password: bar protocol: ppp - - You will need to alter this script to suit your own needs. - When you write this script for the first time, you should - enable “chat” logging to ensure that the - conversation is going as expected. - - If you're using PAP or CHAP, there will be no login at - this point, so your login string can be left blank. See PAP and CHAP + + You will need to alter this script to suit your own + needs. When you write this script for the first time, + you should enable “chat” logging to ensure + that the conversation is going as expected. + + If you are using PAP or CHAP, there will be no login + at this point, so your login string can be left blank. + See PAP and CHAP authentication for further details. - - - - - Line 8: - - - Sets the default timeout (in seconds) for the connection. - Here, the connection will be closed automatically after 300 - seconds of inactivity. If you never want to timeout, set this - value to zero. - - - - - Line 9: - - - Sets the interface addresses. The string - x.x.x.x should be replaced by the - IP address that your provider has allocated to you. The - string y.y.y.y should be replaced - by the IP address that your ISP indicated for their gateway - (the machine to which you connect). If your ISP hasn't given - you a gateway address, use 10.0.0.2/0. If you need to use a - “guessed” address, make sure that you create an - entry in /etc/ppp/ppp.linkup as per the - instructions for PPP and - Dynamic IP addresses. If this line is omitted, - ppp cannot run in or - mode. - - - - - Line 10: - - - Adds a default route to your ISPs gateway. The special - word HISADDR is replaced with the gateway - address specified on line 9. It is important that this line - appears after line 9, otherwise HISADDR - will not yet be initialized. - - - - - Line 11: - - - This line tells PPP to ask your ISP to confirm that your - nameserver addresses are correct. If your ISP supports this - facility, PPP can then update - /etc/resolv.conf with the correct - nameserver entries. - - - - - It is not necessary to add an entry to - ppp.linkup when you have a static IP address as - your routing table entries are already correct before you connect. - You may however wish to create an entry to invoke programs after - connection. This is explained later with the sendmail - example. - - Example configuration files can be found in the - /etc/ppp directory. - - - - PPP and Dynamic IP addresses - - If your service provider does not assign static IP numbers, - ppp can be configured to negotiate the local and - remote addresses. This is done by “guessing” an IP - number and allowing ppp to set it up correctly - using the IP Configuration Protocol (IPCP) after connecting. The - ppp.conf configuration is the same as PPP and Static IP addresses, - with the following change: - - + + + + + Line 8: + + + Sets the default timeout (in seconds) for the + connection. Here, the connection will be closed + automatically after 300 seconds of inactivity. If you + never want to timeout, set this value to zero. + + + + + Line 9: + + + Sets the interface addresses. The string + x.x.x.x should be replaced by + the IP address that your provider has allocated to you. + The string y.y.y.y should be + replaced by the IP address that your ISP indicated for + their gateway (the machine to which you connect). If + your ISP hasn't given you a gateway address, use 10.0.0.2/0. If you need to use + a “guessed” address, make sure that you + create an entry in + /etc/ppp/ppp.linkup as per the + instructions for PPP + and Dynamic IP addresses. If this line is + omitted, ppp cannot run in + or + mode. + + + + + Line 10: + + + Adds a default route to your ISPs gateway. The + special word HISADDR is replaced with + the gateway address specified on line 9. It is + important that this line appears after line 9, + otherwise HISADDR will not yet be + initialized. + + + + + Line 11: + + + This line tells PPP to ask your ISP to confirm that + your nameserver addresses are correct. If your ISP + supports this facility, PPP can then update + /etc/resolv.conf with the correct + nameserver entries. + + + + + It is not necessary to add an entry to + ppp.linkup when you have a static IP + address as your routing table entries are already correct + before you connect. You may however wish to create an entry + to invoke programs after connection. This is explained later + with the sendmail example. + + Example configuration files can be found in the + /etc/ppp directory. + + + + PPP and Dynamic IP Addresses + + If your service provider does not assign static IP + addresses, ppp can be configured to + negotiate the local and remote addresses. This is done by + “guessing” an IP address and allowing + ppp to set it up correctly using the IP + Configuration Protocol (IPCP) after connecting. The + ppp.conf configuration is the same as + PPP and Static IP + Addresses, with the following change: + + 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 - - Again, do not include the line numbers, they are just for - reference in this discussion. Indentation of at least one space is - required. - - - - Line 9: - - The number after the / character is the - number of bits of the address that ppp will insist on. You - may wish to use IP numbers more appropriate to your - circumstances, but the above example will always work. + Again, do not include the line numbers, they are just for + reference. Indentation of at least one space is + required. - The last argument (0.0.0.0) tells PPP - to negotiate using address + + Line 9: + + + The number after the / character + is the number of bits of the address that ppp will + insist on. You may wish to use IP numbers more + appropriate to your circumstances, but the above example + will always work. + + The last argument (0.0.0.0) tells + PPP to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use - 0.0.0.0 as the first argument to - set ifaddr as it prevents PPP from setting - up an initial route in mode. - - - - - If you are running version 1.x of PPP, you will also need to - create an entry in /etc/ppp/ppp.linkup. - ppp.linkup is used after a connection has been - established. At this point, ppp will know what - IP addresses should really be used. The - following entry will delete the existing bogus routes, and create - correct ones: - - -1 provider: -2 delete ALL -3 add 0 0 HISADDR - - - - Line 1: - - - On establishing a connection, ppp will - look for an entry in ppp.linkup according - to the following rules: First, try to match the same label as - we used in ppp.conf. If that fails, look - for an entry for the IP number of our gateway. This entry is - a four-octet IP style label. If we still haven't found an - entry, look for the MYADDR entry. - - - - - Line 2: - - - This line tells ppp to delete all - existing routes for the acquired tun interface (except the - direct route entry). - - - - - Line 3: - - - This line tells ppp to add a default - route that points to HISADDR. - HISADDR will be replaced with the IP number - of the gateway as negotiated in the IPCP. - - - - - See the pmdemand entry in the files - /etc/ppp/ppp.conf.sample and - /etc/ppp/ppp.linkup.sample for a detailed - example. - - Version 2 of PPP introduces “sticky routes”. Any - add or delete lines that - contain MYADDR or HISADDR will - be remembered, and any time the actual values of - MYADDR or HISADDR change, the - routes will be re-applied. This removes the necessity of repeating - these lines in ppp.linkup. - - - - Receiving incoming calls with <command>ppp</command> - - This section describes setting up ppp in a - server role. + 0.0.0.0 as the first argument to + set ifaddr as it prevents PPP from + setting up an initial route in + mode. + + + + + If you are running version 1.x of PPP, you will also need + to create an entry in /etc/ppp/ppp.linkup. + ppp.linkup is used after a connection has + been established. At this point, ppp will + know what IP addresses should really be + used. The following entry will delete the existing bogus + routes, and create correct ones: - When you configure ppp to receive incoming - calls on a machine connected to a LAN, you must decide if you wish - to forward packets to the LAN. If you do, you should allocate the - peer an IP number from your LAN's subnet, and use the command - -enable proxy - - in your ppp.conf file. You should also confirm - that the /etc/rc.conf file (this file used to - be called /etc/sysconfig) contains the - following: - - -gateway=YES - - - Which getty? - - Configuring FreeBSD for Dialup - Services provides a good description on enabling dialup - services using getty. - - An alternative to getty is mgetty, - a smarter version of getty designed with dialup - lines in mind. - - The advantages of using mgetty is that it - actively talks to modems, meaning if port is - turned off in /etc/ttys then your modem won't - answer the phone. - - Later versions of mgetty (from 0.99beta - onwards) also support the automatic detection of PPP streams, - allowing your clients script-less access to your server. - - Refer to Mgetty and - AutoPPP for more information on - mgetty. +1 provider: +2 delete ALL +3 add 0 0 HISADDR + + + + Line 1: + + + On establishing a connection, ppp + will look for an entry in ppp.linkup + according to the following rules: First, try to match + the same label as we used in + ppp.conf. If that fails, look for + an entry for the IP address of our gateway. This entry + is a four-octet IP style label. If we still have not + found an entry, look for the MYADDR + entry. + + + + + Line 2: + + + This line tells ppp to delete all + of the existing routes for the acquired + tun interface (except the + direct route entry). + + + + + Line 3: + + + This line tells ppp to add a + default route that points to HISADDR. + HISADDR will be replaced with the IP + number of the gateway as negotiated in the IPCP. + + + + + See the pmdemand entry in the files + /etc/ppp/ppp.conf.sample and + /etc/ppp/ppp.linkup.sample for a + detailed example. + + Version 2 of PPP introduces “sticky routes”. + Any add or delete lines + that contain MYADDR or + HISADDR will be remembered, and any time + the actual values of MYADDR or + HISADDR change, the routes will be + reapplied. This removes the necessity of repeating these + lines in ppp.linkup. - PPP permissions - - ppp must normally be run as user id 0. If - however you wish to allow ppp to run in server - mode as a normal user by executing ppp as - described below, that user must be given permission to run - ppp by adding them to the - network group in - /etc/group. - - You will also need to give them access to one or more sections - of the configuration file using the allow - command: + Receiving Incoming Calls + + When you configure ppp to + receive incoming calls on a machine connected to a LAN, you + must decide if you wish to forward packets to the LAN. If you + do, you should allocate the peer an IP number from your LAN's + subnet, and use the command enable proxy in + your /etc/ppp/ppp.conf file. You should + also confirm that the /etc/rc.conf file + contains the following: +gateway="YES" + + + Which getty? + + Configuring FreeBSD for Dialup + Services provides a good description on enabling + dialup services using getty. + + An alternative to getty is mgetty, + a smarter version of getty designed with + dialup lines in mind. + + The advantages of using mgetty is + that it actively talks to modems, + meaning if port is turned off in + /etc/ttys then your modem will not answer + the phone. + + Later versions of mgetty (from + 0.99beta onwards) also support the automatic detection of + PPP streams, allowing your clients script-less access to + your server. + + Refer to Mgetty and + AutoPPP for more information on + mgetty. + + + + <application>PPP</application> Permissions + + The ppp command must normally be run + as user id 0. If however, you wish to allow + ppp to run in server mode as a normal + user by executing ppp as described below, + that user must be given permission to run + ppp by adding them to the + network group in + /etc/group. + + You will also need to give them access to one or more + sections of the configuration file using the + allow command: + + allow users fred mary - If this command is used in the default - section, it gives the specified users access to everything. - + If this command is used in the default + section, it gives the specified users access to + everything. + - - Setting up a PPP shell for dynamic-IP users - - Create a file called /etc/ppp/ppp-shell - containing the following: - - + + PPP Shells for Dynamic-IP Users + + Create a file called + /etc/ppp/ppp-shell containing the + following: + + #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT - - This script should be executable. Now make a symbolic link - called ppp-dialup to this script using the - following commands: - - &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup - - You should use this script as the shell - for all your dialup ppp users. This is an example from - /etc/password for a dialup PPP user with - username pchilds. (remember don't directly - edit the password file, use vipw) - - + + This script should be executable. Now make a symbolic + link called ppp-dialup to this script + using the following commands: + + &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup + + You should use this script as the + shell for all of your dialup users. + This is an example from /etc/password + for a dialup PPP user with username + pchilds (remember don't directly edit + the password file, use vipw). + + pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup - - Create a /home/ppp directory that is - world readable containing the following 0 byte files - + + Create a /home/ppp directory that + is world readable containing the following 0 byte + files: + -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts - - which prevents /etc/motd from being - displayed. - - - Setting up a PPP shell for static-IP users - - Create the ppp-shell file as above and - for each account with statically assigned IPs create a symbolic - link to ppp-shell. - - For example, if you have three dialup customers - fred, sam, and - mary, that you route class C networks for, - you would type the following: - - &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred + which prevents /etc/motd from being + displayed. + + + + PPP shells for Static-IP Users + + Create the ppp-shell file as above + and for each account with statically assigned IPs create a + symbolic link to ppp-shell. + + For example, if you have three dialup customers + fred, sam, and + mary, that you route class C networks + for, you would type the following: + + &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary - - Each of these users dialup accounts should have their shell - set to the symbolic link created above. (ie. - mary's shell should be - /etc/ppp/ppp-mary). - - - Setting up ppp.conf for dynamic-IP users + Each of these users dialup accounts should have their + shell set to the symbolic link created above (i.e., + mary's shell should be + /etc/ppp/ppp-mary). + + + + Setting up ppp.conf for dynamic-IP users - The /etc/ppp/ppp.conf file should contain - something along the lines of + The /etc/ppp/ppp.conf file should + contain something along the lines of: - + default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy - - The indenting is important. - - - The default: section is loaded for each - session. For each dialup line enabled in - /etc/ttys create an entry similar to the one - for ttyd0: above. Each line should get a - unique IP address from your pool of IP addresses for dynamic - users. - + + The indenting is important. + - - Setting up <filename>ppp.conf</filename> for static-IP - users - - Along with the contents of the sample - /etc/ppp/ppp.conf above you should add a - section for each of the statically assigned dialup users. We will - continue with our fred, - sam, and mary - example. - - + The default: section is loaded for + each session. For each dialup line enabled in + /etc/ttys create an entry similar to + the one for ttyd0: above. Each line + should get a unique IP address from your pool of IP + addresses for dynamic users. + + + + Setting up <filename>ppp.conf</filename> for static-IP + users + + Along with the contents of the sample + /etc/ppp/ppp.conf above you should add + a section for each of the statically assigned dialup users. + We will continue with our fred, + sam, and mary + example. + + fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 - - The file /etc/ppp/ppp.linkup should also - contain routing information for each static IP user if required. - The line below would add a route for the 203.14.101.0 class C via the client's - ppp link. - - + + The file /etc/ppp/ppp.linkup should + also contain routing information for each static IP user if + required. The line below would add a route for the 203.14.101.0 class C via the + client's ppp link. + + fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR + More on <command>mgetty</command>, AutoPPP, and MS extensions - + <command>mgetty</command> and AutoPPP - Configuring and compiling mgetty with the - AUTO_PPP option enabled allows + Configuring and compiling mgetty with + the AUTO_PPP option enabled allows mgetty to detect the LCP phase of PPP - connections and automatically spawn off a ppp shell. However, - since the default login/password sequence does not occur it is - necessary to authenticate users using either PAP or CHAP. - - This section assumes the user has successfully configured, - compiled, and installed a version of mgetty - with the AUTO_PPP option (v0.99beta or - later) - + connections and automatically spawn off a ppp shell. + However, since the default login/password sequence does not + occur it is necessary to authenticate users using either PAP + or CHAP. + + This section assumes the user has successfully + configured, compiled, and installed a version of + mgetty with the + AUTO_PPP option (v0.99beta or + later). + Make sure your /usr/local/etc/mgetty+sendfax/login.config file has the following in it: - + /AutoPPP/ - - /etc/ppp/ppp-pap-dialup - + This will tell mgetty to run the ppp-pap-dialup script for detected PPP connections. - + Create a file called /etc/ppp/ppp-pap-dialup containing the following (the file should be executable): - + #!/bin/sh exec /usr/sbin/ppp -direct pap$IDENT - + For each dialup line enabled in - /etc/ttys create a corresponding entry in - /etc/ppp/ppp.conf. This will happily - co-exist with the definitions we created above. - + /etc/ttys, create a corresponding entry + in /etc/ppp/ppp.conf. This will + happily co-exist with the definitions we created + above. + pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy - - Each user logging in with this method will need to have a - username/password in /etc/ppp/ppp.secret - file, or alternatively add the - + + Each user logging in with this method will need to have + a username/password in + /etc/ppp/ppp.secret file, or + alternatively add the following option to authenticate users + via PAP from /etc/password file. + enable passwdauth - - option to authenticate users via pap from the - /etc/password file. - If you wish to assign some users a static IP number, you can - specify the number as the third argument in + If you wish to assign some users a static IP number, you + can specify the number as the third argument in /etc/ppp/ppp.secret. See /etc/ppp/ppp.secret.sample for examples. - + MS extensions - It is possible to configure PPP to supply DNS and NetBIOS - nameserver addresses on demand. + It is possible to configure PPP to supply DNS and + NetBIOS nameserver addresses on demand. To enable these extensions with PPP version 1.x, the following lines might be added to the relevant section of /etc/ppp/ppp.conf. - + enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 And for PPP version 2 and above: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 - - This will tell the clients the primary and secondary name - server addresses, and a netbios nameserver host. - In version 2 and above, if the set dns - line is omitted, PPP will use the values found in - /etc/resolv.conf. + This will tell the clients the primary and secondary + name server addresses, and a netbios nameserver host. + + In version 2 and above, if the + set dns line is omitted, PPP will use the + values found in /etc/resolv.conf. - - - - PAP and CHAP authentication - - Some ISPs set their system up so that the authentication part of - your connection is done using either of the PAP or CHAP - authentication mechanisms. If this is the case, your ISP will not - give a login: prompt when you connect, but will - start talking PPP immediately. - - PAP is less secure than CHAP, but security is not normally an - issue here as passwords, although being sent as plain text with PAP, - are being transmitted down a serial line only. There's not much room - for crackers to “eavesdrop”. - - Referring back to the PPP and - Static IP addresses or + PAP and CHAP authentication + + Some ISPs set their system up so that the authentication + part of your connection is done using either of the PAP or + CHAP authentication mechanisms. If this is the case, your ISP + will not give a login: prompt when you + connect, but will start talking PPP immediately. + + PAP is less secure than CHAP, but security is not normally + an issue here as passwords, although being sent as plain text + with PAP, are being transmitted down a serial line only. + There's not much room for crackers to + “eavesdrop”. + + Referring back to the PPP + and Static IP addresses or PPP and Dynamic IP addresses - sections, the following alterations must be made: - - + sections, the following alterations must be made: + + 7 set login … 12 set authname MyUserName 13 set authkey MyPassword - - As always, do not include the line numbers, they are just for - reference in this discussion. Indentation of at least one space is - required. - - - - Line 7: - - Your ISP will not normally require that you log into the - server if you're using PAP or CHAP. You must therefore - disable your "set login" string. - - - - - Line 12: - - - This line specifies your PAP/CHAP user name. You will - need to insert the correct value for - MyUserName. - - - - - Line 13: - - - This line specifies your PAP/CHAP password. You will need - to insert the correct value for - MyPassword. You may want to add an - additional line + As always, do not include the line numbers, they are just + for reference in this discussion. Indentation of at least one + space is required. + + + + Line 7: + + + Your ISP will not normally require that you log into + the server if you're using PAP or CHAP. You must + therefore disable your “set login” + string. + + + + + Line 12: + + + This line specifies your PAP/CHAP user name. You + will need to insert the correct value for + MyUserName. + + + + + Line 13: + + + This line specifies your PAP/CHAP password. You + will need to insert the correct value for + MyPassword. You may want to + add an additional line, such as: - + 15 accept PAP - or - - + or + + 15 accept CHAP - to make it obvious that this is the intention, but PAP and - CHAP are both accepted by default. - - - - - - - Changing your <command>ppp</command> configuration on the - fly + to make it obvious that this is the intention, but + PAP and CHAP are both accepted by default. + + + + - It is possible to talk to the ppp program - while it is running in the background, but only if a suitable - diagnostic port has been set up. To do this, add the following line - to your configuration: + + Changing your <command>ppp</command> configuration on the + fly - + It is possible to talk to the ppp + program while it is running in the background, but only if a + suitable diagnostic port has been set up. To do this, add the + following line to your configuration: + + set server /var/run/ppp-tun%d DiagnosticPassword 0177 - This will tell PPP to listen to the specified unix-domain - socket, asking clients for the specified password before allowing - access. The %d in the name is replaced with the - tun device number that is in use. - - Once a socket has been set up, the - &man.pppctl.8; program may be used in scripts that wish to - manipulate the running program. + This will tell PPP to listen to the specified unix-domain + socket, asking clients for the specified password before + allowing access. The %d in the name is + replaced with the tun device number + that is in use. + + Once a socket has been set up, the &man.pppctl.8; program + may be used in scripts that wish to manipulate the running + program. + - - - - Final system configuration - - You now have ppp configured, but there are a - few more things to do before it is ready to work. They all involve - editing the /etc/rc.conf file (was - /etc/sysconfig). - - Working from the top down in this file, make sure the - hostname= line is set, e.g.: - - -hostname=foo.bar.com - - If your ISP has supplied you with a static IP address and name, - it's probably best that you use this name as your host name. - - Look for the network_interfaces variable. If - you want to configure your system to dial your ISP on demand, make - sure the tun0 device is added to the list, - otherwise remove it. - - -network_interfaces="lo0 tun0" ifconfig_tun0= - - The ifconfig_tun0 variable should be empty, - and a file called /etc/start_if.tun0 should be - created. This file should contain the line + + Final system configuration + + You now have ppp configured, but there + are a few more things to do before it is ready to work. They + all involve editing the /etc/rc.conf + file. + + Working from the top down in this file, make sure the + hostname= line is set, e.g.: + + +hostname="foo.bar.com" + + If your ISP has supplied you with a static IP address and + name, it's probably best that you use this name as your host + name. + + Look for the network_interfaces variable. + If you want to configure your system to dial your ISP on demand, + make sure the tun0 device is added to + the list, otherwise remove it. +network_interfaces="lo0 tun0" ifconfig_tun0= + + + The ifconfig_tun0 variable should be + empty, and a file called + /etc/start_if.tun0 should be created. + This file should contain the line: + + ppp -auto mysystem - - This script is executed at network configuration time, starting - your ppp daemon in automatic mode. If you have a LAN for which this - machine is a gateway, you may also wish to use the - switch. Refer to the manual page for - further details. - - - Set the router program to NO with the - line - - -router_enable=NO (/etc/rc.conf) -router=NO (/etc/sysconfig) - - It is important that the routed daemon is not - started (it's started by default) as routed tends - to delete the default routing table entries created by - ppp. - - It is probably worth your while ensuring that the - sendmail_flags line does not include the - option, otherwise sendmail will - attempt to do a network lookup every now and then, possibly causing - your machine to dial out. You may try: - - + + This script is executed at network configuration time, + starting your ppp daemon in automatic mode. If you have a LAN + for which this machine is a gateway, you may also wish to use + the switch. Refer to the manual page + for further details. + + + Set the router program to NO with + following line in your /etc/rc.conf: + + +router_enable="NO" + + It is important that the routed daemon is + not started (it is started by default), as it + routed tends to delete the default routing + table entries created by ppp. + + It is probably worth your while ensuring that the + sendmail_flags line does not include the + option, otherwise + sendmail will attempt to do a network lookup + every now and then, possibly causing your machine to dial out. + You may try: + + sendmail_flags="-bd" - - The upshot of this is that you must force - sendmail to re-examine the mail queue whenever the - ppp link is up by typing: - - &prompt.root; /usr/sbin/sendmail -q - - You may wish to use the !bg command in - ppp.linkup to do this automatically: - - + + The downside of this is that you must force + sendmail to re-examine the mail queue + whenever the ppp link is up by typing: + + &prompt.root; /usr/sbin/sendmail -q + + You may wish to use the !bg command in + ppp.linkup to do this automatically: + + 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m - - If you don't like this, it is possible to set up a - “dfilter” to block SMTP traffic. Refer to the sample - files for further details. - - All that is left is to reboot the machine. - - After rebooting, you can now either type - - &prompt.root; ppp - - and then dial provider to start the PPP - session, or, if you want ppp to establish sessions - automatically when there is outbound traffic (and you haven't created - the start_if.tun0 script), type - - &prompt.root; ppp -auto provider - - - - Summary - - To recap, the following steps are necessary when setting up ppp - for the first time: - - Client side: - - - - Ensure that the tun device is built - into your kernel. - - - - Ensure that the - tunX device file - is available in the /dev directory. - - - Create an entry in /etc/ppp/ppp.conf. - The pmdemand example should suffice for most - ISPs. - + If you don't like this, it is possible to set up a + “dfilter” to block SMTP traffic. Refer to the + sample files for further details. - - If you have a dynamic IP address, create an entry in - /etc/ppp/ppp.linkup. - + Now the only thing left to do is reboot the machine. - - Update your /etc/rc.conf (or - sysconfig) file. - + All that is left is to reboot the machine. After rebooting, + you can now either type: - - Create a start_if.tun0 script if you - require demand dialing. - - - - Server side: - - - - Ensure that the tun device is built - into your kernel. - + &prompt.root; ppp - - Ensure that the - tunX device file - is available in the /dev directory. - + and then dial provider to start the PPP + session, or, if you want ppp to establish + sessions automatically when there is outbound traffic (and + you have not created the start_if.tun0 + script), type: - - Create an entry in /etc/passwd (using the - &man.vipw.8; program). - + &prompt.root; ppp -auto provider + - - Create a profile in this users home directory that runs - ppp -direct direct-server or similar. - + + Summary + + To recap, the following steps are necessary when setting up + ppp for the first time: + + Client side: + + + + Ensure that the tun device is + built into your kernel. + + + + Ensure that the + tunX device + file is available in the /dev + directory. + + + + Create an entry in + /etc/ppp/ppp.conf. The + pmdemand example should suffice for + most ISPs. + + + + If you have a dynamic IP address, create an entry in + /etc/ppp/ppp.linkup. + + + + Update your /etc/rc.conf + file. + + + + Create a start_if.tun0 script if + you require demand dialing. + + + + Server side: + + + + Ensure that the tun device is + built into your kernel. + + + + Ensure that the + tunX device + file is available in the /dev + directory. + + + + Create an entry in /etc/passwd + (using the &man.vipw.8; program). + + + + Create a profile in this users home directory that runs + ppp -direct direct-server or + similar. + + + + Create an entry in + /etc/ppp/ppp.conf. The + direct-server example should + suffice. + + + + Create an entry in + /etc/ppp/ppp.linkup. + + + + Update your /etc/rc.conf + file. + + + + + - - Create an entry in /etc/ppp/ppp.conf. - The direct-server example should - suffice. - + + Using Kernel PPP - - Create an entry in - /etc/ppp/ppp.linkup. - + Parts originally contributed by &a.gena; and + &a.rhuff;. - - Update your /etc/rc.conf (or - sysconfig) file. - - - - - Acknowledgments - - This section of the handbook was last updated on Monday Aug 10, - 1998 by &a.brian; - - Thanks to the following for their input, comments & - suggestions: - - &a.nik; - - &a.dirkvangulik; - - &a.pjc; - - - - - Setting up Kernel PPP - - Contributed by &a.gena;. - - Before you start setting up PPP on your machine make sure that - pppd is located in /usr/sbin and - directory /etc/ppp exists. + Setting up Kernel PPP - pppd can work in two modes: + Before you start setting up PPP on your machine make sure + that pppd is located in + /usr/sbin and the directory + /etc/ppp exists. - - - as a “client”, i.e. you want to connect your machine - to outside world via PPP serial connection or modem line. - - - - as a “server”, i.e. your machine is located on the - network and used to connect other computers using PPP. - - - - In both cases you will need to set up an options file - (/etc/ppp/options or ~/.ppprc - if you have more then one user on your machine that uses PPP). + pppd can work in two modes: + + + + As a “client”, i.e., you want to connect your + machine to the outside world via a PPP serial connection or + modem line. + + + + as a “server”, i.e. your machine is located on + the network and used to connect other computers using + PPP. + + + + In both cases you will need to set up an options file + (/etc/ppp/options or + ~/.ppprc if you have more than one user on + your machine that uses PPP). - You also will need some modem/serial software (preferably kermit) so - you can dial and establish connection with remote host. + You also will need some modem/serial software (preferably + kermit) so you can dial and establish a connection with the + remote host. + - Working as a PPP client - + Using <command>pppd</command> as a client + I used the following /etc/ppp/options to connect to CISCO terminal server PPP line. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router - + To connect: - Dial to the remote host using kermit (or other modem program) - enter your user name and password (or whatever is needed to enable - PPP on the remote host) + Dial to the remote host using kermit (or some other modem + program), and enter your user name and password (or whatever + is needed to enable PPP on the remote host). Exit kermit (without hanging up the line). - enter: - + Enter the following: + &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 - Use the appropriate speed and device name. + Be sure to use the appropriate speed and device name. - - Now your computer is connected with PPP. If the connection fails - for some reasons you can add the option to the - /etc/ppp/options file and check messages on the - console to track the problem + + Now your computer is connected with PPP. If the connection + fails, you can add the option to the + /etc/ppp/options file and check messages on + the console to track the problem. - Following /etc/ppp/pppup script will make all - 3 stages automatically: + Following /etc/ppp/pppup script will make + all 3 stages automatically: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 - - /etc/ppp/kermit.dial is kermit script that - dials and makes all necessary authorization on the remote host. - (Example of such script is attached to the end of this - document) - - Use the following /etc/ppp/pppdown script to - disconnect the PPP line: + + /etc/ppp/kermit.dial is a kermit script + that dials and makes all necessary authorization on the remote + host (an example of such a script is attached to the end of this + document). + + Use the following /etc/ppp/pppdown script + to disconnect the PPP line: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest - - Check if PPP is still running - (/usr/etc/ppp/ppptest): + + Check to see if PPP is still running by executing + /usr/etc/ppp/ppptest, which should look like + this: #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 - - Hangs up modem line - (/etc/ppp/kermit.hup): + + To hang up the modem, execute + /etc/ppp/kermit.hup, which should + contain: set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit - - Here is an alternate method using chat instead - of kermit. - - Contributed by &a.rhuff;. - + + Here is an alternate method using chat + instead of kermit. + The following two files are sufficient to accomplish a pppd connection. - + /etc/ppp/options: - + /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router - + /etc/ppp/login.chat.script: - - (This should actually go into a single line.) - + + + The following should go on a single line. + + ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> - - Once these are installed and modified correctly, all you need to - do is - + + Once these are installed and modified correctly, all you need + to do is run pppd, like so: + &prompt.root; pppd - - This sample based primarily on information provided by: Trev - Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> and used by - permission. + + This sample is based primarily on information provided by: + Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> + and used with permission. - + - Working as a PPP server - - /etc/ppp/options: + Using <command>pppd</command> as a server + + /etc/ppp/options should contain something + similar to the following: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line - - Following /etc/ppp/pppserv script will enable - ppp server on your machine: + + The following /etc/ppp/pppserv script + will enable tell pppd to behave as a + server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 - - Use this /etc/ppp/pppservdown script to stop - ppp server: + + Use this /etc/ppp/pppservdown script to + stop the server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans - - Following kermit script will enable/disable autoanswer mode on - your modem (/etc/ppp/kermit.ans): + + The following kermit script + (/etc/ppp/kermit.ans) will enable/disable + autoanswer mode on your modem. It should look like this: set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit - - This /etc/ppp/kermit.dial script is used for - dialing and authorizing on remote host. You will need to customize it - for your needs. Put your login and password in this script, also you - will need to change input statement depending on responses from your - modem and remote host. + + A script named /etc/ppp/kermit.dial is + used for dialing and authenticating on the remote host. You will + need to customize it for your needs. Put your login and password + in this script; you will also need to change the input statement + depending on responses from your modem and remote host. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: - + - Setting up PPP over Ethernet (PPPoE) + Using PPP over Ethernet (PPPoE) Contributed by &a.jim; (from node.to) 10 Jan 2000. The following describes how to set up PPP over Ethernet, a.k.a, PPPoE. Prerequisites There are a few requirements that your system will need to meet in order for PPPoE to function properly. They are: Kernel source for FreeBSD &rel.current;-STABLE ppp and pppd from FreeBSD &rel.current;-STABLE Any dependencies for the above Kernel Configuration You will need to set the following options in your kernel configuration and then compile a new kernel. options NETGRAPH options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_CISCO options NETGRAPH_ECHO options NETGRAPH_FRAME_RELAY options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_LMI options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options "NETGRAPH_RFC1490" options NETGRAPH_SOCKET options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC Add the above to your kernel configuration, recompile, install, and then reboot your system. Setting up <filename>ppp.conf</filename> Here is an example of a working ppp.conf: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set MRU 1490 set MTU 1490 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login "TIMEOUT 1.5 name:-\\r-login:\\U word:\\P ocol:PPP HELLO" # this isn't necessary set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net set cd off set crtscts off papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD Running <application>PPP</application> As root, you can run either: &prompt.root; ppp -dedicated or &prompt.root; ppp -dedicated name_of_service_provider depending on how you have set up ppp.conf. Starting <application>PPP</application> at Boot Add the following to your /etc/rc.conf file: ppp_enable="YES" ppp_mode="dedicated" ppp_nat="YES" ppp_profile="default" # or your provider - - Setting up a SLIP Client - - Contributed by &a.asami; 8 Aug 1995. - - The following is one way to set up a FreeBSD machine for SLIP on a - static host network. For dynamic hostname assignments (i.e., your - address changes each time you dial up), you probably need to do - something much fancier. - - First, determine which serial port your modem is connected to. I - have a symbolic link to /dev/modem from - /dev/cuaa1, and only use the modem name in my - configuration files. It can become quite cumbersome when you need to - fix a bunch of files in /etc and - .kermrc's all over the system! - - - /dev/cuaa0 is COM1, - cuaa1 is COM2, - etc. - - - Make sure you have + + Using SLIP + + Originally contributed by &a.asami; and + &a.ghelmer;, with input from &a.wilko; and + &a.piero;. + + + Setting up a SLIP Client + + The following is one way to set up a FreeBSD machine for SLIP + on a static host network. For dynamic hostname assignments (i.e., + your address changes each time you dial up), you probably need to + do something much fancier. + + First, determine which serial port your modem is connected to. + I have a symbolic link to /dev/modem from + /dev/cuaa1, and only use the modem name in + my configuration files. It can become quite cumbersome when you + need to fix a bunch of files in /etc and + .kermrc's all over the system! + + + /dev/cuaa0 is + COM1, cuaa1 is + COM2, etc. + + + Make sure you have the following in your kernel configuration + file: pseudo-device sl 1 - in your kernel's config file. It is included in the - GENERIC kernel, so this will not be a problem - unless you deleted it. + It is included in the GENERIC kernel, so + this should not be a problem unless you have deleted it. - - Things you have to do only once - - - - Add your home machine, the gateway and nameservers to your - /etc/hosts file. Mine looks like - this: + + Things you have to do only once - + + + Add your home machine, the gateway and nameservers to + your /etc/hosts file. Mine looks like + this: + + 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 - - By the way, silvia is the name of the car that I had when I - was back in Japan (it is called 2?0SX here in U.S.). - + + + + Make sure you have before + in your + /etc/host.conf. Otherwise, funny + things may happen. + + + + Edit the /etc/rc.conf file. + + + + Set your hostname by editing the line that + says: - - Make sure you have before - in your /etc/host.conf. - Otherwise, funny things may happen. - + +hostname=“myname.my.domain” - - Edit the file /etc/rc.conf. Note that - you should edit the file /etc/sysconfig - instead if you are running FreeBSD previous to version - 2.2.2. - - - - Set your hostname by editing the line that says: - - -hostname=myname.my.domain + You should give it your full Internet + hostname. + - You should give it your full Internet hostname. - - - - Add sl0 to the list of network interfaces by changing the - line that says: - - + + Add sl0 to the list of network interfaces by + changing the line that says: + + network_interfaces="lo0" - to: - - -network_interfaces="lo0 sl0" - - - - Set the startup flags of sl0 by adding a line: - - + to: + + +network_interfaces=“lo0 sl0” + + + + Set the startup flags of sl0 by adding a + line: + + ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" - - - - Designate the default router by changing the line: + - -defaultrouter=NO + + Designate the default router by changing the + line: - to: + +defaultrouter=“NO” - -defaultrouter=slip-gateway - - - + to: - - Make a file /etc/resolv.conf which - contains: + +defaultrouter=“slip-gateway” + + + - -domain HIP.Berkeley.EDU -nameserver 128.32.136.9 -nameserver 128.32.136.12 + + Make a file /etc/resolv.conf which + contains: - As you can see, these set up the nameserver hosts. Of course, - the actual domain names and addresses depend on your - environment. - - - - Set the password for root and toor (and any other accounts - that does not have a password). Use passwd, do not edit the - /etc/passwd or - /etc/master.passwd files! - - - - Reboot your machine and make sure it comes up with the correct - hostname. - - - - - - Making a SLIP connection - - - - Dial up, type slip at the prompt, enter - your machine name and password. The things you need to enter - depends on your environment. I use kermit, with a script like - this: + +domain HIP.Berkeley.EDU +nameserver 128.32.136.9 +nameserver 128.32.136.12 - + As you can see, these set up the nameserver hosts. Of + course, the actual domain names and addresses depend on your + environment. + + + + Set the password for root and toor (and any other + accounts that do not have a password). Use passwd or + &man.vipw.8;, do not edit the + /etc/passwd or + /etc/master.passwd files! + + + + Reboot your machine and make sure it comes up with the + correct hostname. + + + + + + Making a SLIP connection + + + + Dial up, type slip at the prompt, + enter your machine name and password. The things you need + to enter depends on your environment. I use kermit, with a + script like this: + + # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login -define slip dial 643-9600, input 10 =>, if failure stop, - +define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a - (of course, you have to change the hostname and password to - fit yours). Then you can just type slip from - the kermit prompt to get connected. + Of course, you have to change the hostname and password + to fit yours. After doing so, you can just type + slip from the kermit prompt to get + connected. + + + Leaving your password in plain text anywhere in the + filesystem is generally a BAD idea. Do it at your own + risk. + + + + + Leave the kermit there (you can suspend it by + z) and as root, type: + + &prompt.root; slattach -h -c -s 115200 /dev/modem + + If you are able to ping hosts on the + other side of the router, you are connected! If it does not + work, you might want to try instead of + as an argument to slattach. + + + - - Leaving your password in plain text anywhere in the - filesystem is generally a BAD idea. Do it at your own risk. I - am just too lazy. - - + + How to shutdown the connection - - Leave the kermit there (you can suspend it by - z) and as root, type: - - &prompt.root; slattach -h -c -s 115200 /dev/modem - - If you are able to ping hosts on the other - side of the router, you are connected! If it does not work, you - might want to try instead of - as an argument to slattach. - - - + Do the following: - - How to shutdown the connection - - Type - - &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` + &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` - (as root) to kill slattach. Then go back to kermit - (fg if you suspended it) and exit from it - (q). + to kill slattach. Keep in mind you must be + root to do the above. Then go back to + kermit (fg if you suspended it) and exit from + it (q). - The slattach man page says you have to use ifconfig sl0 - down to mark the interface down, but this does not seem to - make any difference for me. (ifconfig sl0 reports - the same thing.) - - Some times, your modem might refuse to drop the carrier (mine - often does). In that case, simply start kermit and quit it again. It - usually goes out on the second try. - - - - Troubleshooting - - If it does not work, feel free to ask me. The things that people - tripped over so far: - - - - Not using or in - slattach (I have no idea why this can be fatal, but adding this - flag solved the problem for at least one person) - + The slattach man page says you have to use ifconfig + sl0 down to mark the interface down, but this does not + seem to make any difference for me. + (ifconfig sl0 reports the same thing.) - - Using instead of - (might be hard to see the difference on some fonts). - + Some times, your modem might refuse to drop the carrier + (mine often does). In that case, simply start kermit and quit + it again. It usually goes out on the second try. + - - Try ifconfig sl0 to see your interface - status. I get: - - &prompt.root; ifconfig sl0 + + Troubleshooting + + If it does not work, feel free to ask me. The things that + people tripped over so far: + + + + Not using or in + slattach (I have no idea why this can be fatal, but adding + this flag solved the problem for at least one + person). + + + + Using instead of + (might be hard to see the difference on + some fonts). + + + + Try ifconfig sl0 to see your + interface status. I get: + + &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 - - - - Also, netstat -r will give the routing - table, in case you get the "no route to host" messages from ping. - Mine looks like: + + + + Also, netstat -r will give the + routing table, in case you get the “no route to + host” messages from ping. Mine looks like: - &prompt.root; netstat -r + &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) - - (this is after transferring a bunch of files, your numbers - should be smaller). - - - - - - - Setting up a SLIP Server - - Contributed by &a.ghelmer;. v1.0, 15 May - 1995. - - This document provides suggestions for setting up SLIP Server - services on a FreeBSD system, which typically means configuring your - system to automatically startup connections upon login for remote SLIP - clients. The author has written this document based on his experience; - however, as your system and needs may be different, this document may - not answer all of your questions, and the author cannot be responsible - if you damage your system or lose data due to attempting to follow the - suggestions here. - - This guide was originally written for SLIP Server services on a - FreeBSD 1.x system. It has been modified to reflect changes in the - pathnames and the removal of the SLIP interface compression flags in - early versions of FreeBSD 2.X, which appear to be the only major changes - between FreeBSD versions. If you do encounter mistakes in this - document, please email the author with enough information to help - correct the problem. - - - Prerequisites - - This document is very technical in nature, so background knowledge - is required. It is assumed that you are familiar with the TCP/IP - network protocol, and in particular, network and node addressing, - network address masks, subnetting, routing, and routing protocols, - such as RIP. Configuring SLIP services on a dial-up server requires a - knowledge of these concepts, and if you are not familiar with them, - please read a copy of either Craig Hunt's TCP/IP Network - Administration published by O'Reilly & Associates, - Inc. (ISBN Number 0-937175-82-X), or Douglas Comer's books on the - TCP/IP protocol. - - It is further assumed that you have already setup your modem(s) - and configured the appropriate system files to allow logins through - your modems. If you have not prepared your system for this yet, - please see the tutorial for configuring dialup services; if you have a - World-Wide Web browser available, browse the list of tutorials at - http://www.FreeBSD.org/; - otherwise, check the place where you found this document for a - document named dialup.txt or something similar. - You may also want to check the manual pages for - &man.sio.4; for information on the serial port device driver and - &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, & &man.init.8; - for information relevant to configuring the system to accept logins on - modems, and perhaps &man.stty.1; for information on setting serial - port parameters (such as clocal for - directly-connected serial interfaces). + + This is after transferring a bunch of files, your + numbers should be smaller). + + + - - - Quick Overview - - In its typical configuration, using FreeBSD as a SLIP server works - as follows: a SLIP user dials up your FreeBSD SLIP Server system and - logs in with a special SLIP login ID that uses - /usr/sbin/sliplogin as the special user's shell. - The sliplogin program browses the file - /etc/sliphome/slip.hosts to find a matching line - for the special user, and if it finds a match, connects the serial - line to an available SLIP interface and then runs the shell script - /etc/sliphome/slip.login to configure the SLIP - interface. - + + + Setting up a SLIP Server + + This document provides suggestions for setting up SLIP Server + services on a FreeBSD system, which typically means configuring + your system to automatically startup connections upon login for + remote SLIP clients. The author has written this document based + on his experience; however, as your system and needs may be + different, this document may not answer all of your questions, and + the author cannot be responsible if you damage your system or lose + data due to attempting to follow the suggestions here. + + + Prerequisites + + This document is very technical in nature, so background + knowledge is required. It is assumed that you are familiar with + the TCP/IP network protocol, and in particular, network and node + addressing, network address masks, subnetting, routing, and + routing protocols, such as RIP. Configuring SLIP services on a + dial-up server requires a knowledge of these concepts, and if + you are not familiar with them, please read a copy of either + Craig Hunt's TCP/IP Network Administration + published by O'Reilly & Associates, Inc. (ISBN Number + 0-937175-82-X), or Douglas Comer's books on the TCP/IP + protocol. + + It is further assumed that you have already setup your + modem(s) and configured the appropriate system files to allow + logins through your modems. If you have not prepared your + system for this yet, please see the tutorial for configuring + dialup services; if you have a World-Wide Web browser available, + browse the list of tutorials at http://www.FreeBSD.org/. + You may also want to check the manual pages for &man.sio.4; for + information on the serial port device driver and &man.ttys.5;, + &man.gettytab.5;, &man.getty.8;, & &man.init.8; for + information relevant to configuring the system to accept logins + on modems, and perhaps &man.stty.1; for information on setting + serial port parameters (such as clocal for + directly-connected serial interfaces). + + - An Example of a SLIP Server Login + Quick Overview + + In its typical configuration, using FreeBSD as a SLIP server + works as follows: a SLIP user dials up your FreeBSD SLIP Server + system and logs in with a special SLIP login ID that uses + /usr/sbin/sliplogin as the special user's + shell. The sliplogin program browses the + file /etc/sliphome/slip.hosts to find a + matching line for the special user, and if it finds a match, + connects the serial line to an available SLIP interface and then + runs the shell script + /etc/sliphome/slip.login to configure the + SLIP interface. + + + An Example of a SLIP Server Login + + For example, if a SLIP user ID were + Shelmerg, Shelmerg's + entry in /etc/master.passwd would look + something like this (except it would be all on one + line): - For example, if a SLIP user ID were - Shelmerg, Shelmerg's entry - in /etc/master.passwd would look something like - this (except it would be all on one line): - - + Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin - - When Shelmerg logs in, - sliplogin will search - /etc/sliphome/slip.hosts for a line that had a - matching user ID; for example, there may be a line in - /etc/sliphome/slip.hosts that reads: - - + + When Shelmerg logs in, + sliplogin will search + /etc/sliphome/slip.hosts for a line that + had a matching user ID; for example, there may be a line in + /etc/sliphome/slip.hosts that + reads: + + Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - - sliplogin will find that matching line, hook - the serial line into the next available SLIP interface, and then - execute /etc/sliphome/slip.login like - this: - - + + sliplogin will find that matching line, + hook the serial line into the next available SLIP interface, + and then execute /etc/sliphome/slip.login + like this: + + /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - - If all goes well, /etc/sliphome/slip.login - will issue an ifconfig for the SLIP interface to - which sliplogin attached itself (slip interface - 0, in the above example, which was the first parameter in the list - given to slip.login) to set the local IP - address (dc-slip), remote IP address - (sl-helmer), network mask for the SLIP interface - (0xfffffc00), and any additional - flags (autocomp). If something goes wrong, - sliplogin usually logs good informational - messages via the daemon syslog facility, which - usually goes into /var/log/messages (see the - manual pages for &man.syslogd.8; and - &man.syslog.conf.5, and perhaps check - /etc/syslog.conf to see to which files - syslogd is logging). - - OK, enough of the examples — let us dive into setting up - the system. + + If all goes well, + /etc/sliphome/slip.login will issue an + ifconfig for the SLIP interface to which + sliplogin attached itself (slip interface + 0,in the above example, which was the first parameter in the + list given to slip.login) to set the + local IP address (dc-slip), remote IP address + (sl-helmer), network mask for the SLIP + interface (0xfffffc00), and + any additional flags (autocomp). If + something goes wrong, sliplogin usually + logs good informational messages via the + daemon syslog facility, which usually goes + into /var/log/messages (see the manual + pages for &man.syslogd.8; and &man.syslog.conf.5; and perhaps + check /etc/syslog.conf to see to which + files syslogd is logging). + + OK, enough of the examples — let us dive into + setting up the system. + - - - - Kernel Configuration - - FreeBSD's default kernels usually come with two SLIP interfaces - defined (sl0 and - sl1); you can use netstat + + + Kernel Configuration + + FreeBSD's default kernels usually come with two SLIP + interfaces defined (sl0 and + sl1); you can use netstat -i to see whether these interfaces are defined in your - kernel. - - Sample output from netstat -i: - - Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll + kernel. + + Sample output from netstat -i: + + Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 - - The sl0 and sl1 - interfaces shown in netstat -i's output indicate - that there are two SLIP interfaces built into the kernel. (The - asterisks after the sl0 and sl1 - indicate that the interfaces are “down”.) - - However, FreeBSD's default kernels do not come configured to - forward packets (ie, your FreeBSD machine will not act as a router) - due to Internet RFC requirements for Internet hosts (see RFC's 1009 - [Requirements for Internet Gateways], 1122 [Requirements for Internet - Hosts — Communication Layers], and perhaps 1127 [A Perspective - on the Host Requirements RFCs]), so if you want your FreeBSD SLIP - Server to act as a router, you will have to edit the - /etc/rc.conf file (called - /etc/sysconfig in FreeBSD releases prior to - 2.2.2) and change the setting of the gateway - variable to . If you have an older system which - predates even the /etc/sysconfig file, then add - the following command: - -sysctl -w net.inet.ip.forwarding = 1 + The sl0 and + sl1 interfaces shown in + netstat -i's output indicate that there are + two SLIP interfaces built into the kernel. (The asterisks after + the sl0 and sl1 indicate + that the interfaces are “down”.) + + However, FreeBSD's default kernels do not come configured + to forward packets (ie, your FreeBSD machine will not act as a + router) due to Internet RFC requirements for Internet hosts (see + RFCs 1009 [Requirements for Internet Gateways], 1122 + [Requirements for Internet Hosts — Communication Layers], + and perhaps 1127 [A Perspective on the Host Requirements RFCs]), + so if you want your FreeBSD SLIP Server to act as a router, you + will have to edit the /etc/rc.conf file and + change the setting of the gateway variable to + . + + You will then need to reboot for the new settings to take + effect. + + You will notice that near the end of the default kernel + configuration file (/sys/i386/conf/GENERIC) + is a line that reads: - to your /etc/rc.local file. - - You will then need to reboot for the new settings to take - effect. - - You will notice that near the end of the default kernel - configuration file (/sys/i386/conf/GENERIC) is a - line that reads: - - + pseudo-device sl 2 - - This is the line that defines the number of SLIP devices available - in the kernel; the number at the end of the line is the maximum number - of SLIP connections that may be operating simultaneously. - - Please refer to Configuring the - FreeBSD Kernel for help in reconfiguring your kernel. - - - - Sliplogin Configuration - - As mentioned earlier, there are three files in the - /etc/sliphome directory that are part of the - configuration for /usr/sbin/sliplogin (see - &man.sliplogin.8; for the actual manual page for - sliplogin): slip.hosts, which - defines the SLIP users & their associated IP addresses; - slip.login, which usually just configures the - SLIP interface; and (optionally) slip.logout, - which undoes slip.login's effects when the serial - connection is terminated. - + + This is the line that defines the number of SLIP devices + available in the kernel; the number at the end of the line is + the maximum number of SLIP connections that may be operating + simultaneously. + + Please refer to Configuring the + FreeBSD Kernel for help in reconfiguring your + kernel. + + - <filename>slip.hosts</filename> Configuration + Sliplogin Configuration + + As mentioned earlier, there are three files in the + /etc/sliphome directory that are part of + the configuration for /usr/sbin/sliplogin + (see &man.sliplogin.8; for the actual manual page for + sliplogin): slip.hosts, + which defines the SLIP users & their associated IP + addresses; slip.login, which usually just + configures the SLIP interface; and (optionally) + slip.logout, which undoes + slip.login's effects when the serial + connection is terminated. + + + <filename>slip.hosts</filename> Configuration + + /etc/sliphome/slip.hosts contains + lines which have at least four items, separated by + whitespace: + + + + SLIP user's login ID + - /etc/sliphome/slip.hosts contains lines - which have at least four items, separated by whitespace: + + Local address (local to the SLIP server) of the SLIP + link + - - - SLIP user's login ID - - - - Local address (local to the SLIP server) of the SLIP - link - - - - Remote address of the SLIP link - - - - Network mask - - + + Remote address of the SLIP link + - The local and remote addresses may be host names (resolved to IP - addresses by /etc/hosts or by the domain name - service, depending on your specifications in - /etc/host.conf), and I believe the network mask - may be a name that can be resolved by a lookup into - /etc/networks. On a sample system, - /etc/sliphome/slip.hosts looks like - this: - - + + Network mask + + + + The local and remote addresses may be host names (resolved + to IP addresses by /etc/hosts or by the + domain name service, depending on your specifications in + /etc/host.conf), and I believe the + network mask may be a name that can be resolved by a lookup + into /etc/networks. On a sample system, + /etc/sliphome/slip.hosts looks like + this: + + # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp - - At the end of the line is one or more of the options. - - - — no header compression - - - - — compress headers - - - - — compress headers if the - remote end allows it - - - - — disable ICMP packets (so any - “ping” packets will be dropped instead of using up - your bandwidth) - - + At the end of the line is one or more of the + options. - Note that sliplogin under early releases of - FreeBSD 2 ignored the options that FreeBSD 1.x recognized, so the - options , , - , and had no effect - until support was added in FreeBSD 2.2 (unless your - slip.login script included code to make use of - the flags). - - Your choice of local and remote addresses for your SLIP links - depends on whether you are going to dedicate a TCP/IP subnet or if - you are going to use “proxy ARP” on your SLIP server (it - is not “true” proxy ARP, but that is the terminology - used in this document to describe it). If you are not sure which - method to select or how to assign IP addresses, please refer to the - TCP/IP books referenced in the slips-prereqs section and/or - consult your IP network manager. - - If you are going to use a separate subnet for your SLIP clients, - you will need to allocate the subnet number out of your assigned IP - network number and assign each of your SLIP client's IP numbers out - of that subnet. Then, you will probably either need to configure a - static route to the SLIP subnet via your SLIP server on your nearest - IP router, or install gated on your FreeBSD SLIP - server and configure it to talk the appropriate routing protocols to - your other routers to inform them about your SLIP server's route to - the SLIP subnet. - - Otherwise, if you will use the “proxy ARP” method, - you will need to assign your SLIP client's IP addresses out of your - SLIP server's Ethernet subnet, and you will also need to adjust your - /etc/sliphome/slip.login and - /etc/sliphome/slip.logout scripts to use - &man.arp.8; to manage the proxy-ARP entries in the SLIP server's - ARP table. - - - - <filename>slip.login</filename> Configuration + + + — no header + compression + - The typical /etc/sliphome/slip.login file - looks like this: - - + + — compress + headers + + + + — compress headers if + the remote end allows it + + + + — disable ICMP packets + (so any “ping” packets will be dropped instead + of using up your bandwidth) + + + + Note that sliplogin under early releases + of FreeBSD 2 ignored the options that FreeBSD 1.x recognized, + so the options , + , , and + had no effect until support was added + in FreeBSD 2.2 (unless your slip.login + script included code to make use of the flags). + + Your choice of local and remote addresses for your SLIP + links depends on whether you are going to dedicate a TCP/IP + subnet or if you are going to use “proxy ARP” on + your SLIP server (it is not “true” proxy ARP, but + that is the terminology used in this document to describe it). + If you are not sure which method to select or how to assign IP + addresses, please refer to the TCP/IP books referenced in the + slips-prereqs section + and/or consult your IP network manager. + + If you are going to use a separate subnet for your SLIP + clients, you will need to allocate the subnet number out of + your assigned IP network number and assign each of your SLIP + client's IP numbers out of that subnet. Then, you will + probably either need to configure a static route to the SLIP + subnet via your SLIP server on your nearest IP router, or + install gated on your FreeBSD SLIP server + and configure it to talk the appropriate routing protocols to + your other routers to inform them about your SLIP server's + route to the SLIP subnet. + + Otherwise, if you will use the “proxy ARP” + method, you will need to assign your SLIP client's IP + addresses out of your SLIP server's Ethernet subnet, and you + will also need to adjust your + /etc/sliphome/slip.login and + /etc/sliphome/slip.logout scripts to use + &man.arp.8; to manage the proxy-ARP entries in the SLIP + server's ARP table. + + + + <filename>slip.login</filename> Configuration + + The typical /etc/sliphome/slip.login + file looks like this: + + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 - - This slip.login file merely - ifconfig's the appropriate SLIP interface with - the local and remote addresses and network mask of the SLIP - interface. - - If you have decided to use the “proxy ARP” method - (instead of using a separate subnet for your SLIP clients), your - /etc/sliphome/slip.login file will need to look - something like this: - - + + This slip.login file merely + ifconfig's the appropriate SLIP interface + with the local and remote addresses and network mask of the + SLIP interface. + + If you have decided to use the “proxy ARP” + method (instead of using a separate subnet for your SLIP + clients), your /etc/sliphome/slip.login + file will need to look something like this: + + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub - - The additional line in this slip.login, - arp -s $5 00:11:22:33:44:55 pub, creates an - ARP entry in the SLIP server's ARP table. This ARP entry causes the - SLIP server to respond with the SLIP server's Ethernet MAC address - whenever a another IP node on the Ethernet asks to speak to the SLIP - client's IP address. - - When using the example above, be sure to replace the Ethernet - MAC address (00:11:22:33:44:55) with the - MAC address of your system's Ethernet card, or your “proxy - ARP” will definitely not work! You can discover your SLIP - server's Ethernet MAC address by looking at the results of running - netstat -i; the second line of the output should - look something like: - - ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 - - This indicates that this particular system's Ethernet MAC - address is 00:02:c1:28:5f:4a — the - periods in the Ethernet MAC address given by netstat - -i must be changed to colons and leading zeros should be - added to each single-digit hexadecimal number to convert the address - into the form that - &man.arp.8; desires; see the manual page on &man.arp.8; for - complete information on usage. - - When you create /etc/sliphome/slip.login - and /etc/sliphome/slip.logout, the - “execute” bit (ie, chmod 755 + The additional line in this + slip.login, arp -s + $5 00:11:22:33:44:55 pub, creates an ARP entry + in the SLIP server's ARP table. This ARP entry causes the + SLIP server to respond with the SLIP server's Ethernet MAC + address whenever a another IP node on the Ethernet asks to + speak to the SLIP client's IP address. + + When using the example above, be sure to replace the + Ethernet MAC address (00:11:22:33:44:55) with the MAC address of + your system's Ethernet card, or your “proxy ARP” + will definitely not work! You can discover your SLIP server's + Ethernet MAC address by looking at the results of running + netstat -i; the second line of the output + should look something like: + + ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 + + This indicates that this particular system's Ethernet MAC + address is 00:02:c1:28:5f:4a + — the periods in the Ethernet MAC address given by + netstat -i must be changed to colons and + leading zeros should be added to each single-digit hexadecimal + number to convert the address into the form that &man.arp.8; + desires; see the manual page on &man.arp.8; for complete + information on usage. + + + When you create + /etc/sliphome/slip.login and + /etc/sliphome/slip.logout, the + “execute” bit (ie, chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) - must be set, or sliplogin will be unable to - execute it. - - - - - <filename>slip.logout</filename> Configuration + must be set, or sliplogin will be unable + to execute it. + + - /etc/sliphome/slip.logout is not strictly - needed (unless you are implementing “proxy ARP”), but if - you decide to create it, this is an example of a basic - slip.logout script: - - + + <filename>slip.logout</filename> Configuration + + /etc/sliphome/slip.logout is not + strictly needed (unless you are implementing “proxy + ARP”), but if you decide to create it, this is an + example of a basic + slip.logout script: + + #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down - If you are using “proxy ARP”, you will want to have - /etc/sliphome/slip.logout remove the ARP entry - for the SLIP client: - - + If you are using “proxy ARP”, you will want to + have /etc/sliphome/slip.logout remove the + ARP entry for the SLIP client: + + #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 - - The arp -d $5 removes the ARP entry that - the “proxy ARP” slip.login added - when the SLIP client logged in. - - It bears repeating: make sure - /etc/sliphome/slip.logout has the execute - bit set for after you create it (ie, chmod - 755 /etc/sliphome/slip.logout). - - - - - Routing Considerations - - If you are not using the “proxy ARP” method for - routing packets between your SLIP clients and the rest of your network - (and perhaps the Internet), you will probably either have to add - static routes to your closest default router(s) to route your SLIP - client subnet via your SLIP server, or you will probably need to - install and configure gated on your FreeBSD SLIP - server so that it will tell your routers via appropriate routing - protocols about your SLIP subnet. - - - Static Routes - - Adding static routes to your nearest default routers can be - troublesome (or impossible, if you do not have authority to do - so...). If you have a multiple-router network in your organization, - some routers, such as Cisco and Proteon, may not only need to be - configured with the static route to the SLIP subnet, but also need - to be told which static routes to tell other routers about, so some - expertise and troubleshooting/tweaking may be necessary to get - static-route-based routing to work. + + The arp -d $5 removes the ARP entry + that the “proxy ARP” + slip.login added when the SLIP client + logged in. + + It bears repeating: make sure + /etc/sliphome/slip.logout has the execute + bit set for after you create it (ie, chmod 755 + /etc/sliphome/slip.logout). + - + - Running <command>gated</command> - - An alternative to the headaches of static routes is to install - gated on your FreeBSD SLIP server and configure - it to use the appropriate routing protocols (RIP/OSPF/BGP/EGP) to - tell other routers about your SLIP subnet. You can use - gated from the ports - collection or retrieve and build it yourself from Routing Considerations + + If you are not using the “proxy ARP” method for + routing packets between your SLIP clients and the rest of your + network (and perhaps the Internet), you will probably either + have to add static routes to your closest default router(s) to + route your SLIP client subnet via your SLIP server, or you will + probably need to install and configure gated + on your FreeBSD SLIP server so that it will tell your routers + via appropriate routing protocols about your SLIP subnet. + + + Static Routes + + Adding static routes to your nearest default routers can + be troublesome (or impossible, if you do not have authority to + do so...). If you have a multiple-router network in your + organization, some routers, such as Cisco and Proteon, may + not only need to be configured with the static route to the + SLIP subnet, but also need to be told which static routes to + tell other routers about, so some expertise and + troubleshooting/tweaking may be necessary to get + static-route-based routing to work. + + + + Running <command>gated</command> + + An alternative to the headaches of static routes is to + install gated on your FreeBSD SLIP server + and configure it to use the appropriate routing protocols + (RIP/OSPF/BGP/EGP) to tell other routers about your SLIP + subnet. You can use gated from the ports collection or retrieve and build + it yourself from the - GateD anonymous ftp site; I believe the current version as - of this writing is gated-R3_5Alpha_8.tar.Z, - which includes support for FreeBSD “out-of-the-box”. - Complete information and documentation on gated - is available on the Web starting at ; I believe the current version + as of this writing is + gated-R3_5Alpha_8.tar.Z, which includes + support for FreeBSD “out-of-the-box”. Complete + information and documentation on gated is + available on the Web starting at the Merit GateD Consortium. Compile and install it, and then write a - /etc/gated.conf file to configure your gated; - here is a sample, similar to what the author used on a FreeBSD SLIP - server: - - + /etc/gated.conf file to configure your + gated; here is a sample, similar to what the author used on a + FreeBSD SLIP server: + + # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; - - The above sample gated.conf file broadcasts - routing information regarding the SLIP subnet - xxx.xxx.yy via RIP onto the Ethernet; if - you are using a different Ethernet driver than the - ed driver, you will need to change the - references to the ed interface - appropriately. This sample file also sets up tracing to - /var/tmp/gated.output for debugging - gated's activity; you can certainly turn off the - tracing options if gated works OK for you. You - will need to change the xxx.xxx.yy's into - the network address of your own SLIP subnet (be sure to change the - net mask in the proto direct clause as - well). - - When you get gated built and installed and - create a configuration file for it, you will need to run - gated in place of routed on - your FreeBSD system; change the routed/gated - startup parameters in /etc/netstart as - appropriate for your system. Please see the manual page for - gated for information on - gated's command-line parameters. - - - - - Acknowledgments - - Thanks to these people for comments and advice regarding this - tutorial: - - - - &a.wilko; - - - - - - - Piero Serini - - - Piero@Strider.Inet.IT - - - + The above sample gated.conf file + broadcasts routing information regarding the SLIP subnet + xxx.xxx.yy via RIP onto the + Ethernet; if you are using a different Ethernet driver than + the ed driver, you will need to + change the references to the ed + interface appropriately. This sample file also sets up + tracing to /var/tmp/gated.output for + debugging gated's activity; you can + certainly turn off the tracing options if + gated works OK for you. You will need to + change the xxx.xxx.yy's into the + network address of your own SLIP subnet (be sure to change the + net mask in the proto direct clause as + well). + + When you get gated built and installed + and create a configuration file for it, you will need to run + gated in place of routed + on your FreeBSD system; change the + routed/gated startup parameters in + /etc/netstart as appropriate for your + system. Please see the manual page for + gated for information on + gated's command-line parameters. + + diff --git a/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml b/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml index 9a84ff1fe9..90da0350d6 100644 --- a/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2664 +1,2681 @@ PPP and SLIP - - If your connection to the Internet is through a modem, or you wish to - provide other people with dialup connections to the Internet using - FreeBSD, you have the option of using PPP or SLIP. Furthermore, two - varieties of PPP are provided: user (sometimes - referred to as iijppp) and - kernel. The procedures for configuring both types of - PPP, and for setting up SLIP are described in this chapter. - + + Restructured, reorganized, and updated by &a.jim;, + 1 March 2000. + + + Synopsis + + If you are connecting to the Internet via modem, or wish to + provide dialup connections to the Internet for others using FreeBSD, + you have the option of using PPP or SLIP. + + This chapter covers three varieties of PPP; + user, kernel, and + PPPoE (PPP over Ethernet). It also covers + setting up a SLIP client and server. + + The first variety of PPP that will be covered is User PPP. User + PPP was introduced into FreeBSD in 2.0.5-RELEASE as an addition to + the already existing kernel implementation of PPP. + + You may be wondering what the main difference is between User + PPP and kernel PPP. The answer is simple; user PPP does not run as + a daemon, and can run as and when desired. No PPP interface needs + to be compiled into ther kernel; it runs as a user process, and uses + the tunnel device driver (tun) to get data + into and out of the kernel. + + From here on out in this chapter, user ppp will simply be + referred to as ppp unless a distinction needs to be made between it + and and any other PPP software such as pppd. + Unless otherwise stated, all of the commands explained in this + section should be executed as root. + + - Setting up User PPP - - User PPP was introduced to FreeBSD in release 2.0.5 as an addition - to the existing kernel implementation of PPP. So, what is different - about this new PPP that warrants its addition? To quote from the manual - page: - -
- This is a user process PPP software package. Normally, PPP is - implemented as a part of the kernel (e.g. as managed by - pppd) and it is thus somewhat hard to debug and/or - modify its behavior. However, in this implementation PPP is done as a - user process with the help of the tunnel device driver - (tun). -
- - In essence, this means that rather than running a PPP daemon, the - ppp program can be run as and when desired. No PPP interface needs to - be compiled into the kernel, as the program can use the generic tunnel - device to get data into and out of the kernel. - - From here on out, user ppp will be referred to simply as ppp unless - a distinction needs to be made between it and any other PPP - client/server software such as pppd. Unless - otherwise stated, all commands in this section should be executed as - root. - - There are a large number of enhancements in version 2 of ppp. You - can discover what version you have by running ppp with no arguments and - typing show version at the prompt. It is a simple - matter to upgrade to the latest version of ppp (under any version of - FreeBSD) by downloading the latest archive via www.Awfulhak.org. - + Using User PPP + + Originally contributed by &a.brian;, with input + from &a.nik;, &a.dirkvangulik;, and &a.pjc;. + - Before you start - - This document assumes you are in roughly this position: - - You have an account with an Internet Service Provider (ISP) which - lets you use PPP. Further, you have a modem (or other device) - connected and configured correctly which allows you to connect to your - ISP. - - You are going to need the following information to hand: - - - - Your ISPs phone number(s). - + User PPP - - Your login name and password. This can be either a regular - unix style login/password pair, or a PPP PAP or CHAP - login/password pair. - + + Assumptions - - The IP addresses of one or more nameservers. Normally, you - will be given two IP numbers. You must have - this information for PPP version 1.x - unless you run your own nameserver. From version 2 onwards, - PPP supports nameserver address - negotiation. If your ISP supports this, then using the command - enable dns in your config file will tell - PPP to set the nameservers for - you. - - - - The following information may have been supplied by your ISP, but - is not strictly necessary: - - - - The IP address of your ISP's gateway. The gateway is the - machine to which you will connect and will be set up as your - default route. If your ISP hasn't given you - this number, we can make one up and your ISP's PPP server will - tell us the correct value when we connect. - - This IP number is referred to as HISADDR - by ppp. - + This document assumes you have the following: - - Your ISP's netmask. If your ISP hasn't given you this - information, you can safely use a netmask of + + An account with an Internet Service Provider (ISP) which + you connect to using PPP. Further, you have a modem or + other device connected to your system and configured + correctly, which allows you to connect to your ISP. + + + + The dialup number(s) of your ISP. + + + + Your login name and password. This can be either a + regular unix style login and password pair, or a PAP or CHAP + login and password pair. + + + + The IP address(es) of one or more name servers. + Normally, you will be given two IP addresses by your ISP to + use for this. If they have not given you at least one, then + you can use the enable dns command in + your ppp.conf file to tell + ppp to set the name servers for + you. + + + + The following information may be supplied by your ISP, but + is not completely necessary: + + + + The IP address of your ISP's gateway. The gateway is + the machine to which you will connect and will be set up as + your default route. If you do not have + this information, we can make one up and your ISP's PPP + server will tell us the correct value when we connect. + + This IP number is referred to as + HISADDR by + ppp. + + + + The netmask you should use. If your ISP has not + provided you with one, you can safely use 255.255.255.0. - - If your ISP allocates you a static IP address and hostname - then you can enter this information. Otherwise, we simply let the - peer assign whatever IP number it sees fit. - - - - If you do not have any of the required information, contact your - ISP and make sure they provide it to you. - + + + + If your ISP provides you with a static IP address and + hostname, you can enter it. Otherwise, we simply let the + peer assign whatever IP address it sees fit. + + + + If you do not have any of the required information, contact + your ISP and make sure they provide it to you. + - - Building a ppp ready kernel - - As the description states, ppp uses the kernel - tun device. It is necessary to make sure - that your kernel has support for this device compiled in. - - To check this, go to your kernel compile directory - (/sys/i386/conf or - /sys/pc98/conf) and examine your kernel - configuration file. It needs to have the line + + Preparing the Kernel + + As previously mentioned, ppp + users the tun device. It is necessary + to make sure that your kernel has support for this device + compiled into it. + + To check, go to your kernel compile directory + (/sys/i386/conf or + /sys/pc98/conf) and examine your + configuration file. It should have the following line somewhere + in it: -pseudo-device tun 1 - - in it somewhere. The stock GENERIC kernel has - this as standard, so if you have not installed a custom kernel or you - do not have a /sys directory, you do not have to - change anything. - - If your kernel configuration file does not have this line in it, - or you need to configure more than one tun device (for example, if you - are setting up a server and could have 16 dialup ppp connections at - any one time then you will need to use 16 instead - of 1), then you should add the line, re-compile, - re-install and boot the new kernel. Please refer to the Configuring the FreeBSD Kernel section - for more information on kernel configuration. - - You can check how many tunnel devices your current kernel has by - typing the following: +pseudo-device tun 1 + + If this line is not present, you will need to add it to the + configuration file and recompile your kernel. The stock + GENERIC kernel has this included, so if you + have not installed a custom kernel or do not have a + /sys directory, you do not have to change + anything. If you do need to recompile your kernel, please refer + to the kernel configuration + section for more information. + + You can check how many tunnel devices your current kernel + has by typing the following: - &prompt.root; ifconfig -a + &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - - - This case shows four tunnel devices, two of which are currently - configured and being used. It should be noted that the - RUNNING flag above indicates that the interface has - been used at some point—it is not an error if your interface - does not show up as RUNNING. - - If you have a kernel without the tun device, and you can not - rebuild it for some reason, all is not lost. You should be able to - dynamically load the code. Refer to the appropriate - &man.modload.8; and &man.lkm.4; pages for further details. - - You may also wish to take this opportunity to configure a - firewall. Details can be found in the Firewalls section. - - - - Check the tun device - - Most users will only require one tun - device (/dev/tun0). If you have used more (i.e., - a number other than 1 in the - pseudo-device line in the kernel configuration - file) then alter all references to tun0 below - to reflect whichever device number you are using. - - The easiest way to make sure that the - tun0 device is configured correctly is to - re-make it. To do this, execute the following commands: - - &prompt.root; cd /dev + + This case shows four tunnel devices, two of which are + currently configured and being used. It should be noted that + the RUNNING flag above indicates that the + interface has been used at some point—it is not an error + if your interface does not show up as + RUNNING. + + If for some reason you have a kernel that does not have the + tun device in it and cannot recompile + the kernel, all is not lost. You should be able to dynamically + load the code. Please refer to the appropriate + &man.modload.8; and &man.lkm.4; man pages for further + details. + + + + Check the <devicename>tun</devicename> device + + Under normal circumstances, most users will only require one + tun device + (/dev/tun0). If you have specified more + than one on the pseudo-device line for + tun in your kernel configuration file, + then alter all references to tun0 below + to reflect whichever device number you are using (e.g., + tun2). + + The easiest way to make sure that the + tun0 device is configured correctly, + is to remake the device. This process is quite easy. To remake + the device, do the following: + + &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 - - If you require 16 tunnel devices in your kernel, you will need to - create more than just tun0: - - &prompt.root; cd /dev + + If you need 16 tunnel devices in your kernel, you will need + to create them. This can be done by executing the following + commands: + + &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 - - Also, to confirm that the kernel is configured correctly, the - following command should give the indicated output: - - &prompt.root; ifconfig tun0 -tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 - - The RUNNING flag may not yet be set, in which - case you will see: - - &prompt.root; ifconfig tun0 -tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - - - - Name Resolution Configuration - - The resolver is the part of the system that turns IP addresses - into hostnames and vice versa. It can be configured to look for maps - that describe IP to hostname mappings in one of two places. The first - is a file called /etc/hosts (man 5 - hosts). The second is the Internet Domain Name Service - (DNS), a distributed data base, the discussion of which is beyond the - scope of this document. - - This section describes briefly how to configure your - resolver. - - The resolver is a set of system calls that do the name mappings, - but you have to tell them where to find their information. You do - this by first editing the file /etc/host.conf. - Do not call this file - /etc/hosts.conf (note the extra - s) as the results can be confusing. + + To confirm that the kernel is configured correctly, issue + the follow command and compare the results: + + &prompt.root; ifconfig tun0 +tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mut 1500 + + The RUNNING flag may not yet be set, in + which case you will see: + + &prompt.root; ifconfig tun0 +tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 + - Edit the <filename>/etc/host.conf</filename> file + Name Resolution Configuration + + The resolver is the part of the system that turns IP + addresses into hostnames and vice versa. It can be configured + to look for maps that describe IP to hostname mappings in one of + two places. The first is a file called + /etc/hosts. Read &man.hosts.5; for more + information. The second is the Internet Domain Name Service + (DNS), a distributed data base, the discussion of which is + beyond the scope of this document. + + The resolver is a set of system calls that do the name + mappings, but you have to tell them where to find their + information. You do this by first editing the file + /etc/host.conf. Do not + call this file /etc/hosts.conf (note the + extra s) as the results can be + confusing. - This file should contain the following two lines (in this - order): - - + + Edit <filename>/etc/host.conf</filename> + + This file should contain the following two lines (in this + order): + + hosts bind - - These instructs the resolver to first look in the file - /etc/hosts, and then to consult the DNS if the - name was not found. - + + These instruct the resolver to first look in the file + /etc/hosts, and then to consult the DNS + if the name was not found. + - - Edit the <filename>/etc/hosts</filename>(5) file - - This file should contain the IP addresses and names of machines - on your network. At a bare minimum it should contain entries for - the machine which will be running ppp. Assuming that your machine - is called foo.bar.com with the IP - address 10.0.0.1, - /etc/hosts should contain: - - -127.0.0.1 localhost -10.0.0.1 foo.bar.com foo - - The first line defines the alias localhost as a - synonym for the current machine. Regardless of your own IP address, - the IP address for this line should always be 127.0.0.1. The second line maps the name - foo.bar.com (and the shorthand - foo) to the IP address + Edit <filename>/etc/hosts</filename> + + This file should contain the IP addresses and names of + machines on your network. At a bare minimum it should contain + entries for the machine which will be running ppp. Assuming + that your machine is called foo.bar.com with the IP address 10.0.0.1, + /etc/hosts should contain: + + +127.0.0.1 localhost.bar.com localhost +127.0.0.1 localhost.bar.com. +10.0.0.1 foo.bar.com foo +10.0.0.1 foo.bar.com. + + The first two lines define the alias + localhost as a synonym for the current + machine. Regardless of your own IP address, the IP address + for this line should always be 127.0.0.1. The second two lines map + the name foo.bar.com (and the + shorthand foo) to the IP address 10.0.0.1. - - If your provider allocates you a static IP address and name, - then use these in place of the If your provider allocates you a static IP address and + name, use them in place of the 10.0.0.1 entry. - - - - Edit the <filename>/etc/resolv.conf</filename> file + - /etc/resolv.conf tells the resolver how to - behave. If you are running your own DNS, you may leave this file - empty. Normally, you will need to enter the following - line(s): - - + + Edit <filename>/etc/resolv.conf</filename> + + The /etc/resolv.conf file tells the + resolver how to behave. If you are running your own DNS, you + may leave this file empty. Normally, you will need to enter + the following line(s): + + +domain bar.com nameserver x.x.x.x -nameserver y.y.y.y -domain bar.com - - The x.x.x.x and - y.y.y.y - addresses are those given to you by your ISP. Add as many - nameserver lines as your ISP provides. The - domain line defaults to your hostname's domain, - and is probably unnecessary. Refer to the - resolv.conf manual page for details of other - possible entries in this file. - - If you are running PPP version 2 or greater, the enable - dns command will tell PPP to request that your ISP - confirms the nameserver values. If your ISP supplies different - addresses (or if there are no nameserver lines in - /etc/resolv.conf), PPP will rewrite the file - with the ISP-supplied values. +nameserver y.y.y.y + + The x.x.x.x and + y.y.y.y + addresses are those given to you by your ISP. Add as many + nameserver lines as your ISP provides. The + domain line defaults to your hostname's + domain, and is probably unnecessary. Refer to the + &man.resolv.conf.5; manual page for details of other possible + entries in this file. + + If you are running PPP version 2 or greater, the + enable dns command will tell PPP to request + that your ISP confirms the nameserver values. If your ISP + supplies different addresses (or if there are no nameserver + lines in /etc/resolv.conf), PPP will + rewrite the file with the ISP-supplied values. + - - - - <command>ppp</command> Configuration - - Both user ppp and pppd (the kernel level - implementation of PPP) use configuration files located in the - /etc/ppp directory. The sample configuration - files provided are a good reference for user ppp, so don't delete - them. - - Configuring ppp requires that you edit a number - of files, depending on your requirements. What you put in them - depends to some extent on whether your ISP allocates IP addresses - statically (i.e., you get given one IP address, and always use that - one) or dynamically (i.e., your IP address can be different for each - PPP session). - - - PPP and Static IP addresses - You will need to create a configuration file called - /etc/ppp/ppp.conf. It should look similar to - the example below. + + <application>PPP</application> Configuration + + Both ppp and pppd + (the kernel level implementation of PPP) use the configuration + files located in the /etc/ppp directory. + The sample configuration files provided are a good reference, + so do not delete them. - - Lines that end in a : start in the first - column, all other lines should be indented as shown using spaces - or tabs. - + Configuring ppp requires that you edit a + number of files, depending on your requirements. What you put + in them depends to some extent on whether your ISP allocates IP + addresses statically (i.e., you get given one IP address, and + always use that one) or dynamically (i.e., your IP address + changes each time you connect to your ISP). - + + PPP and Static IP Addresses + + You will need to create a configuration file called + /etc/ppp/ppp.conf. It should look + similar to the example below. + + + Lines that end in a : start in the + first column, all other lines should be indented as shown + using spaces or tabs. + + + 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: -6 set phone "(0123) 456 7890" +6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns - Do not include the line numbers, they are just for reference in - this discussion. - - - - Line 1: - - - Identifies the default entry. Commands in this entry are - executed automatically when ppp is run. - - - - - Line 2: - - - Identifies the device to which the modem is connected. - COM1: is - /dev/cuaa0 and - COM2: is - /dev/cuaa1. - - - - - Line 3: - - - Sets the speed you want to connect at. If 115200 doesn't - work (it should with any reasonably new modem), try 38400 - instead. - - - - - Line 4: - - - The dial string. User PPP uses an expect-send syntax - similar to the &man.chat.8; program. Refer to the - manual page for information on the features of this - language. - - - - - Line 5: - - - Identifies an entry for a provider called - “provider”. - - - - - Line 6: - - - Sets the phone number for this provider. Multiple phone - numbers may be specified using the : or - | character as a separator. The difference - between these separators is described in &man.ppp.8;. - To summarize, if you want to rotate through the numbers, use - the :. If you want to always attempt to - dial the first number first and only use the other numbers if - the first number fails, use the |. Always - quote the entire set of phone numbers as shown. - - - - - Line 7: - - - The login string is of the same chat-like syntax as the - dial string. In this example, the string works for a service - whose login session looks like this: - - J. Random Provider + Do not include the line numbers, they are just for + reference in this discussion. + + + + Line 1: + + + Identifies the default entry. Commands in this + entry are executed automatically when ppp is run. + + + + + Line 2: + + + Identifies the device to which the modem is + connected. COM1 is + /dev/cuaa0 and + COM2 is + /dev/cuaa1. + + + + + Line 3: + + + Sets the speed you want to connect at. If 115200 + does not work (it should with any reasonably new modem), + try 38400 instead. + + + + + Line 4: + + + The dial string. User PPP uses an expect-send + syntax similar to the &man.chat.8; program. Refer to + the manual page for information on the features of this + language. + + + + + Line 5: + + + Identifies an entry for a provider called + “provider”. + + + + + Line 6: + + + Sets the phone number for this provider. Multiple + phone numbers may be specified using the colon + (:) or pipe character + (|)as a separator. The difference + between the two separators is described in &man.ppp.8;. + To summarize, if you want to rotate through the numbers, + use a colon. If you want to always attempt to dial the + first number first and only use the other numbers if the + first number fails, use the pipe character. Always + quote the entire set of phone numbers as shown. + + + + + Line 7: + + + The login string is of the same chat-like syntax as + the dial string. In this example, the string works for + a service whose login session looks like this: + + J. Random Provider login: foo password: bar protocol: ppp - - You will need to alter this script to suit your own needs. - When you write this script for the first time, you should - enable “chat” logging to ensure that the - conversation is going as expected. - - If you're using PAP or CHAP, there will be no login at - this point, so your login string can be left blank. See PAP and CHAP + + You will need to alter this script to suit your own + needs. When you write this script for the first time, + you should enable “chat” logging to ensure + that the conversation is going as expected. + + If you are using PAP or CHAP, there will be no login + at this point, so your login string can be left blank. + See PAP and CHAP authentication for further details. - - - - - Line 8: - - - Sets the default timeout (in seconds) for the connection. - Here, the connection will be closed automatically after 300 - seconds of inactivity. If you never want to timeout, set this - value to zero. - - - - - Line 9: - - - Sets the interface addresses. The string - x.x.x.x should be replaced by the - IP address that your provider has allocated to you. The - string y.y.y.y should be replaced - by the IP address that your ISP indicated for their gateway - (the machine to which you connect). If your ISP hasn't given - you a gateway address, use 10.0.0.2/0. If you need to use a - “guessed” address, make sure that you create an - entry in /etc/ppp/ppp.linkup as per the - instructions for PPP and - Dynamic IP addresses. If this line is omitted, - ppp cannot run in or - mode. - - - - - Line 10: - - - Adds a default route to your ISPs gateway. The special - word HISADDR is replaced with the gateway - address specified on line 9. It is important that this line - appears after line 9, otherwise HISADDR - will not yet be initialized. - - - - - Line 11: - - - This line tells PPP to ask your ISP to confirm that your - nameserver addresses are correct. If your ISP supports this - facility, PPP can then update - /etc/resolv.conf with the correct - nameserver entries. - - - - - It is not necessary to add an entry to - ppp.linkup when you have a static IP address as - your routing table entries are already correct before you connect. - You may however wish to create an entry to invoke programs after - connection. This is explained later with the sendmail - example. - - Example configuration files can be found in the - /etc/ppp directory. - - - - PPP and Dynamic IP addresses - - If your service provider does not assign static IP numbers, - ppp can be configured to negotiate the local and - remote addresses. This is done by “guessing” an IP - number and allowing ppp to set it up correctly - using the IP Configuration Protocol (IPCP) after connecting. The - ppp.conf configuration is the same as PPP and Static IP addresses, - with the following change: - - + + + + + Line 8: + + + Sets the default timeout (in seconds) for the + connection. Here, the connection will be closed + automatically after 300 seconds of inactivity. If you + never want to timeout, set this value to zero. + + + + + Line 9: + + + Sets the interface addresses. The string + x.x.x.x should be replaced by + the IP address that your provider has allocated to you. + The string y.y.y.y should be + replaced by the IP address that your ISP indicated for + their gateway (the machine to which you connect). If + your ISP hasn't given you a gateway address, use 10.0.0.2/0. If you need to use + a “guessed” address, make sure that you + create an entry in + /etc/ppp/ppp.linkup as per the + instructions for PPP + and Dynamic IP addresses. If this line is + omitted, ppp cannot run in + or + mode. + + + + + Line 10: + + + Adds a default route to your ISPs gateway. The + special word HISADDR is replaced with + the gateway address specified on line 9. It is + important that this line appears after line 9, + otherwise HISADDR will not yet be + initialized. + + + + + Line 11: + + + This line tells PPP to ask your ISP to confirm that + your nameserver addresses are correct. If your ISP + supports this facility, PPP can then update + /etc/resolv.conf with the correct + nameserver entries. + + + + + It is not necessary to add an entry to + ppp.linkup when you have a static IP + address as your routing table entries are already correct + before you connect. You may however wish to create an entry + to invoke programs after connection. This is explained later + with the sendmail example. + + Example configuration files can be found in the + /etc/ppp directory. + + + + PPP and Dynamic IP Addresses + + If your service provider does not assign static IP + addresses, ppp can be configured to + negotiate the local and remote addresses. This is done by + “guessing” an IP address and allowing + ppp to set it up correctly using the IP + Configuration Protocol (IPCP) after connecting. The + ppp.conf configuration is the same as + PPP and Static IP + Addresses, with the following change: + + 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 - - Again, do not include the line numbers, they are just for - reference in this discussion. Indentation of at least one space is - required. - - - - Line 9: - - The number after the / character is the - number of bits of the address that ppp will insist on. You - may wish to use IP numbers more appropriate to your - circumstances, but the above example will always work. + Again, do not include the line numbers, they are just for + reference. Indentation of at least one space is + required. - The last argument (0.0.0.0) tells PPP - to negotiate using address + + Line 9: + + + The number after the / character + is the number of bits of the address that ppp will + insist on. You may wish to use IP numbers more + appropriate to your circumstances, but the above example + will always work. + + The last argument (0.0.0.0) tells + PPP to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use - 0.0.0.0 as the first argument to - set ifaddr as it prevents PPP from setting - up an initial route in mode. - - - - - If you are running version 1.x of PPP, you will also need to - create an entry in /etc/ppp/ppp.linkup. - ppp.linkup is used after a connection has been - established. At this point, ppp will know what - IP addresses should really be used. The - following entry will delete the existing bogus routes, and create - correct ones: - - -1 provider: -2 delete ALL -3 add 0 0 HISADDR - - - - Line 1: - - - On establishing a connection, ppp will - look for an entry in ppp.linkup according - to the following rules: First, try to match the same label as - we used in ppp.conf. If that fails, look - for an entry for the IP number of our gateway. This entry is - a four-octet IP style label. If we still haven't found an - entry, look for the MYADDR entry. - - - - - Line 2: - - - This line tells ppp to delete all - existing routes for the acquired tun interface (except the - direct route entry). - - - - - Line 3: - - - This line tells ppp to add a default - route that points to HISADDR. - HISADDR will be replaced with the IP number - of the gateway as negotiated in the IPCP. - - - - - See the pmdemand entry in the files - /etc/ppp/ppp.conf.sample and - /etc/ppp/ppp.linkup.sample for a detailed - example. - - Version 2 of PPP introduces “sticky routes”. Any - add or delete lines that - contain MYADDR or HISADDR will - be remembered, and any time the actual values of - MYADDR or HISADDR change, the - routes will be re-applied. This removes the necessity of repeating - these lines in ppp.linkup. - - - - Receiving incoming calls with <command>ppp</command> - - This section describes setting up ppp in a - server role. + 0.0.0.0 as the first argument to + set ifaddr as it prevents PPP from + setting up an initial route in + mode. + + + + + If you are running version 1.x of PPP, you will also need + to create an entry in /etc/ppp/ppp.linkup. + ppp.linkup is used after a connection has + been established. At this point, ppp will + know what IP addresses should really be + used. The following entry will delete the existing bogus + routes, and create correct ones: - When you configure ppp to receive incoming - calls on a machine connected to a LAN, you must decide if you wish - to forward packets to the LAN. If you do, you should allocate the - peer an IP number from your LAN's subnet, and use the command - -enable proxy - - in your ppp.conf file. You should also confirm - that the /etc/rc.conf file (this file used to - be called /etc/sysconfig) contains the - following: - - -gateway=YES - - - Which getty? - - Configuring FreeBSD for Dialup - Services provides a good description on enabling dialup - services using getty. - - An alternative to getty is mgetty, - a smarter version of getty designed with dialup - lines in mind. - - The advantages of using mgetty is that it - actively talks to modems, meaning if port is - turned off in /etc/ttys then your modem won't - answer the phone. - - Later versions of mgetty (from 0.99beta - onwards) also support the automatic detection of PPP streams, - allowing your clients script-less access to your server. - - Refer to Mgetty and - AutoPPP for more information on - mgetty. +1 provider: +2 delete ALL +3 add 0 0 HISADDR + + + + Line 1: + + + On establishing a connection, ppp + will look for an entry in ppp.linkup + according to the following rules: First, try to match + the same label as we used in + ppp.conf. If that fails, look for + an entry for the IP address of our gateway. This entry + is a four-octet IP style label. If we still have not + found an entry, look for the MYADDR + entry. + + + + + Line 2: + + + This line tells ppp to delete all + of the existing routes for the acquired + tun interface (except the + direct route entry). + + + + + Line 3: + + + This line tells ppp to add a + default route that points to HISADDR. + HISADDR will be replaced with the IP + number of the gateway as negotiated in the IPCP. + + + + + See the pmdemand entry in the files + /etc/ppp/ppp.conf.sample and + /etc/ppp/ppp.linkup.sample for a + detailed example. + + Version 2 of PPP introduces “sticky routes”. + Any add or delete lines + that contain MYADDR or + HISADDR will be remembered, and any time + the actual values of MYADDR or + HISADDR change, the routes will be + reapplied. This removes the necessity of repeating these + lines in ppp.linkup. - PPP permissions - - ppp must normally be run as user id 0. If - however you wish to allow ppp to run in server - mode as a normal user by executing ppp as - described below, that user must be given permission to run - ppp by adding them to the - network group in - /etc/group. - - You will also need to give them access to one or more sections - of the configuration file using the allow - command: + Receiving Incoming Calls + + When you configure ppp to + receive incoming calls on a machine connected to a LAN, you + must decide if you wish to forward packets to the LAN. If you + do, you should allocate the peer an IP number from your LAN's + subnet, and use the command enable proxy in + your /etc/ppp/ppp.conf file. You should + also confirm that the /etc/rc.conf file + contains the following: +gateway="YES" + + + Which getty? + + Configuring FreeBSD for Dialup + Services provides a good description on enabling + dialup services using getty. + + An alternative to getty is mgetty, + a smarter version of getty designed with + dialup lines in mind. + + The advantages of using mgetty is + that it actively talks to modems, + meaning if port is turned off in + /etc/ttys then your modem will not answer + the phone. + + Later versions of mgetty (from + 0.99beta onwards) also support the automatic detection of + PPP streams, allowing your clients script-less access to + your server. + + Refer to Mgetty and + AutoPPP for more information on + mgetty. + + + + <application>PPP</application> Permissions + + The ppp command must normally be run + as user id 0. If however, you wish to allow + ppp to run in server mode as a normal + user by executing ppp as described below, + that user must be given permission to run + ppp by adding them to the + network group in + /etc/group. + + You will also need to give them access to one or more + sections of the configuration file using the + allow command: + + allow users fred mary - If this command is used in the default - section, it gives the specified users access to everything. - + If this command is used in the default + section, it gives the specified users access to + everything. + - - Setting up a PPP shell for dynamic-IP users - - Create a file called /etc/ppp/ppp-shell - containing the following: - - + + PPP Shells for Dynamic-IP Users + + Create a file called + /etc/ppp/ppp-shell containing the + following: + + #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT - - This script should be executable. Now make a symbolic link - called ppp-dialup to this script using the - following commands: - - &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup - - You should use this script as the shell - for all your dialup ppp users. This is an example from - /etc/password for a dialup PPP user with - username pchilds. (remember don't directly - edit the password file, use vipw) - - + + This script should be executable. Now make a symbolic + link called ppp-dialup to this script + using the following commands: + + &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup + + You should use this script as the + shell for all of your dialup users. + This is an example from /etc/password + for a dialup PPP user with username + pchilds (remember don't directly edit + the password file, use vipw). + + pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup - - Create a /home/ppp directory that is - world readable containing the following 0 byte files - + + Create a /home/ppp directory that + is world readable containing the following 0 byte + files: + -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts - - which prevents /etc/motd from being - displayed. - - - Setting up a PPP shell for static-IP users - - Create the ppp-shell file as above and - for each account with statically assigned IPs create a symbolic - link to ppp-shell. - - For example, if you have three dialup customers - fred, sam, and - mary, that you route class C networks for, - you would type the following: - - &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred + which prevents /etc/motd from being + displayed. + + + + PPP shells for Static-IP Users + + Create the ppp-shell file as above + and for each account with statically assigned IPs create a + symbolic link to ppp-shell. + + For example, if you have three dialup customers + fred, sam, and + mary, that you route class C networks + for, you would type the following: + + &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary - - Each of these users dialup accounts should have their shell - set to the symbolic link created above. (ie. - mary's shell should be - /etc/ppp/ppp-mary). - - - Setting up ppp.conf for dynamic-IP users + Each of these users dialup accounts should have their + shell set to the symbolic link created above (i.e., + mary's shell should be + /etc/ppp/ppp-mary). + + + + Setting up ppp.conf for dynamic-IP users - The /etc/ppp/ppp.conf file should contain - something along the lines of + The /etc/ppp/ppp.conf file should + contain something along the lines of: - + default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy - - The indenting is important. - - - The default: section is loaded for each - session. For each dialup line enabled in - /etc/ttys create an entry similar to the one - for ttyd0: above. Each line should get a - unique IP address from your pool of IP addresses for dynamic - users. - + + The indenting is important. + - - Setting up <filename>ppp.conf</filename> for static-IP - users - - Along with the contents of the sample - /etc/ppp/ppp.conf above you should add a - section for each of the statically assigned dialup users. We will - continue with our fred, - sam, and mary - example. - - + The default: section is loaded for + each session. For each dialup line enabled in + /etc/ttys create an entry similar to + the one for ttyd0: above. Each line + should get a unique IP address from your pool of IP + addresses for dynamic users. + + + + Setting up <filename>ppp.conf</filename> for static-IP + users + + Along with the contents of the sample + /etc/ppp/ppp.conf above you should add + a section for each of the statically assigned dialup users. + We will continue with our fred, + sam, and mary + example. + + fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 - - The file /etc/ppp/ppp.linkup should also - contain routing information for each static IP user if required. - The line below would add a route for the 203.14.101.0 class C via the client's - ppp link. - - + + The file /etc/ppp/ppp.linkup should + also contain routing information for each static IP user if + required. The line below would add a route for the 203.14.101.0 class C via the + client's ppp link. + + fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR + More on <command>mgetty</command>, AutoPPP, and MS extensions - + <command>mgetty</command> and AutoPPP - Configuring and compiling mgetty with the - AUTO_PPP option enabled allows + Configuring and compiling mgetty with + the AUTO_PPP option enabled allows mgetty to detect the LCP phase of PPP - connections and automatically spawn off a ppp shell. However, - since the default login/password sequence does not occur it is - necessary to authenticate users using either PAP or CHAP. - - This section assumes the user has successfully configured, - compiled, and installed a version of mgetty - with the AUTO_PPP option (v0.99beta or - later) - + connections and automatically spawn off a ppp shell. + However, since the default login/password sequence does not + occur it is necessary to authenticate users using either PAP + or CHAP. + + This section assumes the user has successfully + configured, compiled, and installed a version of + mgetty with the + AUTO_PPP option (v0.99beta or + later). + Make sure your /usr/local/etc/mgetty+sendfax/login.config file has the following in it: - + /AutoPPP/ - - /etc/ppp/ppp-pap-dialup - + This will tell mgetty to run the ppp-pap-dialup script for detected PPP connections. - + Create a file called /etc/ppp/ppp-pap-dialup containing the following (the file should be executable): - + #!/bin/sh exec /usr/sbin/ppp -direct pap$IDENT - + For each dialup line enabled in - /etc/ttys create a corresponding entry in - /etc/ppp/ppp.conf. This will happily - co-exist with the definitions we created above. - + /etc/ttys, create a corresponding entry + in /etc/ppp/ppp.conf. This will + happily co-exist with the definitions we created + above. + pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy - - Each user logging in with this method will need to have a - username/password in /etc/ppp/ppp.secret - file, or alternatively add the - + + Each user logging in with this method will need to have + a username/password in + /etc/ppp/ppp.secret file, or + alternatively add the following option to authenticate users + via PAP from /etc/password file. + enable passwdauth - - option to authenticate users via pap from the - /etc/password file. - If you wish to assign some users a static IP number, you can - specify the number as the third argument in + If you wish to assign some users a static IP number, you + can specify the number as the third argument in /etc/ppp/ppp.secret. See /etc/ppp/ppp.secret.sample for examples. - + MS extensions - It is possible to configure PPP to supply DNS and NetBIOS - nameserver addresses on demand. + It is possible to configure PPP to supply DNS and + NetBIOS nameserver addresses on demand. To enable these extensions with PPP version 1.x, the following lines might be added to the relevant section of /etc/ppp/ppp.conf. - + enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 And for PPP version 2 and above: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 - - This will tell the clients the primary and secondary name - server addresses, and a netbios nameserver host. - In version 2 and above, if the set dns - line is omitted, PPP will use the values found in - /etc/resolv.conf. + This will tell the clients the primary and secondary + name server addresses, and a netbios nameserver host. + + In version 2 and above, if the + set dns line is omitted, PPP will use the + values found in /etc/resolv.conf. - - - - PAP and CHAP authentication - - Some ISPs set their system up so that the authentication part of - your connection is done using either of the PAP or CHAP - authentication mechanisms. If this is the case, your ISP will not - give a login: prompt when you connect, but will - start talking PPP immediately. - - PAP is less secure than CHAP, but security is not normally an - issue here as passwords, although being sent as plain text with PAP, - are being transmitted down a serial line only. There's not much room - for crackers to “eavesdrop”. - - Referring back to the PPP and - Static IP addresses or + PAP and CHAP authentication + + Some ISPs set their system up so that the authentication + part of your connection is done using either of the PAP or + CHAP authentication mechanisms. If this is the case, your ISP + will not give a login: prompt when you + connect, but will start talking PPP immediately. + + PAP is less secure than CHAP, but security is not normally + an issue here as passwords, although being sent as plain text + with PAP, are being transmitted down a serial line only. + There's not much room for crackers to + “eavesdrop”. + + Referring back to the PPP + and Static IP addresses or PPP and Dynamic IP addresses - sections, the following alterations must be made: - - + sections, the following alterations must be made: + + 7 set login … 12 set authname MyUserName 13 set authkey MyPassword - - As always, do not include the line numbers, they are just for - reference in this discussion. Indentation of at least one space is - required. - - - - Line 7: - - Your ISP will not normally require that you log into the - server if you're using PAP or CHAP. You must therefore - disable your "set login" string. - - - - - Line 12: - - - This line specifies your PAP/CHAP user name. You will - need to insert the correct value for - MyUserName. - - - - - Line 13: - - - This line specifies your PAP/CHAP password. You will need - to insert the correct value for - MyPassword. You may want to add an - additional line + As always, do not include the line numbers, they are just + for reference in this discussion. Indentation of at least one + space is required. + + + + Line 7: + + + Your ISP will not normally require that you log into + the server if you're using PAP or CHAP. You must + therefore disable your “set login” + string. + + + + + Line 12: + + + This line specifies your PAP/CHAP user name. You + will need to insert the correct value for + MyUserName. + + + + + Line 13: + + + This line specifies your PAP/CHAP password. You + will need to insert the correct value for + MyPassword. You may want to + add an additional line, such as: - + 15 accept PAP - or - - + or + + 15 accept CHAP - to make it obvious that this is the intention, but PAP and - CHAP are both accepted by default. - - - - - - - Changing your <command>ppp</command> configuration on the - fly + to make it obvious that this is the intention, but + PAP and CHAP are both accepted by default. + + + + - It is possible to talk to the ppp program - while it is running in the background, but only if a suitable - diagnostic port has been set up. To do this, add the following line - to your configuration: + + Changing your <command>ppp</command> configuration on the + fly - + It is possible to talk to the ppp + program while it is running in the background, but only if a + suitable diagnostic port has been set up. To do this, add the + following line to your configuration: + + set server /var/run/ppp-tun%d DiagnosticPassword 0177 - This will tell PPP to listen to the specified unix-domain - socket, asking clients for the specified password before allowing - access. The %d in the name is replaced with the - tun device number that is in use. - - Once a socket has been set up, the - &man.pppctl.8; program may be used in scripts that wish to - manipulate the running program. + This will tell PPP to listen to the specified unix-domain + socket, asking clients for the specified password before + allowing access. The %d in the name is + replaced with the tun device number + that is in use. + + Once a socket has been set up, the &man.pppctl.8; program + may be used in scripts that wish to manipulate the running + program. + - - - - Final system configuration - - You now have ppp configured, but there are a - few more things to do before it is ready to work. They all involve - editing the /etc/rc.conf file (was - /etc/sysconfig). - - Working from the top down in this file, make sure the - hostname= line is set, e.g.: - - -hostname=foo.bar.com - - If your ISP has supplied you with a static IP address and name, - it's probably best that you use this name as your host name. - - Look for the network_interfaces variable. If - you want to configure your system to dial your ISP on demand, make - sure the tun0 device is added to the list, - otherwise remove it. - - -network_interfaces="lo0 tun0" ifconfig_tun0= - - The ifconfig_tun0 variable should be empty, - and a file called /etc/start_if.tun0 should be - created. This file should contain the line + + Final system configuration + + You now have ppp configured, but there + are a few more things to do before it is ready to work. They + all involve editing the /etc/rc.conf + file. + + Working from the top down in this file, make sure the + hostname= line is set, e.g.: + + +hostname="foo.bar.com" + + If your ISP has supplied you with a static IP address and + name, it's probably best that you use this name as your host + name. + + Look for the network_interfaces variable. + If you want to configure your system to dial your ISP on demand, + make sure the tun0 device is added to + the list, otherwise remove it. +network_interfaces="lo0 tun0" ifconfig_tun0= + + + The ifconfig_tun0 variable should be + empty, and a file called + /etc/start_if.tun0 should be created. + This file should contain the line: + + ppp -auto mysystem - - This script is executed at network configuration time, starting - your ppp daemon in automatic mode. If you have a LAN for which this - machine is a gateway, you may also wish to use the - switch. Refer to the manual page for - further details. - - - Set the router program to NO with the - line - - -router_enable=NO (/etc/rc.conf) -router=NO (/etc/sysconfig) - - It is important that the routed daemon is not - started (it's started by default) as routed tends - to delete the default routing table entries created by - ppp. - - It is probably worth your while ensuring that the - sendmail_flags line does not include the - option, otherwise sendmail will - attempt to do a network lookup every now and then, possibly causing - your machine to dial out. You may try: - - + + This script is executed at network configuration time, + starting your ppp daemon in automatic mode. If you have a LAN + for which this machine is a gateway, you may also wish to use + the switch. Refer to the manual page + for further details. + + + Set the router program to NO with + following line in your /etc/rc.conf: + + +router_enable="NO" + + It is important that the routed daemon is + not started (it is started by default), as it + routed tends to delete the default routing + table entries created by ppp. + + It is probably worth your while ensuring that the + sendmail_flags line does not include the + option, otherwise + sendmail will attempt to do a network lookup + every now and then, possibly causing your machine to dial out. + You may try: + + sendmail_flags="-bd" - - The upshot of this is that you must force - sendmail to re-examine the mail queue whenever the - ppp link is up by typing: - - &prompt.root; /usr/sbin/sendmail -q - - You may wish to use the !bg command in - ppp.linkup to do this automatically: - - + + The downside of this is that you must force + sendmail to re-examine the mail queue + whenever the ppp link is up by typing: + + &prompt.root; /usr/sbin/sendmail -q + + You may wish to use the !bg command in + ppp.linkup to do this automatically: + + 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m - - If you don't like this, it is possible to set up a - “dfilter” to block SMTP traffic. Refer to the sample - files for further details. - - All that is left is to reboot the machine. - - After rebooting, you can now either type - - &prompt.root; ppp - - and then dial provider to start the PPP - session, or, if you want ppp to establish sessions - automatically when there is outbound traffic (and you haven't created - the start_if.tun0 script), type - - &prompt.root; ppp -auto provider - - - - Summary - - To recap, the following steps are necessary when setting up ppp - for the first time: - - Client side: - - - - Ensure that the tun device is built - into your kernel. - - - - Ensure that the - tunX device file - is available in the /dev directory. - - - Create an entry in /etc/ppp/ppp.conf. - The pmdemand example should suffice for most - ISPs. - + If you don't like this, it is possible to set up a + “dfilter” to block SMTP traffic. Refer to the + sample files for further details. - - If you have a dynamic IP address, create an entry in - /etc/ppp/ppp.linkup. - + Now the only thing left to do is reboot the machine. - - Update your /etc/rc.conf (or - sysconfig) file. - + All that is left is to reboot the machine. After rebooting, + you can now either type: - - Create a start_if.tun0 script if you - require demand dialing. - - - - Server side: - - - - Ensure that the tun device is built - into your kernel. - + &prompt.root; ppp - - Ensure that the - tunX device file - is available in the /dev directory. - + and then dial provider to start the PPP + session, or, if you want ppp to establish + sessions automatically when there is outbound traffic (and + you have not created the start_if.tun0 + script), type: - - Create an entry in /etc/passwd (using the - &man.vipw.8; program). - + &prompt.root; ppp -auto provider + - - Create a profile in this users home directory that runs - ppp -direct direct-server or similar. - + + Summary + + To recap, the following steps are necessary when setting up + ppp for the first time: + + Client side: + + + + Ensure that the tun device is + built into your kernel. + + + + Ensure that the + tunX device + file is available in the /dev + directory. + + + + Create an entry in + /etc/ppp/ppp.conf. The + pmdemand example should suffice for + most ISPs. + + + + If you have a dynamic IP address, create an entry in + /etc/ppp/ppp.linkup. + + + + Update your /etc/rc.conf + file. + + + + Create a start_if.tun0 script if + you require demand dialing. + + + + Server side: + + + + Ensure that the tun device is + built into your kernel. + + + + Ensure that the + tunX device + file is available in the /dev + directory. + + + + Create an entry in /etc/passwd + (using the &man.vipw.8; program). + + + + Create a profile in this users home directory that runs + ppp -direct direct-server or + similar. + + + + Create an entry in + /etc/ppp/ppp.conf. The + direct-server example should + suffice. + + + + Create an entry in + /etc/ppp/ppp.linkup. + + + + Update your /etc/rc.conf + file. + + + + + - - Create an entry in /etc/ppp/ppp.conf. - The direct-server example should - suffice. - + + Using Kernel PPP - - Create an entry in - /etc/ppp/ppp.linkup. - + Parts originally contributed by &a.gena; and + &a.rhuff;. - - Update your /etc/rc.conf (or - sysconfig) file. - - - - - Acknowledgments - - This section of the handbook was last updated on Monday Aug 10, - 1998 by &a.brian; - - Thanks to the following for their input, comments & - suggestions: - - &a.nik; - - &a.dirkvangulik; - - &a.pjc; - - - - - Setting up Kernel PPP - - Contributed by &a.gena;. - - Before you start setting up PPP on your machine make sure that - pppd is located in /usr/sbin and - directory /etc/ppp exists. + Setting up Kernel PPP - pppd can work in two modes: + Before you start setting up PPP on your machine make sure + that pppd is located in + /usr/sbin and the directory + /etc/ppp exists. - - - as a “client”, i.e. you want to connect your machine - to outside world via PPP serial connection or modem line. - - - - as a “server”, i.e. your machine is located on the - network and used to connect other computers using PPP. - - - - In both cases you will need to set up an options file - (/etc/ppp/options or ~/.ppprc - if you have more then one user on your machine that uses PPP). + pppd can work in two modes: + + + + As a “client”, i.e., you want to connect your + machine to the outside world via a PPP serial connection or + modem line. + + + + as a “server”, i.e. your machine is located on + the network and used to connect other computers using + PPP. + + + + In both cases you will need to set up an options file + (/etc/ppp/options or + ~/.ppprc if you have more than one user on + your machine that uses PPP). - You also will need some modem/serial software (preferably kermit) so - you can dial and establish connection with remote host. + You also will need some modem/serial software (preferably + kermit) so you can dial and establish a connection with the + remote host. + - Working as a PPP client - + Using <command>pppd</command> as a client + I used the following /etc/ppp/options to connect to CISCO terminal server PPP line. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router - + To connect: - Dial to the remote host using kermit (or other modem program) - enter your user name and password (or whatever is needed to enable - PPP on the remote host) + Dial to the remote host using kermit (or some other modem + program), and enter your user name and password (or whatever + is needed to enable PPP on the remote host). Exit kermit (without hanging up the line). - enter: - + Enter the following: + &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 - Use the appropriate speed and device name. + Be sure to use the appropriate speed and device name. - - Now your computer is connected with PPP. If the connection fails - for some reasons you can add the option to the - /etc/ppp/options file and check messages on the - console to track the problem + + Now your computer is connected with PPP. If the connection + fails, you can add the option to the + /etc/ppp/options file and check messages on + the console to track the problem. - Following /etc/ppp/pppup script will make all - 3 stages automatically: + Following /etc/ppp/pppup script will make + all 3 stages automatically: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 - - /etc/ppp/kermit.dial is kermit script that - dials and makes all necessary authorization on the remote host. - (Example of such script is attached to the end of this - document) - - Use the following /etc/ppp/pppdown script to - disconnect the PPP line: + + /etc/ppp/kermit.dial is a kermit script + that dials and makes all necessary authorization on the remote + host (an example of such a script is attached to the end of this + document). + + Use the following /etc/ppp/pppdown script + to disconnect the PPP line: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest - - Check if PPP is still running - (/usr/etc/ppp/ppptest): + + Check to see if PPP is still running by executing + /usr/etc/ppp/ppptest, which should look like + this: #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 - - Hangs up modem line - (/etc/ppp/kermit.hup): + + To hang up the modem, execute + /etc/ppp/kermit.hup, which should + contain: set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit - - Here is an alternate method using chat instead - of kermit. - - Contributed by &a.rhuff;. - + + Here is an alternate method using chat + instead of kermit. + The following two files are sufficient to accomplish a pppd connection. - + /etc/ppp/options: - + /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router - + /etc/ppp/login.chat.script: - - (This should actually go into a single line.) - + + + The following should go on a single line. + + ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> - - Once these are installed and modified correctly, all you need to - do is - + + Once these are installed and modified correctly, all you need + to do is run pppd, like so: + &prompt.root; pppd - - This sample based primarily on information provided by: Trev - Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> and used by - permission. + + This sample is based primarily on information provided by: + Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> + and used with permission. - + - Working as a PPP server - - /etc/ppp/options: + Using <command>pppd</command> as a server + + /etc/ppp/options should contain something + similar to the following: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line - - Following /etc/ppp/pppserv script will enable - ppp server on your machine: + + The following /etc/ppp/pppserv script + will enable tell pppd to behave as a + server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 - - Use this /etc/ppp/pppservdown script to stop - ppp server: + + Use this /etc/ppp/pppservdown script to + stop the server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans - - Following kermit script will enable/disable autoanswer mode on - your modem (/etc/ppp/kermit.ans): + + The following kermit script + (/etc/ppp/kermit.ans) will enable/disable + autoanswer mode on your modem. It should look like this: set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit - - This /etc/ppp/kermit.dial script is used for - dialing and authorizing on remote host. You will need to customize it - for your needs. Put your login and password in this script, also you - will need to change input statement depending on responses from your - modem and remote host. + + A script named /etc/ppp/kermit.dial is + used for dialing and authenticating on the remote host. You will + need to customize it for your needs. Put your login and password + in this script; you will also need to change the input statement + depending on responses from your modem and remote host. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: - + - Setting up PPP over Ethernet (PPPoE) + Using PPP over Ethernet (PPPoE) Contributed by &a.jim; (from node.to) 10 Jan 2000. The following describes how to set up PPP over Ethernet, a.k.a, PPPoE. Prerequisites There are a few requirements that your system will need to meet in order for PPPoE to function properly. They are: Kernel source for FreeBSD &rel.current;-STABLE ppp and pppd from FreeBSD &rel.current;-STABLE Any dependencies for the above Kernel Configuration You will need to set the following options in your kernel configuration and then compile a new kernel. options NETGRAPH options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_CISCO options NETGRAPH_ECHO options NETGRAPH_FRAME_RELAY options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_LMI options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options "NETGRAPH_RFC1490" options NETGRAPH_SOCKET options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC Add the above to your kernel configuration, recompile, install, and then reboot your system. Setting up <filename>ppp.conf</filename> Here is an example of a working ppp.conf: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set MRU 1490 set MTU 1490 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login "TIMEOUT 1.5 name:-\\r-login:\\U word:\\P ocol:PPP HELLO" # this isn't necessary set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net set cd off set crtscts off papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD Running <application>PPP</application> As root, you can run either: &prompt.root; ppp -dedicated or &prompt.root; ppp -dedicated name_of_service_provider depending on how you have set up ppp.conf. Starting <application>PPP</application> at Boot Add the following to your /etc/rc.conf file: ppp_enable="YES" ppp_mode="dedicated" ppp_nat="YES" ppp_profile="default" # or your provider - - Setting up a SLIP Client - - Contributed by &a.asami; 8 Aug 1995. - - The following is one way to set up a FreeBSD machine for SLIP on a - static host network. For dynamic hostname assignments (i.e., your - address changes each time you dial up), you probably need to do - something much fancier. - - First, determine which serial port your modem is connected to. I - have a symbolic link to /dev/modem from - /dev/cuaa1, and only use the modem name in my - configuration files. It can become quite cumbersome when you need to - fix a bunch of files in /etc and - .kermrc's all over the system! - - - /dev/cuaa0 is COM1, - cuaa1 is COM2, - etc. - - - Make sure you have + + Using SLIP + + Originally contributed by &a.asami; and + &a.ghelmer;, with input from &a.wilko; and + &a.piero;. + + + Setting up a SLIP Client + + The following is one way to set up a FreeBSD machine for SLIP + on a static host network. For dynamic hostname assignments (i.e., + your address changes each time you dial up), you probably need to + do something much fancier. + + First, determine which serial port your modem is connected to. + I have a symbolic link to /dev/modem from + /dev/cuaa1, and only use the modem name in + my configuration files. It can become quite cumbersome when you + need to fix a bunch of files in /etc and + .kermrc's all over the system! + + + /dev/cuaa0 is + COM1, cuaa1 is + COM2, etc. + + + Make sure you have the following in your kernel configuration + file: pseudo-device sl 1 - in your kernel's config file. It is included in the - GENERIC kernel, so this will not be a problem - unless you deleted it. + It is included in the GENERIC kernel, so + this should not be a problem unless you have deleted it. - - Things you have to do only once - - - - Add your home machine, the gateway and nameservers to your - /etc/hosts file. Mine looks like - this: + + Things you have to do only once - + + + Add your home machine, the gateway and nameservers to + your /etc/hosts file. Mine looks like + this: + + 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 - - By the way, silvia is the name of the car that I had when I - was back in Japan (it is called 2?0SX here in U.S.). - + + + + Make sure you have before + in your + /etc/host.conf. Otherwise, funny + things may happen. + + + + Edit the /etc/rc.conf file. + + + + Set your hostname by editing the line that + says: - - Make sure you have before - in your /etc/host.conf. - Otherwise, funny things may happen. - + +hostname=“myname.my.domain” - - Edit the file /etc/rc.conf. Note that - you should edit the file /etc/sysconfig - instead if you are running FreeBSD previous to version - 2.2.2. - - - - Set your hostname by editing the line that says: - - -hostname=myname.my.domain + You should give it your full Internet + hostname. + - You should give it your full Internet hostname. - - - - Add sl0 to the list of network interfaces by changing the - line that says: - - + + Add sl0 to the list of network interfaces by + changing the line that says: + + network_interfaces="lo0" - to: - - -network_interfaces="lo0 sl0" - - - - Set the startup flags of sl0 by adding a line: - - + to: + + +network_interfaces=“lo0 sl0” + + + + Set the startup flags of sl0 by adding a + line: + + ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" - - - - Designate the default router by changing the line: + - -defaultrouter=NO + + Designate the default router by changing the + line: - to: + +defaultrouter=“NO” - -defaultrouter=slip-gateway - - - + to: - - Make a file /etc/resolv.conf which - contains: + +defaultrouter=“slip-gateway” + + + - -domain HIP.Berkeley.EDU -nameserver 128.32.136.9 -nameserver 128.32.136.12 + + Make a file /etc/resolv.conf which + contains: - As you can see, these set up the nameserver hosts. Of course, - the actual domain names and addresses depend on your - environment. - - - - Set the password for root and toor (and any other accounts - that does not have a password). Use passwd, do not edit the - /etc/passwd or - /etc/master.passwd files! - - - - Reboot your machine and make sure it comes up with the correct - hostname. - - - - - - Making a SLIP connection - - - - Dial up, type slip at the prompt, enter - your machine name and password. The things you need to enter - depends on your environment. I use kermit, with a script like - this: + +domain HIP.Berkeley.EDU +nameserver 128.32.136.9 +nameserver 128.32.136.12 - + As you can see, these set up the nameserver hosts. Of + course, the actual domain names and addresses depend on your + environment. + + + + Set the password for root and toor (and any other + accounts that do not have a password). Use passwd or + &man.vipw.8;, do not edit the + /etc/passwd or + /etc/master.passwd files! + + + + Reboot your machine and make sure it comes up with the + correct hostname. + + + + + + Making a SLIP connection + + + + Dial up, type slip at the prompt, + enter your machine name and password. The things you need + to enter depends on your environment. I use kermit, with a + script like this: + + # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login -define slip dial 643-9600, input 10 =>, if failure stop, - +define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a - (of course, you have to change the hostname and password to - fit yours). Then you can just type slip from - the kermit prompt to get connected. + Of course, you have to change the hostname and password + to fit yours. After doing so, you can just type + slip from the kermit prompt to get + connected. + + + Leaving your password in plain text anywhere in the + filesystem is generally a BAD idea. Do it at your own + risk. + + + + + Leave the kermit there (you can suspend it by + z) and as root, type: + + &prompt.root; slattach -h -c -s 115200 /dev/modem + + If you are able to ping hosts on the + other side of the router, you are connected! If it does not + work, you might want to try instead of + as an argument to slattach. + + + - - Leaving your password in plain text anywhere in the - filesystem is generally a BAD idea. Do it at your own risk. I - am just too lazy. - - + + How to shutdown the connection - - Leave the kermit there (you can suspend it by - z) and as root, type: - - &prompt.root; slattach -h -c -s 115200 /dev/modem - - If you are able to ping hosts on the other - side of the router, you are connected! If it does not work, you - might want to try instead of - as an argument to slattach. - - - + Do the following: - - How to shutdown the connection - - Type - - &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` + &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` - (as root) to kill slattach. Then go back to kermit - (fg if you suspended it) and exit from it - (q). + to kill slattach. Keep in mind you must be + root to do the above. Then go back to + kermit (fg if you suspended it) and exit from + it (q). - The slattach man page says you have to use ifconfig sl0 - down to mark the interface down, but this does not seem to - make any difference for me. (ifconfig sl0 reports - the same thing.) - - Some times, your modem might refuse to drop the carrier (mine - often does). In that case, simply start kermit and quit it again. It - usually goes out on the second try. - - - - Troubleshooting - - If it does not work, feel free to ask me. The things that people - tripped over so far: - - - - Not using or in - slattach (I have no idea why this can be fatal, but adding this - flag solved the problem for at least one person) - + The slattach man page says you have to use ifconfig + sl0 down to mark the interface down, but this does not + seem to make any difference for me. + (ifconfig sl0 reports the same thing.) - - Using instead of - (might be hard to see the difference on some fonts). - + Some times, your modem might refuse to drop the carrier + (mine often does). In that case, simply start kermit and quit + it again. It usually goes out on the second try. + - - Try ifconfig sl0 to see your interface - status. I get: - - &prompt.root; ifconfig sl0 + + Troubleshooting + + If it does not work, feel free to ask me. The things that + people tripped over so far: + + + + Not using or in + slattach (I have no idea why this can be fatal, but adding + this flag solved the problem for at least one + person). + + + + Using instead of + (might be hard to see the difference on + some fonts). + + + + Try ifconfig sl0 to see your + interface status. I get: + + &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 - - - - Also, netstat -r will give the routing - table, in case you get the "no route to host" messages from ping. - Mine looks like: + + + + Also, netstat -r will give the + routing table, in case you get the “no route to + host” messages from ping. Mine looks like: - &prompt.root; netstat -r + &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) - - (this is after transferring a bunch of files, your numbers - should be smaller). - - - - - - - Setting up a SLIP Server - - Contributed by &a.ghelmer;. v1.0, 15 May - 1995. - - This document provides suggestions for setting up SLIP Server - services on a FreeBSD system, which typically means configuring your - system to automatically startup connections upon login for remote SLIP - clients. The author has written this document based on his experience; - however, as your system and needs may be different, this document may - not answer all of your questions, and the author cannot be responsible - if you damage your system or lose data due to attempting to follow the - suggestions here. - - This guide was originally written for SLIP Server services on a - FreeBSD 1.x system. It has been modified to reflect changes in the - pathnames and the removal of the SLIP interface compression flags in - early versions of FreeBSD 2.X, which appear to be the only major changes - between FreeBSD versions. If you do encounter mistakes in this - document, please email the author with enough information to help - correct the problem. - - - Prerequisites - - This document is very technical in nature, so background knowledge - is required. It is assumed that you are familiar with the TCP/IP - network protocol, and in particular, network and node addressing, - network address masks, subnetting, routing, and routing protocols, - such as RIP. Configuring SLIP services on a dial-up server requires a - knowledge of these concepts, and if you are not familiar with them, - please read a copy of either Craig Hunt's TCP/IP Network - Administration published by O'Reilly & Associates, - Inc. (ISBN Number 0-937175-82-X), or Douglas Comer's books on the - TCP/IP protocol. - - It is further assumed that you have already setup your modem(s) - and configured the appropriate system files to allow logins through - your modems. If you have not prepared your system for this yet, - please see the tutorial for configuring dialup services; if you have a - World-Wide Web browser available, browse the list of tutorials at - http://www.FreeBSD.org/; - otherwise, check the place where you found this document for a - document named dialup.txt or something similar. - You may also want to check the manual pages for - &man.sio.4; for information on the serial port device driver and - &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, & &man.init.8; - for information relevant to configuring the system to accept logins on - modems, and perhaps &man.stty.1; for information on setting serial - port parameters (such as clocal for - directly-connected serial interfaces). + + This is after transferring a bunch of files, your + numbers should be smaller). + + + - - - Quick Overview - - In its typical configuration, using FreeBSD as a SLIP server works - as follows: a SLIP user dials up your FreeBSD SLIP Server system and - logs in with a special SLIP login ID that uses - /usr/sbin/sliplogin as the special user's shell. - The sliplogin program browses the file - /etc/sliphome/slip.hosts to find a matching line - for the special user, and if it finds a match, connects the serial - line to an available SLIP interface and then runs the shell script - /etc/sliphome/slip.login to configure the SLIP - interface. - + + + Setting up a SLIP Server + + This document provides suggestions for setting up SLIP Server + services on a FreeBSD system, which typically means configuring + your system to automatically startup connections upon login for + remote SLIP clients. The author has written this document based + on his experience; however, as your system and needs may be + different, this document may not answer all of your questions, and + the author cannot be responsible if you damage your system or lose + data due to attempting to follow the suggestions here. + + + Prerequisites + + This document is very technical in nature, so background + knowledge is required. It is assumed that you are familiar with + the TCP/IP network protocol, and in particular, network and node + addressing, network address masks, subnetting, routing, and + routing protocols, such as RIP. Configuring SLIP services on a + dial-up server requires a knowledge of these concepts, and if + you are not familiar with them, please read a copy of either + Craig Hunt's TCP/IP Network Administration + published by O'Reilly & Associates, Inc. (ISBN Number + 0-937175-82-X), or Douglas Comer's books on the TCP/IP + protocol. + + It is further assumed that you have already setup your + modem(s) and configured the appropriate system files to allow + logins through your modems. If you have not prepared your + system for this yet, please see the tutorial for configuring + dialup services; if you have a World-Wide Web browser available, + browse the list of tutorials at http://www.FreeBSD.org/. + You may also want to check the manual pages for &man.sio.4; for + information on the serial port device driver and &man.ttys.5;, + &man.gettytab.5;, &man.getty.8;, & &man.init.8; for + information relevant to configuring the system to accept logins + on modems, and perhaps &man.stty.1; for information on setting + serial port parameters (such as clocal for + directly-connected serial interfaces). + + - An Example of a SLIP Server Login + Quick Overview + + In its typical configuration, using FreeBSD as a SLIP server + works as follows: a SLIP user dials up your FreeBSD SLIP Server + system and logs in with a special SLIP login ID that uses + /usr/sbin/sliplogin as the special user's + shell. The sliplogin program browses the + file /etc/sliphome/slip.hosts to find a + matching line for the special user, and if it finds a match, + connects the serial line to an available SLIP interface and then + runs the shell script + /etc/sliphome/slip.login to configure the + SLIP interface. + + + An Example of a SLIP Server Login + + For example, if a SLIP user ID were + Shelmerg, Shelmerg's + entry in /etc/master.passwd would look + something like this (except it would be all on one + line): - For example, if a SLIP user ID were - Shelmerg, Shelmerg's entry - in /etc/master.passwd would look something like - this (except it would be all on one line): - - + Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin - - When Shelmerg logs in, - sliplogin will search - /etc/sliphome/slip.hosts for a line that had a - matching user ID; for example, there may be a line in - /etc/sliphome/slip.hosts that reads: - - + + When Shelmerg logs in, + sliplogin will search + /etc/sliphome/slip.hosts for a line that + had a matching user ID; for example, there may be a line in + /etc/sliphome/slip.hosts that + reads: + + Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - - sliplogin will find that matching line, hook - the serial line into the next available SLIP interface, and then - execute /etc/sliphome/slip.login like - this: - - + + sliplogin will find that matching line, + hook the serial line into the next available SLIP interface, + and then execute /etc/sliphome/slip.login + like this: + + /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - - If all goes well, /etc/sliphome/slip.login - will issue an ifconfig for the SLIP interface to - which sliplogin attached itself (slip interface - 0, in the above example, which was the first parameter in the list - given to slip.login) to set the local IP - address (dc-slip), remote IP address - (sl-helmer), network mask for the SLIP interface - (0xfffffc00), and any additional - flags (autocomp). If something goes wrong, - sliplogin usually logs good informational - messages via the daemon syslog facility, which - usually goes into /var/log/messages (see the - manual pages for &man.syslogd.8; and - &man.syslog.conf.5, and perhaps check - /etc/syslog.conf to see to which files - syslogd is logging). - - OK, enough of the examples — let us dive into setting up - the system. + + If all goes well, + /etc/sliphome/slip.login will issue an + ifconfig for the SLIP interface to which + sliplogin attached itself (slip interface + 0,in the above example, which was the first parameter in the + list given to slip.login) to set the + local IP address (dc-slip), remote IP address + (sl-helmer), network mask for the SLIP + interface (0xfffffc00), and + any additional flags (autocomp). If + something goes wrong, sliplogin usually + logs good informational messages via the + daemon syslog facility, which usually goes + into /var/log/messages (see the manual + pages for &man.syslogd.8; and &man.syslog.conf.5; and perhaps + check /etc/syslog.conf to see to which + files syslogd is logging). + + OK, enough of the examples — let us dive into + setting up the system. + - - - - Kernel Configuration - - FreeBSD's default kernels usually come with two SLIP interfaces - defined (sl0 and - sl1); you can use netstat + + + Kernel Configuration + + FreeBSD's default kernels usually come with two SLIP + interfaces defined (sl0 and + sl1); you can use netstat -i to see whether these interfaces are defined in your - kernel. - - Sample output from netstat -i: - - Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll + kernel. + + Sample output from netstat -i: + + Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 - - The sl0 and sl1 - interfaces shown in netstat -i's output indicate - that there are two SLIP interfaces built into the kernel. (The - asterisks after the sl0 and sl1 - indicate that the interfaces are “down”.) - - However, FreeBSD's default kernels do not come configured to - forward packets (ie, your FreeBSD machine will not act as a router) - due to Internet RFC requirements for Internet hosts (see RFC's 1009 - [Requirements for Internet Gateways], 1122 [Requirements for Internet - Hosts — Communication Layers], and perhaps 1127 [A Perspective - on the Host Requirements RFCs]), so if you want your FreeBSD SLIP - Server to act as a router, you will have to edit the - /etc/rc.conf file (called - /etc/sysconfig in FreeBSD releases prior to - 2.2.2) and change the setting of the gateway - variable to . If you have an older system which - predates even the /etc/sysconfig file, then add - the following command: - -sysctl -w net.inet.ip.forwarding = 1 + The sl0 and + sl1 interfaces shown in + netstat -i's output indicate that there are + two SLIP interfaces built into the kernel. (The asterisks after + the sl0 and sl1 indicate + that the interfaces are “down”.) + + However, FreeBSD's default kernels do not come configured + to forward packets (ie, your FreeBSD machine will not act as a + router) due to Internet RFC requirements for Internet hosts (see + RFCs 1009 [Requirements for Internet Gateways], 1122 + [Requirements for Internet Hosts — Communication Layers], + and perhaps 1127 [A Perspective on the Host Requirements RFCs]), + so if you want your FreeBSD SLIP Server to act as a router, you + will have to edit the /etc/rc.conf file and + change the setting of the gateway variable to + . + + You will then need to reboot for the new settings to take + effect. + + You will notice that near the end of the default kernel + configuration file (/sys/i386/conf/GENERIC) + is a line that reads: - to your /etc/rc.local file. - - You will then need to reboot for the new settings to take - effect. - - You will notice that near the end of the default kernel - configuration file (/sys/i386/conf/GENERIC) is a - line that reads: - - + pseudo-device sl 2 - - This is the line that defines the number of SLIP devices available - in the kernel; the number at the end of the line is the maximum number - of SLIP connections that may be operating simultaneously. - - Please refer to Configuring the - FreeBSD Kernel for help in reconfiguring your kernel. - - - - Sliplogin Configuration - - As mentioned earlier, there are three files in the - /etc/sliphome directory that are part of the - configuration for /usr/sbin/sliplogin (see - &man.sliplogin.8; for the actual manual page for - sliplogin): slip.hosts, which - defines the SLIP users & their associated IP addresses; - slip.login, which usually just configures the - SLIP interface; and (optionally) slip.logout, - which undoes slip.login's effects when the serial - connection is terminated. - + + This is the line that defines the number of SLIP devices + available in the kernel; the number at the end of the line is + the maximum number of SLIP connections that may be operating + simultaneously. + + Please refer to Configuring the + FreeBSD Kernel for help in reconfiguring your + kernel. + + - <filename>slip.hosts</filename> Configuration + Sliplogin Configuration + + As mentioned earlier, there are three files in the + /etc/sliphome directory that are part of + the configuration for /usr/sbin/sliplogin + (see &man.sliplogin.8; for the actual manual page for + sliplogin): slip.hosts, + which defines the SLIP users & their associated IP + addresses; slip.login, which usually just + configures the SLIP interface; and (optionally) + slip.logout, which undoes + slip.login's effects when the serial + connection is terminated. + + + <filename>slip.hosts</filename> Configuration + + /etc/sliphome/slip.hosts contains + lines which have at least four items, separated by + whitespace: + + + + SLIP user's login ID + - /etc/sliphome/slip.hosts contains lines - which have at least four items, separated by whitespace: + + Local address (local to the SLIP server) of the SLIP + link + - - - SLIP user's login ID - - - - Local address (local to the SLIP server) of the SLIP - link - - - - Remote address of the SLIP link - - - - Network mask - - + + Remote address of the SLIP link + - The local and remote addresses may be host names (resolved to IP - addresses by /etc/hosts or by the domain name - service, depending on your specifications in - /etc/host.conf), and I believe the network mask - may be a name that can be resolved by a lookup into - /etc/networks. On a sample system, - /etc/sliphome/slip.hosts looks like - this: - - + + Network mask + + + + The local and remote addresses may be host names (resolved + to IP addresses by /etc/hosts or by the + domain name service, depending on your specifications in + /etc/host.conf), and I believe the + network mask may be a name that can be resolved by a lookup + into /etc/networks. On a sample system, + /etc/sliphome/slip.hosts looks like + this: + + # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp - - At the end of the line is one or more of the options. - - - — no header compression - - - - — compress headers - - - - — compress headers if the - remote end allows it - - - - — disable ICMP packets (so any - “ping” packets will be dropped instead of using up - your bandwidth) - - + At the end of the line is one or more of the + options. - Note that sliplogin under early releases of - FreeBSD 2 ignored the options that FreeBSD 1.x recognized, so the - options , , - , and had no effect - until support was added in FreeBSD 2.2 (unless your - slip.login script included code to make use of - the flags). - - Your choice of local and remote addresses for your SLIP links - depends on whether you are going to dedicate a TCP/IP subnet or if - you are going to use “proxy ARP” on your SLIP server (it - is not “true” proxy ARP, but that is the terminology - used in this document to describe it). If you are not sure which - method to select or how to assign IP addresses, please refer to the - TCP/IP books referenced in the slips-prereqs section and/or - consult your IP network manager. - - If you are going to use a separate subnet for your SLIP clients, - you will need to allocate the subnet number out of your assigned IP - network number and assign each of your SLIP client's IP numbers out - of that subnet. Then, you will probably either need to configure a - static route to the SLIP subnet via your SLIP server on your nearest - IP router, or install gated on your FreeBSD SLIP - server and configure it to talk the appropriate routing protocols to - your other routers to inform them about your SLIP server's route to - the SLIP subnet. - - Otherwise, if you will use the “proxy ARP” method, - you will need to assign your SLIP client's IP addresses out of your - SLIP server's Ethernet subnet, and you will also need to adjust your - /etc/sliphome/slip.login and - /etc/sliphome/slip.logout scripts to use - &man.arp.8; to manage the proxy-ARP entries in the SLIP server's - ARP table. - - - - <filename>slip.login</filename> Configuration + + + — no header + compression + - The typical /etc/sliphome/slip.login file - looks like this: - - + + — compress + headers + + + + — compress headers if + the remote end allows it + + + + — disable ICMP packets + (so any “ping” packets will be dropped instead + of using up your bandwidth) + + + + Note that sliplogin under early releases + of FreeBSD 2 ignored the options that FreeBSD 1.x recognized, + so the options , + , , and + had no effect until support was added + in FreeBSD 2.2 (unless your slip.login + script included code to make use of the flags). + + Your choice of local and remote addresses for your SLIP + links depends on whether you are going to dedicate a TCP/IP + subnet or if you are going to use “proxy ARP” on + your SLIP server (it is not “true” proxy ARP, but + that is the terminology used in this document to describe it). + If you are not sure which method to select or how to assign IP + addresses, please refer to the TCP/IP books referenced in the + slips-prereqs section + and/or consult your IP network manager. + + If you are going to use a separate subnet for your SLIP + clients, you will need to allocate the subnet number out of + your assigned IP network number and assign each of your SLIP + client's IP numbers out of that subnet. Then, you will + probably either need to configure a static route to the SLIP + subnet via your SLIP server on your nearest IP router, or + install gated on your FreeBSD SLIP server + and configure it to talk the appropriate routing protocols to + your other routers to inform them about your SLIP server's + route to the SLIP subnet. + + Otherwise, if you will use the “proxy ARP” + method, you will need to assign your SLIP client's IP + addresses out of your SLIP server's Ethernet subnet, and you + will also need to adjust your + /etc/sliphome/slip.login and + /etc/sliphome/slip.logout scripts to use + &man.arp.8; to manage the proxy-ARP entries in the SLIP + server's ARP table. + + + + <filename>slip.login</filename> Configuration + + The typical /etc/sliphome/slip.login + file looks like this: + + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 - - This slip.login file merely - ifconfig's the appropriate SLIP interface with - the local and remote addresses and network mask of the SLIP - interface. - - If you have decided to use the “proxy ARP” method - (instead of using a separate subnet for your SLIP clients), your - /etc/sliphome/slip.login file will need to look - something like this: - - + + This slip.login file merely + ifconfig's the appropriate SLIP interface + with the local and remote addresses and network mask of the + SLIP interface. + + If you have decided to use the “proxy ARP” + method (instead of using a separate subnet for your SLIP + clients), your /etc/sliphome/slip.login + file will need to look something like this: + + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub - - The additional line in this slip.login, - arp -s $5 00:11:22:33:44:55 pub, creates an - ARP entry in the SLIP server's ARP table. This ARP entry causes the - SLIP server to respond with the SLIP server's Ethernet MAC address - whenever a another IP node on the Ethernet asks to speak to the SLIP - client's IP address. - - When using the example above, be sure to replace the Ethernet - MAC address (00:11:22:33:44:55) with the - MAC address of your system's Ethernet card, or your “proxy - ARP” will definitely not work! You can discover your SLIP - server's Ethernet MAC address by looking at the results of running - netstat -i; the second line of the output should - look something like: - - ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 - - This indicates that this particular system's Ethernet MAC - address is 00:02:c1:28:5f:4a — the - periods in the Ethernet MAC address given by netstat - -i must be changed to colons and leading zeros should be - added to each single-digit hexadecimal number to convert the address - into the form that - &man.arp.8; desires; see the manual page on &man.arp.8; for - complete information on usage. - - When you create /etc/sliphome/slip.login - and /etc/sliphome/slip.logout, the - “execute” bit (ie, chmod 755 + The additional line in this + slip.login, arp -s + $5 00:11:22:33:44:55 pub, creates an ARP entry + in the SLIP server's ARP table. This ARP entry causes the + SLIP server to respond with the SLIP server's Ethernet MAC + address whenever a another IP node on the Ethernet asks to + speak to the SLIP client's IP address. + + When using the example above, be sure to replace the + Ethernet MAC address (00:11:22:33:44:55) with the MAC address of + your system's Ethernet card, or your “proxy ARP” + will definitely not work! You can discover your SLIP server's + Ethernet MAC address by looking at the results of running + netstat -i; the second line of the output + should look something like: + + ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 + + This indicates that this particular system's Ethernet MAC + address is 00:02:c1:28:5f:4a + — the periods in the Ethernet MAC address given by + netstat -i must be changed to colons and + leading zeros should be added to each single-digit hexadecimal + number to convert the address into the form that &man.arp.8; + desires; see the manual page on &man.arp.8; for complete + information on usage. + + + When you create + /etc/sliphome/slip.login and + /etc/sliphome/slip.logout, the + “execute” bit (ie, chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) - must be set, or sliplogin will be unable to - execute it. - - - - - <filename>slip.logout</filename> Configuration + must be set, or sliplogin will be unable + to execute it. + + - /etc/sliphome/slip.logout is not strictly - needed (unless you are implementing “proxy ARP”), but if - you decide to create it, this is an example of a basic - slip.logout script: - - + + <filename>slip.logout</filename> Configuration + + /etc/sliphome/slip.logout is not + strictly needed (unless you are implementing “proxy + ARP”), but if you decide to create it, this is an + example of a basic + slip.logout script: + + #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down - If you are using “proxy ARP”, you will want to have - /etc/sliphome/slip.logout remove the ARP entry - for the SLIP client: - - + If you are using “proxy ARP”, you will want to + have /etc/sliphome/slip.logout remove the + ARP entry for the SLIP client: + + #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 - - The arp -d $5 removes the ARP entry that - the “proxy ARP” slip.login added - when the SLIP client logged in. - - It bears repeating: make sure - /etc/sliphome/slip.logout has the execute - bit set for after you create it (ie, chmod - 755 /etc/sliphome/slip.logout). - - - - - Routing Considerations - - If you are not using the “proxy ARP” method for - routing packets between your SLIP clients and the rest of your network - (and perhaps the Internet), you will probably either have to add - static routes to your closest default router(s) to route your SLIP - client subnet via your SLIP server, or you will probably need to - install and configure gated on your FreeBSD SLIP - server so that it will tell your routers via appropriate routing - protocols about your SLIP subnet. - - - Static Routes - - Adding static routes to your nearest default routers can be - troublesome (or impossible, if you do not have authority to do - so...). If you have a multiple-router network in your organization, - some routers, such as Cisco and Proteon, may not only need to be - configured with the static route to the SLIP subnet, but also need - to be told which static routes to tell other routers about, so some - expertise and troubleshooting/tweaking may be necessary to get - static-route-based routing to work. + + The arp -d $5 removes the ARP entry + that the “proxy ARP” + slip.login added when the SLIP client + logged in. + + It bears repeating: make sure + /etc/sliphome/slip.logout has the execute + bit set for after you create it (ie, chmod 755 + /etc/sliphome/slip.logout). + - + - Running <command>gated</command> - - An alternative to the headaches of static routes is to install - gated on your FreeBSD SLIP server and configure - it to use the appropriate routing protocols (RIP/OSPF/BGP/EGP) to - tell other routers about your SLIP subnet. You can use - gated from the ports - collection or retrieve and build it yourself from Routing Considerations + + If you are not using the “proxy ARP” method for + routing packets between your SLIP clients and the rest of your + network (and perhaps the Internet), you will probably either + have to add static routes to your closest default router(s) to + route your SLIP client subnet via your SLIP server, or you will + probably need to install and configure gated + on your FreeBSD SLIP server so that it will tell your routers + via appropriate routing protocols about your SLIP subnet. + + + Static Routes + + Adding static routes to your nearest default routers can + be troublesome (or impossible, if you do not have authority to + do so...). If you have a multiple-router network in your + organization, some routers, such as Cisco and Proteon, may + not only need to be configured with the static route to the + SLIP subnet, but also need to be told which static routes to + tell other routers about, so some expertise and + troubleshooting/tweaking may be necessary to get + static-route-based routing to work. + + + + Running <command>gated</command> + + An alternative to the headaches of static routes is to + install gated on your FreeBSD SLIP server + and configure it to use the appropriate routing protocols + (RIP/OSPF/BGP/EGP) to tell other routers about your SLIP + subnet. You can use gated from the ports collection or retrieve and build + it yourself from the - GateD anonymous ftp site; I believe the current version as - of this writing is gated-R3_5Alpha_8.tar.Z, - which includes support for FreeBSD “out-of-the-box”. - Complete information and documentation on gated - is available on the Web starting at ; I believe the current version + as of this writing is + gated-R3_5Alpha_8.tar.Z, which includes + support for FreeBSD “out-of-the-box”. Complete + information and documentation on gated is + available on the Web starting at the Merit GateD Consortium. Compile and install it, and then write a - /etc/gated.conf file to configure your gated; - here is a sample, similar to what the author used on a FreeBSD SLIP - server: - - + /etc/gated.conf file to configure your + gated; here is a sample, similar to what the author used on a + FreeBSD SLIP server: + + # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; - - The above sample gated.conf file broadcasts - routing information regarding the SLIP subnet - xxx.xxx.yy via RIP onto the Ethernet; if - you are using a different Ethernet driver than the - ed driver, you will need to change the - references to the ed interface - appropriately. This sample file also sets up tracing to - /var/tmp/gated.output for debugging - gated's activity; you can certainly turn off the - tracing options if gated works OK for you. You - will need to change the xxx.xxx.yy's into - the network address of your own SLIP subnet (be sure to change the - net mask in the proto direct clause as - well). - - When you get gated built and installed and - create a configuration file for it, you will need to run - gated in place of routed on - your FreeBSD system; change the routed/gated - startup parameters in /etc/netstart as - appropriate for your system. Please see the manual page for - gated for information on - gated's command-line parameters. - - - - - Acknowledgments - - Thanks to these people for comments and advice regarding this - tutorial: - - - - &a.wilko; - - - - - - - Piero Serini - - - Piero@Strider.Inet.IT - - - + The above sample gated.conf file + broadcasts routing information regarding the SLIP subnet + xxx.xxx.yy via RIP onto the + Ethernet; if you are using a different Ethernet driver than + the ed driver, you will need to + change the references to the ed + interface appropriately. This sample file also sets up + tracing to /var/tmp/gated.output for + debugging gated's activity; you can + certainly turn off the tracing options if + gated works OK for you. You will need to + change the xxx.xxx.yy's into the + network address of your own SLIP subnet (be sure to change the + net mask in the proto direct clause as + well). + + When you get gated built and installed + and create a configuration file for it, you will need to run + gated in place of routed + on your FreeBSD system; change the + routed/gated startup parameters in + /etc/netstart as appropriate for your + system. Please see the manual page for + gated for information on + gated's command-line parameters. + +