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. The topics are sorted alphabetically.
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:
root# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
root# 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.
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:
user% tar xvfz .../netatalk-1.4b2.tar.Z
user% make
root# make install
You may want to edit the `Makefile' before calling make to actually compile the software. Specifically, you might want to change the DESTDIR variable which defines where the files will be installed later. The default of /usr/local/atalk is fairly safe.
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.
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 privileges 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.
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.
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:
root# /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.
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.
/etc/rc.d/rc.inet1 file.
.AppleDesktop'' and Network Trash
Folder. Then, for each directory you access it
will create a .AppleDouble below it so it can
store resource forks, etc. So think twice before
exporting /, you will have a great time
cleaning up afterwards.
/proc/net/
directory if you need it.
For a much more detailed description of how to configure Appletalk for Linux refer to Anders Brownworth Linux Netatalk-HOWTO page at thehamptons.com.
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.
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.
Support for DECNet is currently being worked on. You should expect it to
appear in a late 2.1.* kernel.
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.
Larry Stefani, lstefani@ultranet.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 to that of an ethernet interface. You just specify the appropriate FDDI interface name in the ifconfig and route commands.
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:
user% tar xvfz .../frad-0.15.tgz
user% cd frad-0.15
user% for i in common dlci frad; make -C $i clean; make -C $i; done
root# mkdir /etc/frad
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
root# install -m 700 -o root -g root frad/fradcfg /sbin
rppt# install -m 700 -o root -g root dlci/dlcicfg /sbin
Note that the previous commands use sh syntax, if you use a csh flavour instead (like tcsh), the for loop will look different.
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 overridden 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 recognized
#
# 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. These commands are best hosted in a shell
script, due to their number:
#!/bin/sh
# 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
#
AF_IPX)
The IPX protocol is most commonly utilized 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.
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.
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.
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.
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 customized 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.
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.
X.25 is a circuit based packet switching protocol defined by the
C.C.I.T.T. (a standards body recognized 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.
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.