Previous Next Contents

6. Network Technology Specific Information.

The following subsections are specific to particular network technologies. The information contained in these sections does not necessarily apply to any other type of network technology.

6.1 ARCNet

ARCNet device names are `arc0e', `arc1e', `arc2e' etc. or `arc0s', `arc1s', `arc2s' etc. The first card detected by the kernel is assigned `arc0e' or `arc0s' and the rest are assigned sequentially in the order they are detected. The letter at the end signifies whether you've selected ethernet encapsulation packet format or RFC1051 packet format.

Kernel Compile Options:

Network device support  --->
    [*] Network device support
    <*> ARCnet support
    [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
    [ ]   Enable arc0s (ARCnet RFC1051 packet format)

Once you have your kernel properly built to support your ethernet card then configuration of the card is easy.

Typically you would use something like:

# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
Please refer to the /usr/src/linux/Documentation/networking/arcnet.txt and /usr/src/linux/Documentation/networking/arcnet-hardware.txt files for further information.

ARCNet support was developed by Avery Pennarun, apenwarr@foxnet.net.

6.2 Appletalk (AF_APPLETALK)

The Appletalk support has no special device names as it uses existing network devices.

Kernel Compile Options:

Networking options  --->
    <*> Appletalk DDP
Appletalk support allows your Linux machine to interwork with Apple networks. An important use for this is to share resources such as printers and disks between both your Linux and Apple computers. Additional software is required, this is called netatalk. Wesley Craig netatalk@umich.edu represents a team called the `Research Systems Unix Group' at the University of Michigan and they have produced the netatalk package which provides software that implements the Appletalk protocol stack and some useful utilities. The netatalk package will either have been supplied with your Linux distribution, or you will have to ftp it from its home site at the University of Michigan

To build and install the package do something like:

# cd /usr/src
# tar xvfz .../netatalk-1.4b2.tar.Z
- You may want to edit the `Makefile' at this point, specifically to change
  the DESTDIR variable which defines where the files will be installed later.
  The default of /usr/local/atalk is fairly safe.
# make
- as root:
# make install

Configuring the Appletalk software.

The first thing you need to do to make it all work is to ensure that the appropriate entries in the /etc/services file are present. The entries you need are:

rtmp    1/ddp   # Routing Table Maintenance Protocol
nbp     2/ddp   # Name Binding Protocol
echo    4/ddp   # AppleTalk Echo Protocol
zip     6/ddp   # Zone Information Protocol

The next step is to create the Appletalk configuration files in the /usr/local/atalk/etc directory (or wherever you installed the package).

The first file to create is the /usr/local/atalk/etc/atalkd.conf file. Initially this file needs only one line that gives the name of the network device that supports the network that your Apple machines are on:

eth0

The Appletalk daemon program will add extra details after it is run.

Exporting a Linux filesystems via Appletalk.

You can export filesystems from your linux machine to the network so that Apple machine on the network can share them.

To do this you must configure the /usr/local/atalk/etc/AppleVolumes.system file. There is another configuration file called /usr/local/atalk/etc/AppleVolumes.default which has exactly the same format and describes which filesystems users connecting with guest priveledges will receive.

Full details on how to configure these files and what the various options are can be found in the afpd man page.

A simple example might look like:

/tmp Scratch
/home/ftp/pub "Public Area"

Which would export your /tmp filesystem as AppleShare Volume `Scratch' and your ftp public directory as AppleShare Volume `Public Area'. The volume names are not mandatory, the daemon will choose some for you, but it won't hurt to specify them anyway.

Sharing your Linux printer across Appletalk.

You can share your linux printer with your Apple machines quite simply. You need to run the papd program which is the Appletalk Printer Access Protocol Daemon. When you run this program it will accept requests from your Apple machines and spool the print job to your local line printer daemon for printing.

You need to edit the /usr/local/atalk/etc/papd.conf file to configure the daemon. The syntax of this file is the same as that of your usual /etc/printcap file. The name you give to the definition is registered with the Appletalk naming protocol, NBP.

A sample configuration might look like:

TricWriter:\
   :pr=lp:op=cg:

Which would make a printer named `TricWriter' available to your Appletalk network and all accepted jobs would be printed to the linux printer `lp' (as defined in the /etc/printcap file) using lpd. The entry `op=cg' says that the linux user `cg' is the operator of the printer.

Starting the appletalk software.

Ok, you should now be ready to test this basic configuration. There is an rc.atalk file supplied with the netatalk package that should work ok for you, so all you should have to do is:

# /usr/local/atalk/etc/rc.atalk

and all should startup and run ok. You should see no error messages and the software will send messages to the console indicating each stage as it starts.

Testing the appletalk software.

To test that the software is functioning properly, go to one of your Apple machines, pull down the Apple menu, select the Chooser, click on AppleShare, and your Linux box should appear.

Caveats of the appletalk software.

More information

For a much more detailed description of how to configure Appletalk for Linux refer to Anders Brownworth Linux Netatalk-HOWTO page at thehamptons.com.

6.3 ATM

Werner Almesberger <werner.almesberger@lrc.di.epfl.ch> is managing a project to provide Asynchronous Transfer Mode support for Linux. Current information on the status of the project may be obtained from: lrcwww.epfl.ch.

6.4 AX25 (AF_AX25)

AX.25 device names are `sl0', `sl1', etc. in 2.0.* kernels or `ax0', `ax1', etc. in 2.1.* kernels.

Kernel Compile Options:

Networking options  --->
    [*] Amateur Radio AX.25 Level 2
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO. These protocols are used by Amateur Radio Operators world wide in packet radio experimentation.

Most of the work for implementation of these protocols has been done by Jonathon Naylor, jsn@cs.nott.ac.uk.

6.5 DECNet

Support for DECNet is currently being worked on. You should expect it to appear in a late 2.1.* kernel.

6.6 EQL - multiple line traffic equaliser

The EQL device name is `eql'. With the standard kernel source you may have only one EQL device per machine. EQL provides a means of utilising multiple point to point lines such as PPP, slip or plip as a single logical link to carry tcp/ip. Often it is cheaper to use multiple lower speed lines than to have one high speed line installed.

Kernel Compile Options:

Network device support  --->
    [*] Network device support
    <*> EQL (serial line load balancing) support

To support this mechanism the machine at the other end of the lines must also support EQL. Linux, Livingstone Portmasters and newer dial-in servers support compatible facilities.

To configure EQL you will need the eql tools which are available from: sunsite.unc.edu.

Configuration is fairly straightforward. You start by configuring the eql interface. The eql interface is just like any other network device. You configure the IP address and mtu using the ifconfig utility, so something like:

ifconfig eql 192.168.10.1 mtu 1006

Next you need to manually initiate each of the lines you will use. These may be any combination of point to point network devices. How you initiate the connections will depend on what sort of link they are, refer to the appropriate sections for further information.

Lastly you need to associate the serial link with the EQL device, this is called `enslaving' and is done with the eql_enslave command as shown:

eql_enslave eql sl0 28800
eql_enslave eql ppp0 14400
The `estimated speed' parameter you supply eql_enslave doesn't do anything directly. It is used by the EQL driver to determine what share of the datagrams that device should receive, so you can fine tune the balancing of the lines by playing with this value.

To disassociate a line from an EQL device you use the eql_emancipate command as shown:

eql_emancipate eql sl0

You add routing as you would for any other point to point link, except your routes should refer to the eql device rather than the actual serial devices themselves, typically you would use:

route add default eql

The EQL driver was developed by Simon Janes, simon@ncm.com.

6.7 Ethernet

Ethernet device names are `eth0', `eth1', `eth2' etc. The first card detected by the kernel is assigned `eth0' and the rest are assigned sequentially in the order they are detected.

To learn how to make your ethernet card working under Linux you should refer to the Ethernet-HOWTO.

Once you have your kernel properly built to support your ethernet card then configuration of the card is easy.

Typically you would use something like:

# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0

Most of the ethernet drivers were developed by Donald Becker, becker@CESDIS.gsfc.nasa.gov.

6.8 FDDI

FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card detected by the kernel is assigned `fddi0' and the rest are assigned sequentially in the order they are detected.

Lawrence V. Stefani, larry_stefani@us.newbridge.com, has developed a driver for the Digital Equipment Corporation FDDI EISA and PCI cards.

Kernel Compile Options:

Network device support  --->
    [*] FDDI driver support
    [*] Digital DEFEA and DEFPA adapter support

When you have your kernel built to support the FDDI driver and installed, configuration of the FDDI interface is almost identical that for an ethernet interface. You just specify the appropraite FDDI interface name in the ifconfig and route comands.

6.9 Frame Relay

The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).

Frame Relay is a new networking technology that is designed to suit data communications traffic that is of a `bursty' or intermittent nature. You connect to a Frame Relay network using a Frame Relay Access Device (FRAD). The Linux Frame Relay supports IP over Frame Relay as described in RFC-1490.

Kernel Compile Options:

Network device support  --->
    <*> Frame relay DLCI support (EXPERIMENTAL)
    (24)   Max open DLCI
    (8)   Max DLCI per device
    <*>   SDLA (Sangoma S502/S508) support

Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay support and configuration tools.

Currently the only FRAD supported are the Sangoma Technologies S502A, S502E and S508.

To configure the FRAD and DLCI devices after you have rebuilt your kernel you will need the Frame Relay configuration tools. These are available from ftp.invlogic.com. Compiling and installing the tools is straightforward, but the lack of a top level Makefile makes it a fairly manual process:

# cd /usr/src
# tar xvfz .../frad-0.15.tgz
# cd frad-0.15
# for i in common dlci frad; make -C $i clean; make -C $i; done
# mkdir /etc/frad
# install -m 644 -o root -g root bin/*.sfm /etc/frad
# install -m 700 -o root -g root frad/fradcfg /sbin
# install -m 700 -o root -g root dlci/dlcicfg /sbin

After installing the tools you need to create an /etc/frad/router.conf file. You can use this template, which is a modified version of one of the example files:

# /etc/frad/router.conf
# This is a template configuration for frame relay.
# All tags are included. The default values are based on the code
# supplied with the DOS drivers for the Sangoma S502A card.
#
# A '#' anywhere in a line constitutes a comment
# Blanks are ignored (you can indent with tabs too)
# Unknown [] entries and unknown keys are ignored
#

[Devices]
Count=1                 # number of devices to configure
Dev_1=sdla0             # the name of a device
#Dev_2=sdla1            # the name of a device

# Specified here, these are applied to all devices and can be overriden for 
# each individual board.
#
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
#
# MTU=1500              # Maximum transmit IFrame length, default is 4096
# T391=10               # T391 value    5 - 30, default is 10
# T392=15               # T392 value    5 - 30, default is 15
# N391=6                # N391 value    1 - 255, default is 6
# N392=3                # N392 value    1 - 10, default is 3
# N393=4                # N393 value    1 - 10, default is 4

# Specified here, these set the defaults for all boards
# CIRfwd=16             # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512 
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511


#
#
# Device specific configuration
#
#

#
# The first device is a Sangoma S502E
#
[sdla0]
Type=Sangoma            # Type of the device to configure, currently only 
                        # SANGOMA is recognised
#
# These keys are specific to the 'Sangoma' type
#
# The type of Sangoma board - S502A, S502E, S508
Board=S502E
#
# The name of the test firmware for the Sangoma board
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
#
# The name of the FR firmware
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
#
Port=360                # Port for this particular card
Mem=C8                  # Address of memory window, A0-EE, depending on card
IRQ=5                   # IRQ number, do not supply for S502A
DLCIs=1                 # Number of DLCI's attached to this device
DLCI_1=16               # DLCI #1's number, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
#
# Specified here, these apply to this device only, 
# and override defaults from above
#
# Access=CPE            # CPE or NODE, default is CPE 
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal        # External or Internal, default is Internal
# Baud=128              # Specified baud rate of attached CSU/DSU
# MTU=2048              # Maximum transmit IFrame length, default is 4096
# T391=10               # T391 value    5 - 30, default is 10
# T392=15               # T392 value    5 - 30, default is 15
# N391=6                # N391 value    1 - 255, default is 6
# N392=3                # N392 value    1 - 10, default is 3
# N393=4                # N393 value    1 - 10, default is 4

#
# The second device is some other card
#
# [sdla1]
# Type=FancyCard        # Type of the device to configure.
# Board=                # Type of Sangoma board
# Key=Value             # values specific to this type of device


#
# DLCI Default configuration parameters
# These may be overridden in the DLCI specific configurations
#
CIRfwd=64               # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512 
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511

#
# DLCI Configuration
# These are all optional. The naming convention is
# [DLCI_D<devicenum>_<DLCI_Num>]
#

[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0

[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0

When you've built your /etc/frad/router.conf file the only step remaining is to configure the actual devices themselves. This is only a little trickier than a normal network device configuration, you need to remember to bring up the FRAD device before the DLCI encapsulation devices.

# Configure the frad hardware and the DLCI parameters
/sbin/fradcfg /etc/frad/router.conf || exit 1
/sbin/dlcicfg file /etc/frad/router.conf
#
# Bring up the FRAD device
ifconfig sdla0 up
#
# Configure the DLCI encapsulation interfaces and routing
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#

6.10 IP Accounting

The IP accounting features of the Linux kernel allow you to collect and analyse some network usage data. The data collected comprises the number of packets and the number of bytes accumulated since the figures were last reset. You may specify a variety of rules to categorise the figures to suit whatever purpose you may have.

Kernel Compile Options:

Networking options  --->
    [*] IP: accounting

After you have compiled and installed the kernel you need to use the ipfwadm command to configure IP accounting. There are many different ways of breaking down the accounting information that you might choose. I've picked a simple example of what might be useful to use, you should read the ipfwadm man page for more information.

Scenario: You have a ethernet network that is linked to the internet via a PPP link. On the ethernet you have a machine that offers a number of services and that you are interested in knowing how much traffic is generated by each of telnet, rlogin, ftp and world wide web traffic.

You might use a command set that looks like the following:

#
# Flush the accounting rules
ipfwadm -A -f
#
# Add rules for local ethernet segment
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 20
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 20
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 23
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 23
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 80
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 80
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 513
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 513
ipfwadm -A in -a -P tcp -D 44.136.8.96/29
ipfwadm -A out -a -P tcp -D 44.136.8.96/29
ipfwadm -A in -a -P udp -D 44.136.8.96/29
ipfwadm -A out -a -P udp  -D 44.136.8.96/29
ipfwadm -A in -a -P icmp -D 44.136.8.96/29
ipfwadm -A out -a -P icmp -D 44.136.8.96/29
#
# Rules for default
ipfwadm -A in -a -P tcp -D 0/0 20
ipfwadm -A out -a -P tcp -S 0/0 20
ipfwadm -A in -a -P tcp -D 0/0 23
ipfwadm -A out -a -P tcp -S 0/0 23
ipfwadm -A in -a -P tcp -D 0/0 80
ipfwadm -A out -a -P tcp -S 0/0 80
ipfwadm -A in -a -P tcp -D 0/0 513
ipfwadm -A out -a -P tcp -S 0/0 513
ipfwadm -A in -a -P tcp -D 0/0
ipfwadm -A out -a -P tcp -D 0/0
ipfwadm -A in -a -P udp -D 0/0
ipfwadm -A out -a -P udp  -D 0/0
ipfwadm -A in -a -P icmp -D 0/0
ipfwadm -A out -a -P icmp -D 0/0
#
# List the rules
ipfwadm -A -l -n
#
The last command lists each of the Accounting rules and displays the collected totals.

An important point to note when analysing IP accounting is that totals for all rules that match will be incremented so that to obtain differential figures you need to perform appropriate maths. For example if I wanted to know how much data was not ftp, telnet, rlogin or www I would substract the individual totals from the rule that matches all ports.

# ipfwadm -A -l -n
IP accounting rules
 pkts bytes dir prot source               destination          ports
    0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 20
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            20 -> *
    0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 23
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            23 -> *
   10  1166 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 80
   10   572 out tcp  44.136.8.96/29       0.0.0.0/0            80 -> *
  242  9777 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 513
  220 18198 out tcp  44.136.8.96/29       0.0.0.0/0            513 -> *
  252 10943 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  231 18831 out tcp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 in  udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 out udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 in  icmp 0.0.0.0/0            44.136.8.96/29       *
    0     0 out icmp 0.0.0.0/0            44.136.8.96/29       *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 20
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            20 -> *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 23
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            23 -> *
   10  1166 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 80
   10   572 out tcp  0.0.0.0/0            0.0.0.0/0            80 -> *
  243  9817 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 513
  221 18259 out tcp  0.0.0.0/0            0.0.0.0/0            513 -> *
  253 10983 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  231 18831 out tcp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 out udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  icmp 0.0.0.0/0            0.0.0.0/0            *
    0     0 out icmp 0.0.0.0/0            0.0.0.0/0            *
# 

6.11 IP Aliasing

There are some applications where being able to configure multiple IP addresses to a single network device is useful. Internet Service Providers often use this facility to provide a `customised' to their World Wide Web and ftp offerings for their customers.

Kernel Compile Options:

Networking options  --->
    ....
    [*] Network aliasing
    ....
    <*> IP: aliasing support

After compiling and installing your kernel with IP_Alias support configuration is very simple. The aliases are added to virtual network devices associated with the actual network device. A simple naming convention applies to these devices being <devname>:<virtual dev num>, e.g. eth0:0, ppp0:10 etc.

For example, assume you have an ethernet network that supports two different IP subnetworks simultaneously and you wish your machine to have direct access to both, you could use something like:

#
# ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0:0
#
# ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
#

To delete an alias you simply add a `-' to the end of its name and refer to it and is as simple as:

# ifconfig eth0:0- 0
All routes associated with that alias will also be deleted automatically.

6.12 IP Firewall

IP Firewall and Firewalling issues are covered in more depth in the Firewall-HOWTO. IP Firewalling allows you to secure your machine against unauthorised network access by filtering or allowing datagrams from or to IP addresses that you nominate. There are three different classes of rules, incoming filtering, outgoing filtering and forwarding filtering. Incoming rules are applied to datagrams that are received by a network device. Outgoing rules are applied to datagrams that are to be transmitted by a network device. Forwarding rules are applied to datagrams that are received and are not for this machine, ie datagrams that would be routed.

Kernel Compile Options:

Networking options  --->
    [*] Network firewalls
    ....
    [*] IP: forwarding/gatewaying
    ....
    [*] IP: firewalling
    [ ] IP: firewall packet logging

Configuration of the IP firewall rules is performed using the ipfwadm command. As I mentioned earlier, security is not something I am expert at, so while I will present an example you can use, you should do your own research and develop your own rules if security is important to you.

Probably the most common use of IP firewall is when you are using your linux machine as a router and firewall gateway to protect your local network from unauthorised access from outside your network.

The following configuration is based on a contribution from Arnt Gulbrandsen, <agulbra@troll.no>.

The example describes the configuration of the firewall rules on the Linux firewall/router machine illustrated in this diagram:

-                                   -
 \                                  | 172.16.37.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |  172.16.174.30 | Linux |      |
NET =================|  f/w  |------|    ..37.19
    |    PPP         | router|      |  --------
   /                 ---------      |--| Mail |
  /                                 |  | /DNS |
 /                                  |  --------
-                                   -

The following commands would normally be placed in an rc file so that they were automatically started each time the system boots. For maximum security they would be performed after the network interfaces are configured, but before the interfaces are actually brought up to prevent anyone gaining access while the firewall machine is rebooting.

#!/bin/sh

# Flush the 'Forwarding' rules table
# Change the default policy to 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. and for 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept

# First off, seal off the PPP interface
# I'd love to use '-a deny' instead of '-a reject -y' but then it
# would be impossible to originate connections on that interface too.
# The -o causes all rejected datagrams to be logged. This trades
# disk space against knowledge of an attack of configuration error.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30

# Throw away certain kinds of obviously forged packets right away:
# Nothing should come from multicast/anycast/broadcast addresses
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# and nothing coming from the loopback network should ever be
# seen on a wire
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24

# accept incoming SMTP and DNS connections, but only
# to the Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS uses UDP as well as TCP, so allow that too
# for questions to our name server
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# but not "answers" coming to dangerous ports like NFS and
# Larry McVoy's NFS extension.  If you run squid, add its port here.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
        -D 172.16.37.0/24 2049 2050

# answers to other user ports are okay
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
        -D 172.16.37.0/24 53 1024:65535

# Reject incoming connections to identd
# We use 'reject' here so that the connecting host is told
# straight away not to bother continuing, otherwise we'd experience
# delays while ident timed out.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113

# Accept some common service connections from the 192.168.64 and
# 192.168.65 networks, they are friends that we trust.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
        -D 172.16.37.0/24 20:23

# accept and pass through anything originating inside
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0

# deny most other incoming TCP connections and log them
# (append 1:1023 if you have problems with ftp not working)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24

# ... for UDP too
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24

Good firewall configurations are a little tricky. This example should be a reasonable starting point for you. The ipfwadm manual page offers some assistance in how to use the tool. If you intend to configure a firewall, be sure to ask around and get as much advice from sources you consider reliable and get someone to test/sanity check your configuration from the outside.

6.13 IPIP Encapsulation

Why would you want to encapsulate IP datagrams within IP datagrams? It must seem an odd thing to do if you've never seen an application of it before. Ok, here are a couple of common places where it is used: Mobile-IP and IP-Multicast. What is perhaps the most widely spread use of it though is also the least well known, Amateur Radio.

Kernel Compile Options:

Networking options  --->
    [*] TCP/IP networking
    [*] IP: forwarding/gatewaying
    ....
    <*> IP: tunneling

IP tunnel devices are called `tunl0', `tunl1' etc.

"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP network comprises a network address and a network mask. This produces a series of contiguous addresses that may all be routed via a single routing entry. This is very convenient, but it means that you may only use any particular IP address while you are connected to the particular piece of network to which it belongs. In most instances this is ok, but if you are a mobile netizen then you may not be able to stay connected to the one place all the time. IP/IP encapsulation (IP tunneling) allows you to overcome this restriction by allowing datagrams destined for your IP address to be wrapped up and redirected to another IP address. If you know that you're going to be operating from some other IP network for some time you can set up a machine on your home network to accept datagrams to your IP address and redirect them to the address that you will actually be using temporarily.

A tunneled network configuration.

As always, I believe a diagram will save me lots of confusing text, so here is one:

 192.168.1/24                          192.168.2/24

     -                                     -
     |      ppp0 =            ppp0 =       |
     |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |       //        |     |   |
     |---|  A  |------//---------|  B  |---|
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |                                     |
     -                                     -

The diagram illustrates another possible reason to use IPIP encapsulation, virtual private networking. This example presupposes that you have two machines each with a simple dial up internet connection. Each host is allocated just a single IP address. Behind each of these machines are some private local area networks configured with reserved IP network addresses. Suppose that you want to allow any host on network A to connect to any host on network B, just as if they were properly connected to the Internet with a network route. IPIP encapsulation will allow you to do this. Note, encapsulation does not solve the problem of how you get the hosts on networks A and B to talk to any other on the Internet, you still need tricks like IP Masquerade for that. Encapsulation is normally performed by machine functioning as routers.

Linux router `A' would be configured with:

#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -net 192.168.2.0 netmask 255.255.255.0 gw fff.ggg.hhh.iii tunl0

Linux router `B' would be configured with:

#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up
route add -net 192.168.2.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.2.1 up
route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0

The command:

route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP encap datagram with a destination address of aaa.bbb.ccc.ddd'.

Note that the configurations are reciprocated at either end. The tunnel device uses the `gw' in the route as the destination of the IP datagram in which it will place the datagram it has received to route. That machine must know how to decapsulate IPIP datagrams, that is, it must also be configured with a tunnel device.

A tunneled host configuration.

It doesn't have to be a whole network you route. You could for example route just a single IP address. In that instance you might configure the tunl device on the `remote' machine with its home IP address and at the A end just use a host route (and Proxy Arp) rather than a network route via the tunnel device. Let's redraw and modify our configuration appropriately. Now we have just host `B' which to want to act and behave as if it is both fully connected to the Internet and also part of the remote network supported by host `A':

 192.168.1/24

     -
     |      ppp0 =                ppp0 =
     |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
     |
     |   /-----\                 /-----\
     |   |     |       //        |     |
     |---|  A  |------//---------|  B  |
     |   |     |     //          |     |
     |   \-----/                 \-----/
     |                      also: 192.168.1.12
     -

Linux router `A' would be configured with:

#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -host 192.168.1.12 gw fff.ggg.hhh.iii tunl0
#
# Proxy ARP for the remote host
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub

Linux host `B' would be configured with:

#
PATH=/sbin:/usr/sbin
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.12 up
route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0

This sort of configuration is more typical of a Mobile-IP application. Where a single host wants to roam around the Internet and maintain a single usable IP address the whole time. You should refer to the Mobile-IP section for more information on how that is handled in practice.

6.14 IPX (AF_IPX)

The IPX protocol is most commonly utilised in Novell NetWare(tm) local area network environments. Linux includes support for this protocol and may be configured to act as a network endpoint, or as a router for IPX.

Kernel Compile Options:

Networking options  --->
    [*] The IPX protocol
    [ ] Full internal IPX network

The IPX protocol and the NCPFS are covered in greater depth in the IPX-HOWTO.

6.15 IPv6

Just when you thought you were beginning to understand IP networking the rules get changed! IPv6 is the shorthand notation for version 6 of the Internet Protocol. IPv6 was developed primarily to overcome the concerns in the Internet community that there would soon be a shortage of IP addresses to allocate. IPv6 addresses are 16 bytes long (128 bits). IPv6 incorporates a number of other changes, mostly simplifications, that will make IPv6 networks more managable than IPv4 networks.

Linux already has a working, but not completed, IPv6 implementation in the 2.1.* series kernels.

If you wish to experiment with this next generation Internet technology, or have a requirement for it, then you should read the IPv6-FAQ which is available from www.terra.net.

6.16 ISDN

The Integrated Services Digital Network (ISDN) is a series of standards that specify a general purpose switched digital data network. An ISDN `call' creates a synchronous point to point data service to the destination. ISDN is generally delivered on a high speed link that is broken down into a number of discrete channels. There are two different types of channels, the `B Channels' which will actually carry the user data and a single channel called the `D channel' which is used to send control information to the ISDN exchange to establish calls and other functions. In Australia for example, ISDN may be delivered on a 2Mbps link that is broken into 30 discreet 64kbps B channels with one 64kbps D channel. Any number of channels may be used at a time and in any combination. You could for example establish 30 seperate calls to 30 different destinations at 64kbps each, or you could establish 15 calls to 15 different destinations at 128kbps each (two channels used per call), or just a small number of calls and leave the rest idle. A channel may be used for either incoming or outgoing calls. The original intention of ISDN was to allow Telecommunications companies to provide a single data service which could deliver either telephone (via digitised voice) or data services to your home or business without requiring you to make any special configuration changes.

There are a few different ways to connect your computer to an ISDN service. One way is to use a device called a `Terminal Adaptor' which plugs into the Network Terminating Unit that you telecommunications carrier will have installed when you got your ISDN service and presents a number of serial interfaces. One of those interfaces is used to enter commands to establish calls and configuration and the others are actually connected to the network devices that will use the data circuits when they are established. Linux will work in this sort of configuration without modification, you just treat the port on the Terminal Adaptor like you would treat any other serial device. Another way, which is the way the kernel ISDN support is designed for allows you to install an ISDN card into your Linux machine and then has your Linux software handle the protocols and make the calls itself.

Kernel Compile Options:

ISDN subsystem  --->
        <*> ISDN support
        [ ] Support synchronous PPP
        [ ] Support audio via ISDN
        < > ICN 2B and 4B support
        < > PCBIT-D support
        < > Teles/NICCY1016PC/Creatix support

The Linux implementation of ISDN support a number of different types of internal ISDN cards. These are those listed in the kernel configuration options:

Some of these cards require software to be downloaded to them to make them operational. There is a seperate utility to do this with.

Full details on how to configure the Linux ISDN support is available from the /usr/src/linux/Documentation/isdn/ directory and an FAQ dedicated to isdn4linux is available at www.lrz-muenchen.de. (You can click on the english flag to get an english version).

A note about PPP. The PPP suite of protocols will operate over either asynchronous or synchronous serial lines. The commonly distributed PPP daemon for Linux `pppd' supports only asynchronous mode. If you wish to run the PPP protocols over your ISDN service you need a specially modified version. Details of where to find it are available in the documentation referred to above.

6.17 IP Masquerade

Many people have a simple dialup account to connect to the Internet. Nearly everybody using this sort of configuration is allocated a single IP address by the Internet Service Provider. This is normally enough to allow only one host full access to the network. IP Masquerade is a clever trick that enables you to have many machines make use of that one IP address, by causing the other hosts to look like, hence the term masquerade, the machine supporting the dialup connection. There is a small caveat and that is that the masqerade function nearly always works only in one direction, that is the masqueraded hosts can make calls out, but they cannot accept or receive network connections from remote hosts. This means that some network services do not work such as talk and others such as ftp must be configured to operate in passive (PASV) mode to operate. Fortunately the most common network services such as telnet, World Wide Web and irc do work just fine.

Kernel Compile Options:

Code maturity level options  --->
    [*] Prompt for development and/or incomplete code/drivers
Networking options  --->
    [*] Network firewalls
    ....
    [*] TCP/IP networking
    [*] IP: forwarding/gatewaying
    ....
    [*] IP: masquerading (EXPERIMENTAL)

Normally you have your linux machine supporting a slip or PPP dialup line just as it would if it were a standalone machine. Additionally it would have another network device configured, perhaps an ethernet, configured with one of the reserved network addresses. The hosts to be masqueraded would be on this second network. Each of these hosts would have the IP address of the ethernet port of the linux machine set as their default gateway or router.

A typical configuration might look something like this:

-                                   -
 \                                  | 192.168.1.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |                | Linux | .1.1 |
NET =================| masq  |------|
    |    PPP/slip    | router|      |  --------
   /                 ---------      |--| host |
  /                                 |  |      |
 /                                  |  --------
-                                   -

The most relevant commands for this configuration are:

# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 

You can get more information on the Linux IP Masquerade feature from the IP Masquerade Resource Page

6.18 IP Transparent Proxy

IP transparent proxy is a feature that enables you to redirect servers or services destined for another machine to those services on this machine. Typically this would be useful where you have a linux machine as a router and also provides a proxy server. You would redirect all connections destined for that service remotely to the local proxy server.

Kernel Compile Options:

Code maturity level options  --->
        [*] Prompt for development and/or incomplete code/drivers
Networking options  --->
        [*] Network firewalls
        ....
        [*] TCP/IP networking
        ....
        [*] IP: firewalling
        ....
        [*] IP: transparent proxy support (EXPERIMENTAL)

Configuration of the transparent proxy feature is performed using the ipfwadm command.

An example that might be useful is as follows:

ipfwadm -I -a accept -D 0/0 80 -r 8080
This example will cause any connection attempts to port 80 (www) on any host to be redirected to port 8080 on this host. This could be used to ensure that all WWW traffic from your network is automatically directed to a local WWW cache program.

6.19 Mobile IP

The term "IP mobility" describes the ability of a host that is able to move its network connection from one point on the Internet to another without changing its IP address or losing connectivity. Usually when an IP host changes its point of connectivity it must also change its IP address. IP Mobility overcomes this problem by allocating a fixed IP address to the mobile host and using IP encapsulation (tunneling) with automatic routing to ensure that datagrams destined for it are routed to the actual IP address it is currently using.

A project is underway to provide a complete set of IP mobility tools for Linux. The Status of the project and tools may be obtained from the: Linux Mobile IP Home Page.

6.20 Multicast

IP Multicast allows an arbitrary number of IP hosts on disparate IP networks to have IP datagrams simultaneously routed to them. This mechanism is exploited to provide Internet wide "broadcast" material such as audio and video transmissions and other novel applications.

Kernel Compile Options:

Networking options  --->
        [*] TCP/IP networking
        ....
        [*] IP: multicasting

A suite of tools and some minor network configuration is required. One source of information on how to install and configure these for Linux is provided at www.teksouth.com.

6.21 NAT - Network Address Translation

The IP Network Address Translation facility is pretty much the standardised big brother of the Linux IP Masquerade facility. It is specified in some detail in RFC-1631 at your nearest RFC archive. NAT provides features that IP-Masquerade does not that make it eminently more suitable for use in corporate firewall router designs and larger scale installations.

An alpha implementation of NAT for Linux 2.0.29 kernel has been developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-chemnitz.de. Michaels documentation and implementation are available from:

Linux IP Network Address Web Page

Newer Linux 2.1.* kernels also include some NAT functionality in the routing algorithm.

6.22 NetRom (AF_NETROM)

NetRom device names are `nr0', `nr1', etc.

Kernel Compile Options:

Networking options  --->
    [*] Amateur Radio AX.25 Level 2
    [*] Amateur Radio NET/ROM
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO. These protocols are used by Amateur Radio Operators world wide in packet radio experimentation.

Most of the work for implementation of these protocols has been done by Jonathon Naylor, jsn@cs.nott.ac.uk.

6.23 PLIP

PLIP device names are `plip0', `plip1 and plip2.

Kernel Compile Options:

Networking options  --->
    <*> PLIP (parallel port) support

plip (Parallel Line IP), is like SLIP, in that it is used for providing a point to point network connection between two machines, except that it is designed to use the parallel printer ports on your machine instead of the serial ports (a cabling diagram in included in the cabling diagram section later in this document). Because it is possible to transfer more than one bit at a time with a parallel port, it is possible to attain higher speeds with the plip interface than with a standard serial device. In addition, even the simplest of parallel ports, printer ports, can be used in lieu of you having to purchase comparatively expensive 16550AFN UART's for your serial ports. PLIP uses a lot of CPU compared to a serial link and is most certainly not a good option if you can obtain some cheap ethernet cards, but it will work when nothing else is available and will work quite well. You should expect a data transfer rate of about 20 kilobytes per second when a link is running well.

The PLIP device drivers competes with the parallel device driver for the parallel port hardware. If you wish to use both drivers then you should compile them both as modules to ensure that you are able to select which port you want to use for PLIP and which ports you want for the printer driver. Refer to the Modules-HOWTO for more information on kernel module configuration.

Please note that some laptops use chipsets that will not work with PLIP because they do not allow some combinations of signals that PLIP relies on, that printers don't use.

The Linux plip interface is compatible with the Crynwyr Packet Driver PLIP and this will mean that you can connect your Linux machine to a DOS machine running any other sort of tcp/ip software via plip.

In the 2.0.* series kernel the plip devices are mapped to i/o port and IRQ as follows:

device  i/o     IRQ
------  -----   ---
plip0   0x3bc   5
plip1   0x378   7
plip2   0x278   2

If your parallel ports don't match any of the above combinations then you can change the IRQ of a port using the ifconfig command using the `irq' parameter. Be sure to enable IRQ's on your printer ports in your ROM BIOS if it supports this option.

In late 2.1.* series kernel with Plug'n'Play support the plip devices are allocated sequentially as they are detected just like the ethernet devices with plip0 being the first allocated.

When compiling the kernel, there is only one file that might need to be looked at to configure plip. That file is /usr/src/linux/driver/net/CONFIG and it contains plip timers in milliseconds. The defaults are probably ok in most cases. You will probably need to increase them if you have an especially slow computer, in which case the timers to increase are actually on the other computer. A program called plipconfig exists that allows you to change these timer settings without recompiling your kernel. It is supplied with many Linux distributions.

To configure a plip interface, you will need to add the following lines to your network rc file:

#
# Attach a PLIP interface
#
#  configure first parallel port as a plip device
/sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End plip

Where:

IPA.IPA.IPA.IPA

represents your IP address.

IPR.IPR.IPR.IPR

represents the IP address of the remote machine.

The pointopoint parameter has the same meaning as for SLIP, in that it specifies the address of the machine at the other end of the link.

In almost all respects you can treat a plip interface as though it were a SLIP interface, except that neither dip nor slattach need be, nor can be, used.

Further information on PLIP may be obtained from the PLIP-mini-HOWTO

6.24 PPP

PPP devices names are `ppp0', `ppp1, etc. Devices are numbered sequentially with the first device configured receiving `0'.

Kernel Compile Options:

Networking options  --->
    <*> PPP (point-to-point) support

PPP configuration is covered in detail in the PPP-HOWTO.

Maintaining a permanent connection to the net with pppd.

If you are fortunate enough to have a semi permanent connection to the net and would like to have your machine automatically redial your PPP connection if it is lost then here is a simple trick to do so.

Configure PPP such that it can be started by the root user by issuing the command:

# pppd
Be sure that you have the `-detach' option configured in your /etc/ppp/options file. Then, insert the following line into your /etc/inittab file, down with the getty definitions:
pd:23:respawn:/usr/sbin/pppd
This will cause the init program to spawn and monitor the pppd program and automatically restart it if it dies.

6.25 Rose protocol (AF_ROSE)

Rose device names are `rs0', `rs1', etc. in 2.1.* kernels. Rose is available in the 2.1.* kernels.

Kernel Compile Options:

Networking options  --->
    [*] Amateur Radio AX.25 Level 2
    <*> Amateur Radio X.25 PLP (Rose)
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO. These protocols are used by Amateur Radio Operators world wide in packet radio experimentation.

Most of the work for implementation of these protocols has been done by Jonathon Naylor, jsn@cs.nott.ac.uk.

6.26 SAMBA - `NetBEUI', `NetBios' support.

SAMBA is an implementation of the Session Management Block protocol. Samba allows Microsoft and other systems to mount and use your disks and printers.

SAMBA and its configuration are covered in detail in the SMB-HOWTO.

6.27 SLIP client

SLIP devices are named `sl0', `sl1' etc. with the first device configured being assigned `0' and the rest incrementing sequentially as they are configured.

Kernel Compile Options:

Network device support  --->
    [*] Network device support
    <*> SLIP (serial line) support
    [ ]  CSLIP compressed headers
    [ ]  Keepalive and linefill
    [ ]  Six bit SLIP encapsulation

SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a serial line, be that a phone line with a dialup modem, or a leased line of some sort. Of course to use SLIP you need access to a SLIP-server in your area. Many universities and businesses provide SLIP access all over the world.

Slip uses the serial ports on your machine to carry IP datagrams. To do this it must take control of the serial device. Slip device names are named sl0, sl1 etc. How do these correspond to your serial devices ? The networking code uses what is called an ioctl (i/o control) call to change the serial devices into SLIP devices. There are two programs supplied that can do this, they are called dip and slattach

dip

dip (Dialup IP) is a smart program that is able to set the speed of the serial device, command your modem to dial the remote end of the link, automatically log you into the remote server, search for messages sent to you by the server and extract information for them such as your IP address and perform the ioctl necessary to switch your serial port into SLIP mode. dip has a powerful scripting ability and it is this that you can exploit to automate your logon procedure.

You can find it at: sunsite.unc.edu.

To install it, try the following:

#
# cd /usr/src
# gzip -dc dip337o-uri.tgz | tar xvf -
# cd dip-3.3.7o

<edit Makefile>

# make install
#

The Makefile assumes the existence of a group called uucp, but you might like to change this to either dip or SLIP depending on your configuration.

slattach

slattach as contrasted with dip is a very simple program, that is very easy to use, but does not have the sophistication of dip. It does not have the scripting ability, all it does is configure your serial device as a SLIP device. It assumes you have all the information you need and the serial line is established before you invoke it. slattach is ideal to use where you have a permanent connection to your server, such as a physical cable, or a leased line.

When do I use which ?

You would use dip when your link to the machine that is your SLIP server is a dialup modem, or some other temporary link. You would use slattach when you have a leased line, perhaps a cable, between your machine and the server and there is no special action needed to get the link working. See section `Permanent Slip connection' for more information.

Configuring SLIP is much like configuring an Ethernet interface (read section `Configuring an ethernet device' above). However there are a few key differences.

First of all, SLIP links are unlike ethernet networks in that there is only ever two hosts on the network, one at each end of the link. Unlike an ethernet that is available for use as soon are you are cabled, with SLIP, depending on the type of link you have, you may have to initialize your network connection in some special way.

If you are using dip then this would not normally be done at boot time, but at some time later, when you were ready to use the link. It is possible to automate this procedure. If you are using slattach then you will probably want to add a section to your rc.inet1 file. This will be described soon.

There are two major types of SLIP servers: Dynamic IP address servers and static IP address servers. Almost every SLIP server will prompt you to login using a username and password when dialing in. dip can handle logging you in automatically.

Static SLIP server with a dialup line and DIP.

A static SLIP server is one in which you have been supplied an IP address that is exclusively yours. Each time you connect to the server, you will configure your SLIP port with that address. The static SLIP server will answer your modem call, possibly prompt you for a username and password, and then route any datagrams destined for your address to you via that connection. If you have a static server, then you may want to put entries for your hostname and IP address (since you know what it will be) into your /etc/hosts. You should also configure some other files such as: rc.inet2, host.conf, resolv.conf, /etc/HOSTNAME and rc.local. Remember that when configuring rc.inet1, you don't need to add any special commands for your SLIP connection since it is dip that does all of the hard work for you in configuring your interface. You will need to give dip the appropriate information and it will configure the interface for you after commanding the modem to establish the call and logging you into your SLIP server.

If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure dip appropriately.

Dynamic SLIP server with a dialup line and DIP.

A dynamic SLIP server is one which allocates you an IP address randomly, from a pool of addresses, each time you logon. This means that there is no guarantee that you will have any particular address each time, and that address may well be used by someone else after you have logged off. The network administrator who configured the SLIP server will have assigned a pool of address for the SLIP server to use, when the server receives a new incoming call, it finds the first unused address, guides the caller through the login process and then prints a welcome message that contains the IP address it has allocated and will proceed to use that IP address for the duration of that call.

Configuring for this type of server is similar to configuring for a static server, except that you must add a step where you obtain the IP address that the server has allocated for you and configure your SLIP device with that.

Again, dip does the hard work and new versions are smart enough to not only log you in, but to also be able to automatically read the IP address printed in the welcome message and store it so that you can have it configure your SLIP device with it.

If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure dip appropriately.

Using DIP.

As explained earlier, dip is a powerful program that can simplify and automate the process of dialing into the SLIP server, logging you in, starting the connection and configuring your SLIP devices with the appropriate ifconfig and route commands.

Essentially to use dip you'll write a `dip script', which is basically a list of commands that dip understands that tell dip how to perform each of the actions you want it to perform. See sample.dip that comes supplied with dip to get an idea of how it works. dip is quite a powerful program, with many options. Instead of going into all of them here you should look at the man page, README and sample files that will have come with your version of dip.

You may notice that the sample.dip script assumes that you're using a static SLIP server, so you know what your IP address is beforehand. For dynamic SLIP servers, the newer versions of dip include a command you can use to automatically read and configure your SLIP device with the IP address that the dynamic server allocates for you. The following sample is a modified version of the sample.dip that came supplied with dip337j-uri.tgz and is probably a good starting point for you. You might like to save it as /etc/dipscript and edit it to suit your configuration:

#
# sample.dip    Dialup IP connection support program.
#
#               This file (should show) shows how to use the DIP
#       This file should work for Annex type dynamic servers, if you
#       use a static address server then use the sample.dip file that
#       comes as part of the dip337-uri.tgz package.
#
#
# Version:      @(#)sample.dip  1.40    07/20/93
#
# Author:       Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#

main:
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400

# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset

# Note! "Standard" pre-defined "errlevel" values:
#  0 - OK
#  1 - CONNECT
#  2 - ERROR
#
# You can change those grep'ping for "addchat()" in *.c...

# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble

# We are connected.  Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:

# We are now logged in.
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error

# Command the server into SLIP mode
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error

# Get and Set your IP address from the server.  
#   Here we assume that after commanding the SLIP server into SLIP
#   mode that it prints your IP address
get $locip remote 30
if $errlvl != 0 goto prompt_error

# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default

# Say hello and fire up!
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit

prompt_error:
print TIME-OUT waiting for sliplogin to fire up...
goto error

login_trouble:
print Trouble waiting for the Login: prompt...
goto error

password:error:
print Trouble waiting for the Password: prompt...
goto error

modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit

exit:
exit

The above example assumes you are calling a dynamic SLIP server, if you are calling a static SLIP server, then the sample.dip file that comes with dip337j-uri.tgz should work for you.

When dip is given the get $local command it searches the incoming text from the remote end for a string that looks like an IP address, ie strings numbers separated by `.' characters. This modification was put in place specifically for dynamic SLIP servers, so that the process of reading the IP address granted by the server could be automated.

The example above will automatically create a default route via your SLIP link, if this is not what you want, you might have an ethernet connection that should be your default route, then remove the default command from the script. After this script has finished running, if you do an ifconfig command, you will see that you have a device sl0. This is your SLIP device. Should you need to, you can modify its configuration manually, after the dip command has finished, using the ifconfig and route commands.

Please note that dip allows you to select a number of different protocols to use with the mode command, the most common example is cSLIP for SLIP with compression. Please note that both ends of the link must agree, so you should ensure that whatever you select agrees with what your server is set to.

The above example is fairly robust and should cope with most errors. Please refer to the dip man page for more information. Naturally you could, for example, code the script to do such things as redial the server if it doesn't get a connection within a prescribed period of time, or even try a series of servers if you have access to more than one.

Permanent SLIP connection using a leased line and slattach.

If you have a cable between two machines, or are fortunate enough to have a leased line, or some other permanent serial connection between your machine and another, then you don't need to go to all the trouble of using dip to set up your serial link. slattach is a very simple to use utility that will allow you just enough functionality to configure your connection.

Since your connection will be a permanent one, you will want to add some commands to your rc.inet1 file. In essence all you need to do for a permanent connection is ensure that you configure the serial device to the correct speed and switch the serial device into SLIP mode. slattach allows you to do this with one command. Add the following to your rc.inet1 file:

#
# Attach a leased line static SLIP connection
#
#  configure /dev/cua0 for 19.2kbps and cslip
/sbin/slattach -p cslip -s 19200 /dev/cua0 &
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End static SLIP.

Where:

IPA.IPA.IPA.IPA

represents your IP address.

IPR.IPR.IPR.IPR

represents the IP address of the remote end.

slattach allocates the first unallocated SLIP device to the serial device specified. slattach starts with sl0. Therefore the first slattach command attaches SLIP device sl0 to the serial device specified and sl1 the next time, etc.

slattach allows you to configure a number of different protocols with the -p argument. In your case you will use either SLIP or cSLIP depending on whether you want to use compression or not. Note: both ends must agree on whether you want compression or not.

6.28 SLIP server.

If you have a machine that is perhaps network connected, that you'd like other people be able to dial into and provide network services, then you will need to configure your machine as a server. If you want to use SLIP as the serial line protocol, then currently you have three options as to how to configure your Linux machine as a SLIP server. My preference would be to use the first presented, sliplogin, as it seems the easiest to configure and understand, but I will present a summary of each, so you can make your own decision.

Slip Server using sliplogin.

sliplogin is a program that you can use in place of the normal login shell for SLIP users that converts the terminal line into a SLIP line. It allows you to configure your Linux machine as either a static address server, users get the same address everytime they call in, or a dynamic address server, where users get an address allocated for them which will not necessarily be the same as the last time they called.

The caller will login as per the standard login process, entering their username and password, but instead of being presented with a shell after their login, sliplogin is executed which searches its configuration file (/etc/slip.hosts) for an entry with a login name that matches that of the caller. If it locates one, it configures the line as an 8bit clean line, and uses an ioctl call to convert the line discipline to SLIP. When this process is complete, the last stage of configuration takes place, where sliplogin invokes a shell script which configures the SLIP interface with the relevant ip address, netmask and sets appropriate routing in place. This script is usually called /etc/slip.login, but in a similar manner to getty, if you have certain callers that require special initialisation, then you can create configuration scripts called /etc/slip.login.loginname that will be run instead of the default specifically for them.

There are either three or four files that you need to configure to get sliplogin working for you. I will detail how and where to get the software and how each is configured in detail. The files are:

Where to get sliplogin

You may already have the sliplogin package installed as part of your distribution, if not then sliplogin can be obtained from: sunsite.unc.edu. The tar file contains both source, precompiled binaries and a man page.

To ensure that only authorised users will be able to run sliplogin program, you should add an entry to your /etc/group file similar to the following:

 ..
slip::13:radio,fred
 ..

When you install the sliplogin package, the Makefile will change the group ownership of the sliplogin program to slip, and this will mean that only users who belong to that group will be able to execute it. The example above will allow only users radio and fred to execute sliplogin.

To install the binaries into your /sbin directory and the man page into section 8, do the following:

# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# <..edit the Makefile if you don't use shadow passwords..>
# make install

If you want to recompile the binaries before installation, add a make clean before the make install. If you want to install the binaries somewhere else, you will need to edit the Makefile install rule.

Please read the README files that come with the package for more information.

Configuring /etc/passwd for Slip hosts.

Normally you would create some special logins for Slip callers in your /etc/passwd file. A convention commonly followed is to use the hostname of the calling host with a capital `S' prefixing it. So, for example, if the calling host is called radio then you could create a /etc/passwd entry that looked like:

Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin

It doesn't really matter what the account is called, so long as it is meaningful to you.

Note: the caller doesn't need any special home directory, as they will not be presented with a shell from this machine, so /tmp is a good choice. Also note that sliplogin is used in place of the normal login shell.

Configuring /etc/slip.hosts

The /etc/slip.hosts file is the file that sliplogin searches for entries matching the login name to obtain configuration details for this caller. It is this file where you specify the ip address and netmask that will be assigned to the caller and configured for their use. Sample entries for two hosts, one a static configuration for host radio and another, a dynamic configuration for user host albert might look like:

#
Sradio   44.136.8.99   44.136.8.100  255.255.255.0  normal      -1
Salbert  44.136.8.99   DYNAMIC       255.255.255.0  compressed  60
#

The /etc/slip.hosts file entries are:

  1. the login name of the caller.
  2. ip address of the server machine, ie this machine.
  3. ip address that the caller will be assigned. If this field is coded DYNAMIC then an ip address will be allocated based on the information contained in your /etc/slip.tty file discussed later. Note: you must be using at least version 1.3 of sliplogin for this to work.
  4. the netmask assigned to the calling machine in dotted decimal notation eg 255.255.255.0 for a Class C network mask.
  5. the slip mode setting which allows you to enable/disable compression and slip other features. Allowable values here are "normal" or "compressed".
  6. a timeout parameter which specifies how long the line can remain idle (no datagrams received) before the line is automatically disconnected. A negative value disables this feature.
  7. optional arguments.

Note: You can use either hostnames or IP addresses in dotted decimal notation for fields 2 and 3. If you use hostnames then those hosts must be resolvable, that is, your machine must be able to locate an ip address for those hostnames, otherwise the script will fail when it is called. You can test this by trying trying to telnet to the hostname, if you get the `Trying nnn.nnn.nnn...' message then your machine has been able to find an ip address for that name. If you get the message `Unknown host', then it has not. If not, either use ip addresses in dotted decimal notation, or fix up your name resolver configuration (See section Name Resolution).

The most common slip modes are:

normal

to enable normal uncompressed SLIP.

compressed

to enable van Jacobsen header compression (cSLIP)

Naturally these are mutually exclusive, you can use one or the other. For more information on the other options available, refer to the man pages.

Configuring the /etc/slip.login file.

After sliplogin has searched the /etc/slip.hosts and found a matching entry, it will attempt to execute the /etc/slip.login file to actually configure the SLIP interface with its ip address and netmask.

The sample /etc/slip.login file supplied with the sliplogin package 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 ...
#   SLIPunit ttyspeed   pid   the arguments from the slip.host entry
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 <hw_addr> pub
exit 0
#

You will note that this script simply uses the ifconfig and route commands to configure the SLIP device with its ipaddress, remote ip address and netmask and creates a route for the remote address via the SLIP device. Just the same as you would if you were using the slattach command.

Note also the use of Proxy ARP to ensure that other hosts on the same ethernet as the server machine will know how to reach the dial-in host. The <hw_addr> field should be the hardware address of the ethernet card in the machine. If your server machine isn't on an ethernet network then you can leave this line out completely.

Configuring the /etc/slip.logout file.

When the call drops out, you want to ensure that the serial device is restored to its normal state so that future callers will be able to login correctly. This is achieved with the use of the /etc/slip.logout file. It is quite simple in format and is called with the same argument as the /etc/slip.login file.

#!/bin/sh -
#
#               slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#

All it does is `down' the interface which will delete the manual route previously created. It also uses the arp command to delete any proxy arp put in place, again, you don't need the arp command in the script if your server machine does not have an ethernet port.

Configuring the /etc/slip.tty file.

If you are using dynamic ip address allocation (have any hosts configured with the DYNAMIC keyword in the /etc/slip.hosts file, then you must configure the /etc/slip.tty file to list what addresses are assigned to what port. You only need this file if you wish your server to dynamically allocate addresses to users.

The file is a table that lists the tty devices that will support dial-in SLIP connections and the ip address that should be assigned to users who call in on that port.

Its format is as follows:

# slip.tty    tty -> IP address mappings for dynamic SLIP
# format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0      192.168.0.100
/dev/ttyS1      192.168.0.101
#

What this table says is that callers that dial in on port /dev/ttyS0 who have their remote address field in the /etc/slip.hosts file set to DYNAMIC will be assigned an address of 192.168.0.100.

In this way you need only allocate one address per port for all users who do not require an dedicated address for themselves. This helps you keep the number of addresses you need down to a minimum to avoid wastage.

Slip Server using dip.

Let me start by saying that some of the information below came from the dip man pages, where how to run Linux as a SLIP server is briefly documented. Please also beware that the following has been based on the dip337o-uri.tgz package and probably will not apply to other versions of dip.

dip has an input mode of operation, where it automatically locates an entry for the user who invoked it and configures the serial line as a SLIP link according to information it finds in the /etc/diphosts file. This input mode of operation is activated by invoking dip as diplogin. This therefore is how you use dip as a SLIP server, by creating special accounts where diplogin is used as the login shell.

The first thing you will need to do is to make a symbolic link as follows:

# ln -sf /usr/sbin/dip /usr/sbin/diplogin

You then need to add entries to both your /etc/passwd and your /etc/diphosts files. The entries you need to make are formatted as follows:

To configure Linux as a SLIP server with dip, you need to create some special SLIP accounts for users, where dip (in input mode) is used as the login shell. A suggested convention is that of having all SLIP accounts begin with a capital `S', eg `Sfredm'.

A sample /etc/passwd entry for a SLIP user looks like:

Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^         ^^        ^^  ^^   ^^   ^^   ^^
|          |         |   |    |    |    \__ diplogin as login shell
|          |         |   |    |    \_______ Home directory
|          |         |   |    \____________ User Full Name
|          |         |   \_________________ User Group ID
|          |         \_____________________ User ID
|          \_______________________________ Encrypted User Password
\__________________________________________ Slip User Login Name

After the user logs in, the login program, if it finds and verifies the user ok, will execute the diplogin command. dip, when invoked as diplogin knows that it should automatically assume that it is being used a login shell. When it is started as diplogin the first thing it does is use the getuid() function call to get the userid of whoever has invoked it. It then searches the /etc/diphosts file for the first entry that matches either the userid or the name of the tty device that the call has come in on and configures itself appropriately. By judicious decision as to whether to give a user an entry in the diphosts file, or whether to let the user be given the default configuration you can build your server in such a way that you can have a mix of static and dynamically assigned address users.

dip will automatically add a `Proxy-ARP' entry if invoked in input mode, so you do not need to worry about manually adding such entries.

Configuring /etc/diphosts

/etc/diphosts is used by dip to lookup preset configurations for remote hosts. These remote hosts might be users dialing into your linux machine, or they might be for machines that you dial into with your linux machine.

The general format for /etc/diphosts is as follows:

 ..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
 ..

The fields are:

  1. login name: as returned by getpwuid(getuid()) or tty name.
  2. unused: compat. with passwd
  3. Remote Address: IP address of the calling host, either numeric or by name
  4. Local Address: IP address of this machine, again numeric or by name
  5. Netmask: in dotted decimal notation
  6. Comment field: put whatever you want here.
  7. protocol: Slip, CSlip etc.
  8. MTU: decimal number

An example /etc/net/diphosts entry for a remote SLIP user might be:

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296

which specifies a SLIP link with remote address of 145.71.34.1 and MTU of 296, or:

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006

which specifies a cSLIP-capable link with remote address 145.71.34.1 and MTU of 1006.

Therefore, all users who you wish to be allowed a statically allocated dial-up IP access should have an entry in the /etc/diphosts. If you want users who call a particular port to have their details dynamically allocated then you must have an entry for the tty device and do not configure a user based entry. You should remember to configure at least one entry for each tty device that your dialup users use to ensure that a suitable configuration is available for them regardless of which modem they call in on.

When a user logs in they will receive a normal login and password prompt at which they should enter their SLIP-login userid and password. If these verify ok then the user will see no special messages and they should just change into SLIP mode at their end. The user should then be able to connect ok and be configured with the relevant parameters from the diphosts file.

SLIP server using the dSLIP package.

Matt Dillon <dillon@apollo.west.oic.com> has written a package that does not only dial-in but also dial-out SLIP. Matt's package is a combination of small programs and scripts that manage your connections for you. You will need to have tcsh installed as at least one of the scripts requires it. Matt supplies a binary copy of the expect utility as it too is needed by one of the scripts. You will most likely need some experience with expect to get this package working to your liking, but don't let that put you off.

Matt has written a good set of installation instructions in the README file, so I won't bother repeating them.

You can get the dSLIP package from its home site at:

apollo.west.oic.com

/pub/linux/dillon_src/dSLIP203.tgz

or from:

sunsite.unc.edu

/pub/Linux/system/Network/serial/dSLIP203.tgz

Read the README file and create the /etc/passwd and /etc/group entries before doing a make install.

6.29 STRIP support (Starmode Radio IP)

STRIP device names are `st0', `st1', etc.

Kernel Compile Options:

Network device support  --->
        [*] Network device support
        ....
        [*] Radio network interfaces
        < > STRIP (Metricom starmode radio IP)

STRIP is a protocol designed specifically for a range of Metricom radio modems for a research project being conducted by Stanford University called the MosquitoNet Project. There is a lot of interesting reading here, even if you aren't directly interested in the project.

The Metricom radios connect to a serial port, employ spread spectrum technology and are typically capable of about 100kbps. Information on the Metricom radios is available from the: Metricom Web Server.

At present the standard network tools and utilities do not support the STRIP driver, so you will have to download some customised tools from the MosquitoNet web server. Details on what software you need is available at the: MosquitoNet STRIP Page.

A summary of configuration is that you use a modified slattach program to set the line discipline of a serial tty device to STRIP and then configure the resulting `st[0-9]' device as you would for ethernet with one important exception, for technical reasons STRIP does not support the ARP protocol, so you must manually configure the ARP entries for each of the hosts on your subnet. This shouldn't prove too onerous.

6.30 Token Ring

Token ring device names are `tr0', `tr1' etc. Token Ring is an IBM standard LAN protocol that avoids collisions by providing a mechanism that allows only one station on the LAN the right to transmit at a time. A `token' is held by one station at a time and the station holding the token is the only station allowed to transmit. When it has transmitted its data it passes the token onto the next station. The token loops amongst all active stations, hence the name `Token Ring'.

Kernel Compile Options:

Network device support  --->
        [*] Network device support
        ....
        [*] Token Ring driver support
        < > IBM Tropic chipset based adaptor support

Configuration of token ring is identical to that of ethernet with the exception of the network device name to configure.

6.31 X.25

X.25 is a circuit based packet switching protocol defined by the C.C.I.T.T. (a standards body recognised by Telecommunications companies in most parts of the world). An implementation of X.25 and LAPB are being worked on and recent 2.1.* kernels include the work in progress.

Jonathon Naylor jsn@cs.nott.ac.uk is leading the development and a mailing list has been established to discuss Linux X.25 related matters. To subscribe send a message to: majordomo@vger.rutgers.edu with the text "subscribe linux-x25" in the body of the message.

Early versions of the configuration tools may be obtained from Jonathon's ftp site at ftp.cs.nott.ac.uk.

6.32 WaveLan Card

Wavelan device names are `eth0', `eth1', etc.

Kernel Compile Options:

Network device support  --->
        [*] Network device support
        ....
        [*] Radio network interfaces
        ....
        <*> WaveLAN support

The WaveLAN card is a spread spectrum wireless lan card. The card looks very like an ethernet card in practice and is configured in much the same way.

You can get information on the Wavelan card from Wavelan.com.


Previous Next Contents