12 Experimental and Developmental modules.

Contents of this section

There are a number of people developing new features and modules for the Linux networking code. Some of these are in quite an advanced state (read working), and it is these that I intend to include in this section until they are standard release code, when they will be moved forward.

12.1 PPP - Point to Point Protocol.

The Point to Point Protocol is a modern and efficient protocol for conveying tcp/ip across serial links, that a lot of people use in place of slip. It offers enhanced functionality and security options.

The authors of the Linux port are Michael Callahan, <callahan@maths.ox.ac.uk> and Al Longyear, <longyear@netcom.com>. Most of this information has come from the documentation that accompanies the PPP software. The documentation is quite complete, in fact will tell you much more than I present here.

The code is still officially ALPHA which means you should exercise caution in using it. But there have been many reports of successful operation, and the authors feel confident that the new releases are quite stable.

The PPP code comes in two parts. The first is a kernel module which handles the assembly and disassembly of the frames, and the second is a set of protocols called LCP, IPCP, UPAP and CHAP, for negotiating link options and bringing the link into a functioning state and for authentication.

Where to obtain the PPP software.

The ppp software is available from:

ftp.gang.umass.edu

/usr/michael/linux-ppp-0.2.1.tgz

This file contains the kernel source, and the pppd source and binary. Version 0.2.1 is meant for use with kernels 1.0.x and 1.1.x.

Installing the PPP software.

Installation of the PPP software is fairly straightforward.

The kernel driver.

Some support for ppp has been built into the kernel for some time. Configuring the kernel is fairly easy, the following should work ok:

# cd /usr/src
# gzip -dc linux-ppp-0.2.1.tgz | tar xvf -
# cp /usr/src/linux-ppp-0.2.1/linux/ppp.c /usr/src/linux/drivers/net
# cp /usr/src/linux-ppp-0.2.1/pppd/ppp.h /usr/src/linux/include/linux

You will then need to uncomment the CONFIG_PPP line in /usr/src/linux/config.in. If you are running a version of the kernel that is 1.1.4 or higher, then you will also need to comment out or delete the macro definition of NET02D in the file /usr/src/linux/drivers/net/ppp.c

You can then do a make config, select PPP support, and follow with a make dep;make.

When you reboot with the new kernel you should see messages at boot time that look something like these:

PPP: version 0.2.1 (4 channels)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.

Now, try looking at the contents of /proc/net/dev. It should look something like this:

  Inter-|   Receive                  |  Transmit
   face |packets errs drop fifo frame|packets errs drop fifo colls carrier
      lo:      0    0    0    0    0        0    0    0    0     0    0
    ppp0:      0    0    0    0    0        0    0    0    0     0    0
    ppp1:      0    0    0    0    0        0    0    0    0     0    0
    ppp2:      0    0    0    0    0        0    0    0    0     0    0
    ppp3:      0    0    0    0    0        0    0    0    0     0    0

This indicates that the kernel driver is installed correctly.

pppd

If you want to recompile pppd, type make in the pppd subdirectory of the installation. There will be some warnings when compiling lcp.c, upap.c and chap.c but these are OK.

If you want to recompile chat, consult README.linux in the chat directory.

To install, type make install in the chat and pppd directories. This will put chat and pppd binaries in /usr/etc and the pppd.8 manual page in /usr/man/man8.

pppd needs to be run as root. You can either make it suid root or just use it when you are root. make install will try to install it suid root, so if you are root when you try to install it, it should work ok.

Configuring and using the PPP software.

Like slip, you can configure the PPP software as either a client or a server. The chat performs a similar function to the dip program in that it is used to automate the dialling and login procedure to the remote machine, unlike dip though, it does not perform the ioctl to convert the serial line into a PPP line, this is performed by the pppd program. pppd can act as either the client or the server. When used as a client, it normally invokes the chat program to perform the connection and login, and then it takes over by performing the ioctl to change the line discipline to ppp and then steps out of the way to let you operate.

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the operation of these utilities is much more complete than I have described here.

Configuring a PPP client by dial-up modem.

This is perhaps what most of you will want to do, so it appears first. You would use this configuration when you have a network provider who supports ppp by dialup modem. When you want to establish your connection you simply have to invoke the pppd program with appropriate arguments.

The following example might looks a little confusing at first, but it is easier to understand if you can see that all it is doing it taking a command line for the chat program as its first argument and then others for itself later.

pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: password'\
      /dev/cua1 38400 debug crtscts modem defaultroute 192.1.1.17:

What this says is:

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.

Configuring a PPP client via a leased line.

Configuring a PPP client via a leased line is almost as straightforward as for configuring slip with slattach. You will still use the pppd program, but since you won't need to establish the modem link the arguments to the chat program can be much simpler.

The example I'm presenting here assumes that the ppp server doesn't require any special login procedure. I do this because every login procedure will be different, and if you are simply running a local connection then it is possible that you might have it set up this way.

pppd connect 'echo connecting...' defaultroute noipdefault debug \
      kdebug 2 /dev/cua0 9600

This will echo a message to your screen, and set your default route via the ppp interface. The noipdefault argument instructs the pppd program to request the address to use for this device from the server. Debug messages will go to syslog. The kdebug 2 argument causes the debug messages to be set to level 2, this will give you slightly more information on what is going on. It will use /dev/cua0 at 9600 bps.

If your ppp server does require some sort of login procedure, you can easily use the chat program as in the example for the dialup server to perform that function for you.

Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.

Configuring a PPP server.

Configuring a PPP server is similar to establishing a slip server. You can create a special `ppp' account, which uses an executable script as its login shell. The /etc/passwd entry might look like:

ppp:EncPasswd:102:50:PPP client login:/tmp:/etc/ppp/ppplogin

and the /etc/ppp/ppplogin script might look like:

#!/bin/sh
exec /usr/etc/pppd passive :192.1.2.23

The address that you provide will the address that the calling machine will be assigned.

Naturally, if you want multiple users to have simultaneous access you would have to create a number of startup scripts and individual accounts for each to use, as you can only put one ip address in each script.

12.2 AX.25 - A protocol used by Amateur Radio Operators.

The AX.25 protocol is used by Amateur Radio Operators worldwide. It offers both connected and connectionless modes of operation, and is used either by itself for point-point links, or to carry other protocols such as tcp/ip and netrom.

It is similar to X.25 level 2 in structure, with some extensions to make it more useful in the amateur radio environment.

Alan Cox has developed some kernel based AX.25 software support for Linux and these are available in ALPHA form for you to try.

Where to obtain the AX.25 software.

Teh AX.25 software is available from:

sunacm.swan.ac.uk

/pub/misc/Linux/Radio/*

You will find a number of directories, each containing different versions of the code. Since it is closely linked with the kernel code, you will need to ensure that you choose the version appropriate for the kernel version you are running. The following table shows the mapping between the two:

AX25007                 Prehistoric
AX25010                 Obsolete
AX25012                 Current AX.25 kernel release for 1.0.* kernels
AX25017                 Current AX.25 kernel release for 1.1.6+ kernels
patch10-11              Patch from AX.25 010 to 011

In each directory you will find at least two files, one called something like krnl017.tgz, and the other called something like user017.tgz. These are the kernel software, and the user programs respectively.

Installing the AX.25 software.

The software comes in two parts, the kernel drivers, and the user programs.

The kernel drivers.

To install the kernel drivers, do the following:

# cd /usr/src
# gzip -dc krnl017.tgz | tar xvf -

you will need to uncomment the CONFIG_AX25 define in the /usr/src/linux/config.in file.

You should then:

# cd /usr/src/linux
# make config
# make dep;make

Be sure to answer `yes' when you are asked if you should include the AX.25 support in the make config step.

The user programs.

To install the user programs you should try:

# cd /
# gzip -dc user017.tgz | tar xvvof -

You should then:

# cd /usr/local/ax25/src
# make install

Configuring and using the AX.25 software.

Configuring an AX.25 port is very similar to configuring a slip device. The AX.25 software has been designed to work with a TNC in kiss mode. You will need to have the TNC preconfigured and connected.

You use the axattach program in much the same way as you would use the slattach program. For example:

# /usr/local/ax25/bin/axattach -s 4800 /dev/cua1 VK2KTJ &

would configure your /dev/cua1 serial device to be a kiss interface at 4800 bps, with the hardware address VK2KTJ.

You would then use the ifconfig program to configure the ip address and netmask as for an ethernet device:

# /sbin/ifconfig sl0 44.136.8.5
# /sbin/ifconfig sl0 netmask 255.255.255.0
# /sbin/ifconfig sl0 broadcast 44.136.8.255
# /sbin/ifconfig sl0  arp mtu 257 up

To test it out, try the following:

/usr/local/ax25/bin/call VK2DAY via VK2RVT

The call program is a linemode terminal program for making ax.25 calls. It recognises lines that start with `~' as command lines. The `~.' command will close the connection.

I haven't had a chance to try this code out yet, please refer to the man pages in /usr/local/ax25/man for more information.

12.3 NIS - Sun Network Information System.

There are in fact two NIS implementations being distributed. Firstly there is a rudimentary implementation int he standard libc ditribution which however requires binding to to servers via ypbind before use. A more clean implementation tending towwards the NIS+ implementation is called NYS written by Peter Eriksson, <pen@lysator.liu.se> and is available from:

ftp.funet.fi

/pub/OS/Linux/BETA/NYS/nys-0.26.tar.gz

An NIS style server can be retrieved from:

ftp.funet.fi

/pub/OS/Linux/BETA/NYS/ypserv-0.5.tar.gz

Check there are no newer versions, as this information might now be slightly dated.

Both of these are fully fucntional and they have been used extensively with no troubles to query Sun servers for NIS information like passwd/hosts/group etc. and don't require binding to arbitrary servers. In fact they allow you to specify servers for services and have the ability to select a yp/dns/file option for name/passwd/etc. resolution of sepcific services. They are extremely easy to set up, and recommended for client machines intgrating into larger network.

Clearly your network daemons and clients need to be recompiled to link with the shared library libnsl.so to make use of the YP facilities. This is fairly trivial and an NYS package of all network clients and daemons is currently being compiled.

If you have more detailed information on NIS, please email me.

12.4 snmp agent.

There is an experimental snmp agent for linux, that I lost the information for after an accidental deletion of 6 weeks worth of updating this document. I'll see if I can find it for the next release.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter