Next Previous Contents

8. Other Network Technologies

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.

8.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: 

        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.

8.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: 

        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.

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 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.

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: 

        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.

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.

8.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.

8.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.

8.5 DECNet

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

8.6 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.

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.

8.7 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: 

        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
        #

8.8 IPX (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.

8.9 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.

8.10 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.

8.11 SAMBA - `NetBEUI', `NetBios', `CIFS' 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.

8.12 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 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.

8.13 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.

8.14 X.25

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.

8.15 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.

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:21