Networking with Amigas.

1. Using the Amiga as a multi-user single node host.

There's a few ways to do this, depending on your configuration.

1.1. Low end.

If you have two Amigas, then the simplest way is to use a variant of the ParNet system to link the two machines together. Software exists on Aminet to install a simple client/server system on the two machines to enable one to open a shell on the window on it's own screen, but with STDIO going to the remote computer. This would enable two users to use shell based networking tools- such as telnet- to link out. IRCing simply involves (in the absence of a text based local IRC client) telnetting to a suitable public server such as dismayl.demon.co.uk. Although I've never used this technique, and so can't give details on where to find the client/server software (other than Aminet!), this should give multisession capability. In other words, unlike a standard ASCII/null modem link, you could have two seperate shells running different programs. It does, however, rely on two Amigas being available.

1.2. Mid range.

Whichever method you use, you now have at least one spare serial conection, which can be used by anything capable of emulating a standard ASCII RS232 based terminal- such as the ancient VT100 terminals I have around here. You then plug them in, set the serial parameters, and (if using the built in serial port) use the standard AUX: device to run a remote shell on it (i.e. by typing newshell AUX: on the Amiga).

For running more than one remote terminal, you need to replace Commodore's AUX: device with a multi unit one such as AuxHandler, in the comm/misc section of Aminet. Note that, although BSC provide a set of terminal drivers with their MultiFace software, these aren't as effective as the Aminet version and can cause problems with genuine VT100 terminals. It's also a good idea when taking this path to obtain versions of software that can function with STDIO as opposed to opening their own windows. For instance, the aux-emacs program in the text/edit category is a good replacement for AmigaDOS's ed command, and AmigaElm and Tin are both good additions.

Using remote dumb terminals, while good for light use, have their drawbacks. There is not (as yet!) a program available on the Amiga similar to the screen command of Unix systems, so it is only possible to have a single session running from each remote terminal. In addition, it is impossible to use the CTRL-Z key combination to switch between processes. Therefore, if you have several 'good' computers, such as any combination of Amigas, modern PC's or Macintoshes, it's a good idea to look at the next section.

2. Using Amigas on Local TCP/IP Based Networks.

If you have several machines locally and only one has a real internet address that can be routed to from outside- for example, you have a dialup IP account with an ISP, then there is a new way of networking the machines.

Let's discuss the simplest case. You have an Amiga, with a modem, and it has a spare serial port. It also has its own internet address and is running a TCP stack- I'll be talking about AmiTCP but this applies to anything. You also have either another Amiga, or a PC running some form of networking software- either Linux, Win3.1 with Winsock or whatever. Although if you've managed to install Linux, I don't know why you're using the modem on the Amiga :)

The Amiga communicates with the outside world by means of either a SLIP or PPP connection via the modem. I'll discuss SLIP, but everything's as relevant to PPP. You can also connect a null modem cable between the spare serial pots of the two machines, over which you run another slip connection.

Let's call the Amiga with the modem "A" and the other one is "B". What a truly inspired choice of labels. You COULD communicate with the outside world from B by telnetting to A, logging in to it, and then telnetting out from there using the same kind of STDIO telnet clients as discussed earlier. But what if you want to use Netscape? It would be nice to be able to give B it's own network address, and be able to route data through A, which is now referred to as the 'gateway,' to and from the outsie world. The obvious way to do this would be to make up a fake address for B and pretend to the outside world that this is a real address- however this wouldn't work at all.

If we allocated, say, the address 200.1.1.1 to B and tried to telnet out to a remote machine, that remote machine would recieve the data we send out, but would try and send responses back to the real 200.1.1.1, so as well as not working, there is also a chance of causing someone else a few problems.

Clearly, from outside, all connections from the local network must appear to be coming from the one gateway Amiga, and that machine must be able to sort out for itself which of the data streams coming from outside are to be routed to which local machines. This isn't as difficult as it appears, and figure 1 shows a schematic of the setup.  We see that the Amiga actually has two different addresses; for the purposes of the outside Internet, it is referred to as 158.152.100.100, while on the local network it has the label 10.1.1.1.

To allow the Amiga to function in tthis schizophrenic manner, it is necessary to reconfigure the internal loopback device lo0 to act as a network interface between addresses 158.152.100.100 and 10.1.1.1- and further, to add a route from 158.152.100.100 to 10.1.1.1 via this interface. We do this with the two commands;

At this point, it is necessary to check the startnet script, and also anything like user-startup, to remove any definitions of the lo0 interface that may conflict. For good measure, it's also a good idea that the machine knows that at least the name localhost is used to refer to itself, and if your machine happens to be called wibble, we'd like to be able to use that name as well. So we need to make sure the following commands also exist somewhere;

Machine A is now set up as far as we need for the present. It is now necessary to move to the second machine. The connection between machine A and B could be via any physical interface for which a SANA2 compliant device is available- SLIP, PLIP, floppy port networks and Ethernet are all commonly available, and if anyone knows of a SANA2 driver for SCSI, I'd appreciate it if you could drop me a line ;)

Let's assume you're going to take the simplest option and go for a SLIP connection. You need a null modem cable connected between a spare serial port on each machine, and you need to set the networking up on machine B very simply- the address of machine B is 10.1.1.2 and the address to give it for a gateway is 10.1.1.1. If you need any other addresses for an auto installer, then you must give 10.1.1.1- no addresses off the local network will work for the reason givven earlier.

You also need to add the following command to the startup of machine A;

and, obviously, you need to make a slip1.config file in env:sana2/. You can figure out how to do this by looking at the slip0.config file set up when you first installed your network software- the only things you need to change are the serial device, unit and speed.

On booting both machines now and running the network software, you should be able to ping one machine from the other, and telnet from B to A. It would be possible to use this network as it is, by the user of B telnetting to A, logging in and then telnetting out from there to run text only sessions offsite. However, it is quite easy, and worth the extra time, to set up a transparent mechanism by which machine B can use GUI IRC clients, graphical WWW browsers and the like.

There are two items of software that are needed; socklink100.lha and htpproxy.lha, both available in the comm/tcp ddirectory of your local Aminet site. Note that by the time this is read, socklink is going to be a higher version than 1.00 and search for it accordingly ;)

The description of Socklink is that it "links stdio to socket". This sounds uninteresting- however, if you consider what happens if an entry is made in the file inet:db/inetd.conf (for an AmiTCP based setup) along the lines of

irc stream tcp dos bin - amitcp:bin/socklink dismayl.demon.co.uk 6667

And an entry is made in the services file allocating the name 'irc' to port 6667 then any incoming connections to port 6667 of the machine will automatically- and entirely transparently- be routed to port 6667 of dismayl. This means that a GUI IRC client can be run on B and be told to use 1.1.1.1 port 6667 as it's server, and will in actual fact be transparently conecting to the real IRC server running at Demon. Because the connection to Dismayl originates at machine A, there is no problem with packets being routed back to the wrong address.

This technique can be used to allow telnet sessions from machine B to connect "directly" to external sites without the user needing to log in to machine A- as long as only a few external sites are routinely telnetted to (which is usually the case).

For example, the first of the following extracts is from my amitcp:db/services file, and the second from the inetd.conf file:

 irc         stream tcp dos bin - amitcp:bin/socklink dismayl.demon.co.uk 6667

 oook        stream tcp dos bin - echo "oook to you too!"

 netstat     stream tcp dos bin - inet:bin/systat

 unixa       stream tcp dos bin - amitcp:bin/socklink unixa.lancs.ac.uk 23

 unixb       stream tcp dos bin - amitcp:bin/socklink unixb.lancs.ac.uk 23

 dismayl     stream tcp dos bin - amitcp:bin/socklink dismayl.demon.co.uk 23

 gate        stream tcp dos bin - amitcp:bin/socklink gate.demon.co.uk 79

 post        stream tcp dos bin - amitcp:bin/socklink post.demon.co.uk 79

 

 irc         6667/tcp       ;local mirror of dismayl.demon.co.uk (irc)

 httpproxy   8080/tcp       ;HTTP local proxy

 unixa       9001/tcp       ;local gate to unixa.lancs.ac.uk (telnet)

 unixb       9002/tcp       ;local gate to unixb.lancs.ac.uk (telnet)

 dismayl     9003/tcp       ;local gate to dismayl.demon.co.uk (telnet)

 gate        9004/tcp       ;local gate to gate.demon.co.uk (finger)

 post        9005/tcp       ;local gate to post.demon.co.uk (finger)

Most browsers allow the use of a proxy, so once httpproxy is downloaded and installed (very understandable instructions are supplied), using it is simply a matter of defining 10.1.1.1 to be the proxy server, and everything from then on operates transparently.

You should now have a local network on which all the machines are capable of accessing the outside internet as if they were connected directly to it, bar a few easily avoidable limitations. It should be remembered though that InetD does not pay any attention to what site is connecting to a specific port on the machine- all sites are either allowed to connect or not allowed. Thus, you should avoid doing anything that may cause a conflict with an external service- for example, it is a very bad idea to link port 25 of 10.1.1.1 to port 25 of post.demon to allow B to post mail- Demon will then no longer be ablee to connect to you and you will not recieve any mail. (connections from post to 10.1.1.1 will be routed straight back to post).

The choice of fake addresses (10.1.1.1 for example) that we have made is not truly arbitrary. There are three sets of numberic IP address that, by convention, are unrouted; that is, they are set aside for uses like this one and there is no real machine anywhere called 10.1.1.1. The three ranges of address that can be used are:

 10.0.0.0 - 10.255.255.255

172.16.0.0 - 172.31.255.255

192.168.0.0 - 192.168.255.255

This document was created, and the copyright is held by, Craig Graham (email craig@blksheep.demon.co.uk.) It is not public domain, but may freely be distributed provided the text is intact and unaltered, and this footer is present.

BACK