RISC OS Networking
Richard Walker continues his series
TCP/IP and further configuration
Last time, we looked at the cabling and simple file and printer sharing between RISC OS computers. The configuration, you may recall, did not co-exist with any existing settings that you may have. For example, if you loaded the ANT Internet Suite and connected to your ISP, the network-shared discs and printers would probably stop working. We will start this instalment with a look at TCP/IP, and then use some of this theory to refine the network configuration. It may seem complicated, or even rather academic, but it will make more sense as the series continues - I promise!
TCP/IP from the beginning
TCP/IP is short for 'Transmission Control Protocol over Internet Protocol'. It is a protocol for communication between computers on networks and is the basis for standard Internet protocols (e.g. HTTP or FTP). What makes TCP/IP rather important and useful is that it is a formally defined and agreed specification that a very wide range of computer systems can use. The scenarios in this article are biased towards RISC OS computers, but any of them could be, for example, x86-compatible PCs running Microsoft Windows, or Apple Macintosh computers, or Unix workstations.
Network software, such as email clients or web browsers, generally sit 'on top' of the TCP/IP software. This means that they work with anything which supports TCP/IP. The "stack diagram" (figure 6) will explain this later.
RISC OS has an implementation of TCP/IP in it's 'Internet' module, which has been part of the OS since version 3.6. For RISC OS 3.1 and 3.5, the software is generally provided on the ROM of your Ethernet card. To further confuse things, updated versions are also available on disc to soft-load! As a matter of historical interest, the Internet module was also available for RISC OS 2, as part of Acorn's 'TCP/IP Protocol Suite', and it remained commercial until Spring 1995, when Acorn released the module on it�s FTP site (after which RISC OS 3.6 also appeared).
Network interfaces
A network interface (usually an Ethernet card) must be configured to use TCP/IP. Note that a single computer can have multiple network interfaces, so it is vague to think of the TCP/IP configuration for 'a computer'. Each interface has a name, (assigned by the interface driver), an IP address and a 'netmask'. The netmask sets up the addressable 'range' of the network interface - we will see this later.
Fig. 1 - A single TCP/IP network
Each computer on the (10base2) network in figure 1 has an IP address of the form 192.168.0.x, where x is unique. Note that all the dot-separated numbers can be between 0 and 255. It is very important that IP addresses are unique. If, for example, the A7000 was accidentally re-configured with an IP address of 192.168.0.1 (the same as the A5000) it's TCP/IP software would stop working immediately, and errors would be flagged to the user. If this didn't happen, imagine the confusion that would reign if, say, the RISC PC requested a file from 192.168.0.1 (what it thought was the A5000).
The netmask value of 255.255.255.0 indicates that the only locally-addressable computers are in the range 192.168.0.x. If, for example, some software on the RS7500+ computer tries to contact 192.168.1.123 or 123.456.789.10, then the TCP/IP software knows that this is not possible, and will not even bother trying. Actually, it will report 'No route to host', and routes will be explained later. Conversely, if the RS7500+ computer tries to contact 192.168.0.5, it would attempt to do so over the network, and some time later, would time out with a 'host not found' (or similar) error.
The loopback interface
Usually, a computer with TCP/IP software will also have an additional interface present. This is not a physical hardware interface (like an Ethernet card) but a software interface. It points back to the computer itself, and is known as the loopback interface. It has the fixed IP address of 127.0.0.1 and a netmask of 255.0.0.0.
Loopback interfaces are useful. They let you for run TCP/IP client and server applications on a single computer - you simply point the client to 127.0.0.1. For example, you can run a web server and a web browser at the same time, and test the served pages by pointing the browser to http://127.0.0.1/
The loopback interface requires no user configuration - it is automatically configured by the RISC OS TCP/IP software.
Multiple interfaces and routing
As mentioned earlier, it is possible to have more than one TCP/IP network interface in a computer. This is often used to join networks together.
Fig. 2 - Two connected TCP/IP networks
In figure 2, there are actually two separate networks here, so the lower one is shown with broken lines to help illustrate this. If each interface were configured as shown, the A440/1 and A3020 would be able to communicate with each other and the A7000. Similarly, the A5000, RISC PC and RS7500+ would be able to communicate with each other and the A7000. Note that the traffic between the A440/1, A3020 and A7000 computers (in the 192.168.1.x network) will not be visible to others. This can be useful for controlling the network traffic.
Supposing the computers were all on the same network, and A440/1 and A3020 spent all day throwing many megabytes of data between themselves - it would ruin the network performance for the other computers. With the separation in the diagram above, this wouldn't be too much of a problem - only communication between the A7000 and A440/1 or A3020 would be affected.
But what if we want to maintain the useful separation and allow cross-network communication? That is also possible! Each client needs to have 'routes' configured. Consider the A5000 wanting to communicate with the A440/1: it already knows that it can access any 192.168.0.x computer directly, but it doesn't know how to access anything else. A simple route configuration is all that is required to tell the A5000 that it can access the 192.168.1.x network via the A7000. However, this will only allow one-way communication, since the A440/1 doesn't know how to talk back to the A5000! So, the A440/1 must also have it's route configuration modified - it must know that to reach the 192.168.0.x network, it has to go via the A7000. Similar route configuration adjustments can be carried out on the rest of the computers, so they can all communicate.
Note that the A7000 has become a 'gateway' (or 'router') - it has to look at incoming data and forward it to the appropriate network. For this to be allowed, it also needs some configuration changes (to switch on the forwarder).
Fig. 3 - Three connected TCP/IP networks
In figure 3, we have a third network. The same routing can be achieved (i.e. all the computers able to communicate with each other) but it is complex. For example, for the A3020 to contact the A5000, it needs to know that the 192.168.1.x network is accessible via the RS7500+, and the 192.168.0.x network is accessible via the A7000 - and similar information would need adding to all of the computers. Then imagine how much worse it would be with a hundred networks! Thankfully, there is a way around this. Each computer has a 'default route' setting. This can be set to the address of a computer that is on the same network (so accessible without any special route configuration) which knows how to access all of the other networks. Basically, if a computer knows it cannot connect directly to another (by checking it's netmask) it will try via the default route.
For example, the RS7500+ could be told how to access the 192.168.0.x network (via the A7000) and the A7000 could be told how to access the 192.168.2.x network (via the RS7500+). All the other computers can simply have their default route set to the RS7500+ or the A7000 (which ever one is on the same network). Again, consider the situation with a hundred networks - but this time it isn't so bad!
The default route is used when you connect to your ISP.
Fig. 4 - TCP/IP and the default route
Figure 4 is a highly-typical use of the default route. The A7000 will simply have it's default route set to the ISP router (16.3.34.1) which manages all the scary routing to other Internet networks for us.
There is a vague side-issue here. If you have a local network connected to the Internet, how do you ensure the IP addresses that you choose do not clash with other Internet-connected networks? Again, this has all been thought out! There are dedicated IP address ranges which are never forwarded around the Internet (by ISP routers etc.) so you can use them on your own local networks without fuss. The 'private range' addresses are 192.168.x.y with a netmask of 255.255.0.0 and 10.a.b.c with a netmask of 255.0.0.0. You can adopt either scheme (of a subset) on an internal network, and don't need to worry about duplicating IP addresses across the Internet! So, if you are building a home network, I would strongly recommend you use an addressing scheme that is compatible with the 'private address range' rules. That way, if you ever connect it to the Internet, you won't have to change all your IP addresses!
Host and domain names
All this talk of IP addresses can seem complicated. They are not exactly convenient to use, especially when it comes to remembering them! Thankfully, help is at hand - we have 'host names'. These are alphanumeric identifiers for each interface IP address. For example, we could give IP address 192.168.0.1 the name 'fred'. It is much easier for us to remember fred than 192.168.0.1! There is also the concept of a 'domain name', which is a name for a the group of IP addresses covered by the netmask. That isn't so easy to understand, so refer to figure 5.
Fig. 5 - Two connected TCP/IP networks with host and domain names
You can see how each computer can be referred to by the combination of it's host name (e.g. atom) and it's domain name (e.g. acorn) with the format:
Using host and domain names (rather than IP addresses) is much more convenient for the users (but not the computer!). Each computer will need to know which host and domain names map onto which IP addresses. A simple 'hosts database' for the above would look something like this:
192.168.0.1 atom atom.acorn
192.168.0.2 proton proton.acorn
192.168.0.3 gluon gluon.acorn
192.168.0.3 electron electron.acorn
192.168.1.1 grape grape.fruit
192.168.1.2 apple apple.fruit
192.168.1.3 banana banana.fruit
The TCP/IP software will automatically use this database to cross-reference host and domain names with IP addresses. However, consider the difficulty involved with maintaining a hosts database on each computer, especially with a large collection computers - and what about the Internet itself? It would be impossible for every Internet-connected computer to know the fully-qualified domain name of every other connected computer!
Domain Name Servers (DNS)
Fortunately, there is a solution to the hassle of maintaining separate hosts databases. We can have one computer holding the database and the other computers can refer to it every time they need to translate a host name into an IP address. This is what 'domain name servers' provide. For the situation in figure 5, each computer would only have to know the IP address (not the host name!) of the domain name server, which would perform all the IP address lookups as required. If the IP address of one of the computer's interfaces had to change, or a new computer is added, it is less hassle to update one database, rather than several.
It would make sense for the A7000 to be the domain name server, since it is directly accessible by the computers on the acorn and fruit domains, so lookups will be slightly quicker. However, this does not have to be the case, as the routing configuration means that the computers can all communicate anyway.
Once a computer has used a domain name server to lookup an IP address, it tends to cache the information in it's own memory to save repeated lookups (which are performed over the network, so are not terribly fast).
With the Internet, there are a large number of domain name servers. They work together by passing around host and domain name information and the corresponding IP addresses.
RISC OS implementation details
Many people refer to the RISC OS 'network stack' or 'TCP/IP stack'. What does this mean? Essentially, it is the collection of operating system software that provides the framework for network client applications (e.g. web browsers) to operate. Note that RISC OS does not provide all of the framework out-of-the-box, many parts are optional extras. Strictly speaking, 'TCP/IP stack' only refers to a subset of the stack - there are non-TCP/IP parts. The term 'stack' is used because the software is layered. Consider figure 6 below:
Fig. 6 - The RISC OS network stack
At the bottom, we have the most physical elements such as the actual network interface hardware and the associated drivers. Further up the diagram, the software becomes more abstracted from the hardware. This allows such cleverness as a web browser receiving web pages via a PPP/modem connection to the Internet, or an Ethernet-based connection. To further confuse the issue, some of the components (namely LanManFS) can communicate without a TCP/IP interface being configured, because they can talk directly to the network driver and use a different network protocol (in the case of LanManFS this is NetBEUI). Most components operate 'over' TCP/IP, that is, they use the Internet module (directly or indirectly) and thus use the TCP/IP interface(s).
Applications communicate with a variety of points in the diagram. For example, Printers can communicate with NetPrint, NFS, Freeway or LanManFS to achieve network printing. The OmniClient Filer front-end can communicate with NetFS, NFS, ShareFS or LanManFS to connect to shared network directories. A web browser can communicate directly with Internet to retrieve web pages via HTTP.
Some of those component names may sound obscure. To help:
The four Net? components are what is referred to as 'AUN', the software which you would typically use to connect to an Acorn Level 4 file or printer server.
The Freeway and ShareFS components are what is referred to as 'Acorn Access', the file and printer sharing system we looked at last time.
The NFS (Network File System) and LanManFS (LAN Manager) components are part of the OmniClient software and used for connecting to NFS file and printer shares (usually on Unix systems) or LAN Manager file and printer shares (usually on Microsoft Windows systems).
So, to use any of these network services, as a general minimum, the underlying component software, Internet and one or more network interface drivers, must be configured correctly (LanManFS being the interesting exception!).
RISC OS configuration
A lot of confusion arises because of the way the network configuration is handled with RISC OS. As the critical modules (Internet and MbufManager) were not part of RISC OS until version 3.6, and were not easily configured until version 3.7, the popular Internet connectivity applications (which started to appear in 1994-95) had to implement their own configuration systems. This article will only look at two systems: the ANT Internet Suite and the tools built into Boot/Configure on RISC OS 3.7/4.0.
Firstly, it is critically important that you use one or the other: the ANT Suite or the RISC OS Configure tools (double-click Boot, then click Network). If you are going to use the ANT Internet Suite, you must disable the �TCP/IP protocol suite� with the RISC OS Configure tools. The situation is described by figure 7.
Fig. 7 - The relationship between the ANT Suite and RISC OS Configure
Ideally, you should have your computer set to run the InetSuite application when it starts up (use the 'Boot', 'Run' feature in RISC OS 4's Configure or manually add a line to your boot sequence). This way your network stack will always be correctly configured and ready for use. If you use RISC OS Configure, this is done for you.
Both the ANT Suite and RISC OS Configure will load up the basic modules (Internet and MBufManager), some extras such as Acorn Access (if enabled) and network interface drivers that you configure. The ANT Suite also includes functionality for handling temporary dial-up modem connections to the Internet, so it will configure a suitable PPP interface as it needs to. Products like R-Comp's DialUp provide similar functionality for systems set up with RISC OS Configure.
Incidentally, I would also recommend that users of R-Comp's DialUp also run it during their boot sequence. It is completely compatible with the RISC OS Configure system, so you must set up your Ethernet card with RISC OS Configure, and your modem with DialUp. Usage of DialUp will not affect the Ethernet side of things, which is nice sociable behaviour.
A point worth noting is that RISCOS Ltd. have now acquired the rights to develop and market the ANT Internet Suite, under the name 'RISC OS Internet Suite' (apart from Fresco, which will remain at version 2.13). I would imagine that future versions of RISC OS will have a neat combination of the Suite and Configure, which would clean up the current complications! However, when this will happen remains to be seen.
A practical example
Fig. 8 - A simple two-computer network
Consider the rather typical figure 8. Supposing that the RISC PC has the ANT Internet Suite installed (and configured to run at boot-up) and the A7000 has the RISC OS Configure tools (part of it's copy of RISC OS 4). We will see how to use these packages to configure the network correctly and enable Acorn Access (see last month).
RISC PC configuration (ANT Internet Suite)
The ANT Internet Suite is already installed and configured for modem use, since it is mainly used to connect the RISC PC to the Internet. This all works OK. We are going to modify the configuration.
The first thing is to ensure we are compliant with figure 7. Open the root directory of your main hard disc. Run Boot and click Network. Click AUN and ensure it is not enabled. Click Access and ensure it is enabled. Click Internet and ensure 'TCP/IP Protocol Suite' is not enabled (the ANT Suite does this bit for us).
Open the Internet Suite panel and double-click Configuration. Enable the 'LAN (Local Area Network)' option and click on 'LAN setup'. Enter the details as illustrated in figure 9 and click 'Save'. Note that you do not tick the 'Use AUN/Access' option.
Fig. 9 - Configuring the RISC PC Ethernet card with the ANT Suite
Open the file !InetSuite.Internet.Files.Hosts (this is the hosts database) with a text editor and add in the lines for riscpc and a7000 as shown in figure 10:
Fig. 10 - Editing the hosts database for the ANT Suite
If you re-boot your computer, InetSuite should automatically load and configure your network interface. You can view the interface configuration by pressing CTRL-F12 and typing: *IfConfig -a
A7000 configuration (RISC OS Configure)
Open the root directory of your main hard disc. Run Boot and click Network. Click AUN and ensure it is not enabled. Click Access and ensure it is enabled. Click Internet and ensure 'TCP/IP Protocol Suite' is enabled.
In the 'Host names' subsection, click 'Hosts file...' and the hosts database will open in your text editor. Edit this in the same way as for the ANT Suite on the RISC PC (see figure 10) so it includes the IP addresses for riscpc and a7000.
For the Interfaces, Routing and Host names subsections, fill them in as shown in figure 11:
Fig. 11 - Internet configuration with RISC OS Configure
If you re-boot your computer, the boot sequence should automatically load and configure your network interface. You can view the interface configuration by pressing CTRL-F12 and typing: *IfConfig -a
Testing TCP/IP communication
To check that both computers can communicate with TCP/IP across the network, there is an utility called Ping. It sends a small amount of test data to a computer and waits for a 'successfully received' acknowledgement. The ANT Suite comes with a couple of fancy front-ends for this: Ping and Ping+, but a standard RISC OS system just has a command line utility.
On the RISC PC, open the ANT Suite panel, click Tools, and double-click Ping. Enter 'a7000' in the 'Remote host' field and click 'Ping'. It should report 'OK, reply n secs' (where n is the time taken for the acknowledgement to be received). You can also investigate Ping+.
On the A7000, press CTRL-F12 and type 'ping riscpc'. You should get some output showing the time taken for the acknowledgement to be received. It may loop for ever, so you might have to press ESCAPE to stop it. You can type 'ping' on it's own, which shows the usage pattern for the utility - feel free to experiment!
If the pings fail, check the configuration on both systems. Try using the IP addresses instead of the host names - you could have made an error editing the hosts databases.
You can also try using Acorn Access to share files and/or printers (as discussed last time). This will work with your TCP/IP configuration.
More complex configurations
You may want to connect your computer to an existing TCP/IP network. This is no different - just ask for the configuration information from whoever looks after the network (correct IP address, netmask etc.) and input that. This kind of activity raises another method of network interface configuration! There are two popular mechanisms which allow your computer to ask a network server for it�s configuration: BootP (Boot Protocol) and DHCP (Dynamic Host Configuration Protocol). Obviously, getting such information from a server removes the need for manual configuration on the client side, rather like DNS.
It is possible to use BootP with RISC OS (either with RISC OS Configure or the ANT Suite). You need to have the �IfRConfig� (Interface Remote Configure) program available in your $.!Boot.Resources.!Internet.bin (RISC OS Configure) or !InetSuite.Internet.Bin (ANT Suite) directory. Some copies of the Internet/InetSuite application have this program present and some do not - check your copy. If IfRConfig is seen by the ANT Suite or RISC OS Configure, an option to select �BootP� for your IP address will appear. This means your IP address will be requested from a BootP server rather than being manually entered by you. The BootP server must have an entry in it�s database for your Ethernet card (it�s unique hardware address) and it�s associated IP address.
DHCP is only available to RISC OS users with an Ethernet card containing a TopCat boot ROM (see: http://www.microlynx.co.uk/client.htm). These boot ROMs provide a special configuration command which allows your computer to request an IP address from a DHCP server when it boots up. The RISC OS Select subscription scheme aims to deliver DHCP as part of RISC OS 4+ at some point in the future. However, as with the rest of the Select scheme, there are no timescales set in stone. On the positive side, a DHCP server can often be configured to also recognise BootP requests, so the RISC OS BootP software may suffice. Try it!
There are also some RISC OS specific ways of automatically configuring an interface, which are especially handy for discless clients (e.g. A7000 'Net' machines). These will be discussed in a later article.
At this point, you have a fully functional TCP/IP connection between the two computers. It is possible to do more exotic things such as running a web server on the RISC PC and a browser on the A7000 will be able to access the pages over the network. Other computers (Windows PCs, Macintoshes, Unix workstations etc.) can be connected in a similar way. These activities will be explained in greater detail in future articles.
Signing off
That concludes our first look at TCP/IP and it's configuration with RISC OS. As usual, please get in touch with The Editor or myself if you want to make suggestions or raise queries regarding this series.
Richard Walker