This chapter covers the following topics:
In the next three chapters, you'll learn about configuring basic TCP/IP clients, servers, and gateways. But before you begin configuration, you should plan the basic layout of your network (see previous chapter); you should also address the following issues (chapters indicated are from the 2nd edition of TCP/IP Network Administration):
| In order to: | Refer to: |
|---|---|
| Select the IP address of each host | Chapters 1 to 4 |
| Determine conventions for naming hosts | Chapters 1 to 4 |
| Identify accessibility to local and remote servers | Chapters 1 to 4 |
| Determine the availability of ``default'' gateways to other networks | Chapter 7 |
| Decide if you need to use TCP/IP subnets | Chapters 1 to 4 |
| Decide if you need to use Domain Name Servers | Chapter 8 |
Please also note that if you:
In QNX, the distinction between ``system'' and ``user'' processes is practically nonexistent. Some processes are called managers (or daemons in Unix terminology), but that's simply because they manage a specific resource and provide a service to other processes.
To configure a computer in QNX, you have to start several processes. Which processes you start depends on the services you want that computer to provide. By adding the appropriate processes to a computer's startup script file (e.g. sysinit.node), you can easily enable a computer to be a QNX workstation, a TCP/IP client, a TCP/IP server - or all three!
QNX 4.25 TCP/IP uses shared libraries. The libraries are represented by the binaries rpc_so, snmp_so, and socket_so. To run any executable (except for Socklet, Socket, and Sockppp) you must have these binaries available. They won't show up in a sin listing, but they do create entries in /dev/shmem. If you wish to remove the socket shared library (not a good idea while you're using it), use the following command:
rm /dev/shmem/socket_so
You can remove the RPC and SNMP shared libraries in the same way.
The minimal configuration of a TCP/IP host is that of a client host. To transform a client into a server, you simply add the desired server daemons to that client's configuration.
Since client and server configurations can be performed in isolation, we describe them separately here. This structure will help you configure any host as a client and then subsequently add server capabilities as required.
The name ``TCP/IP'' implies two main protocols - TCP and IP - in a suite of many protocols.
IP is the main protocol upon which most protocols are layered. In order to use TCP/IP you need an IP address. You normally get your IP address from an ISP (Internet Service Provider), directly from the InterNIC, or from your MIS department.
|
To find out where to go on the Internet for IP addresses, see Appendix B: ``Useful Internet Contacts.'' |
If you're setting up a network that is separated from any other machines, then you can use the IP address 192.9.200.x, where x is a number in the range 1 to 254. Many QNX users give the logical node ID as the suffix for the IP address (e.g. node 15 might be 192.9.200.15).
The simple way to map between alphanumeric names (e.g. qnx.com) and IP addresses is via a table kept in the /etc/hosts file. This works fine for small to medium networks. If you think this is getting unwieldy for your network, then you should read the chapter on DNS (Domain Name Service) in TCP/IP Network Administration.
Note that many of the following sample configurations make some assumptions about routing, which can be defined as the act of choosing how to get a packet to its destination. See the ``Routing'' section in this chapter.
Quite often the series of commands you need to start up the TCP/IP aspects of networking are gathered together in the script /etc/netstart. The runtime product includes an example script. Once you work out your specific needs, you should modify that script accordingly. If you have multiple workstations sharing /etc (via QNX networking) and they each have different TCP/IP needs, it's customary to name the various scripts /etc/netstart.node.
If you have several TCP/IP hosts/servers on a QNX network, you can select which one you use by setting the environment variable SOCK to the node number of the Socket Manager you wish to use.
export SOCK=1 #use the Socket on node 1
Many TCP/IP programs produce logging or debugging information. For example, sendmail logs a message whenever it processes incoming or outgoing mail. By examining this type of information, you can verify that local host programs are operating correctly.
While some programs write this type of information to standard output or standard error, many will send supplementary status information to syslogd, if it's running. In certain circumstances, logging might also go to the /dev/console file.
Since the /dev/console file doesn't exist in a default QNX system, you may need to execute the following command:
prefix -A /dev/console=file
The file argument is the device or file you want to use as your log device. For example, if file is /dev/con1, logging goes to console 1. But if file is /tmp/logfile, the output goes to /tmp/logfile on disk.
Routing is the act of determining how to get a packet to its intended destination.
|
You should supplement the brief overview of routing given here with the detailed treatment found in Hunt's TCP/IP Network Administration. |
There are really three general categories of routing:
|
Although gated isn't shipped with the TCP/IP implementation, you'll find a free (unsupported) version in the TCP/IP area on QUICS. |
There's often confusion between routing and routing protocols. Routing is done by Socket via routing tables; routing protocols allow those tables to change.
Several utilities are useful for debugging TCP/IP configurations:
| When you want to: | Use this utility: |
|---|---|
| Ascertain connectivity between hosts | ping |
| Get status of Socket configuration | netstat and route |
| Configure and query interfaces | ifconfig |
| Get reports on route and delays through network | traceroute |
| Configure and query hardware-to-protocol address translation | arp |
| Look up the translation of alphanumeric names to IP addresses | nslookup |
You use the ping utility to determine if you have connectivity to other hosts. Suppose you've configured a point-to-point link (SLIP or PPP), but you haven't specified a default route. You can type:
ping isp.com
to see if you're connected to the other end of the link.
With success, ping will output something like this:
PING isp.com (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=0 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=255 time=0 ms
This report will continue until ping is terminated. To terminate ping, press Ctrl -C . You'll see a report like this:
--- isp.com ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms
The ping utility may fail for different reasons:
A common problem involves configuring a PPP interface correctly. Assume that the user has established the connection using pppd. Now the user can ping the machine he's dialed into (isp.com), but not anything past it (e.g. the Internet). The user's routing tables (from netstat -rn) look like this:
Routing tables Destination Gateway Flags Refs Use Interface Route Tree for Protocol Family 2: (root node) 127.0.0.1 127.0.0.1 UH 1 0 lo0 10.0.0.1 10.0.0.101 UH 2 10 ppp0 (root node)
Note that the user has a route to isp.com (10.0.0.1) and to localhost. What the user really needs is a route to ``anywhere he doesn't have in his list.'' This is called the default route. It can be automatically added via the defaultroute option to pppd, but can also be added later via the route utility (e.g. route add default isp.com).
In other cases the need for a route isn't so obvious to see. Suppose your machine has two interfaces. Which interface does a packet take? Here's the output of netstat -rn and netstat -in on such a machine:
Routing tables Destination Gateway Flags Refs Use Interface Route Tree for Protocol Family 2: (root node) 10 10.0.0.249 U 2 82 en2 10.8 10.8.0.249 U 1 0 en9 127.0.0.1 127.0.0.1 UH 2 7 lo0 (root node) Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en2 1500 <Link> 6 0 1 0 0 en2 1500 10 10.0.0.249 6 0 1 0 0 en9 1500 <Link> 0 0 1 0 0 en9 1500 10.8 10.8.0.249 0 0 1 0 0 sl0* 296 <Link> 0 0 0 0 0 ppp0* 1500 <Link> 0 0 0 0 0 lo0 1536 <Link> 89 0 89 0 0 lo0 1536 127 127.0.0.1 89 0 89 0 0
What are some of the things this output tells us? The line under (root node) tells us that packets bound for network 10 will go out the en2 interface. The line below that tells us that packets bound for network 10.8 will go out the en9 interface.
What's the difference between network 10 and network 10.8? The answer lies in the IP address and in something called a netmask. During routing, a gateway divides the address into two parts (the network and the host) using the netmask.
The network part is used to determine how to route a packet until it has reached its own network, at which point the host address is used.
To find the netmask for an interface, we need to use the command ifconfig en9, which gives this output:
en9: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
inet 10.8.0.249 netmask ffff0000 broadcast 10.8.255.255
This tells us that the netmask for en9 is ffff0000.
Similarly, we find that en2 has the netmask ff000000. So, how do we determine what interface a packet bound for 10.0.0.5 will take? We look down the routing table for the longest match.
If we ``bitwise and'' 10.0.0.5 with the 10 netmask (255.0.0.0), we see that the network portion lines up with the entry in the table. Thus the packet will go out the en2 interface. If we then look at a packet bound for 10.8.0.67, we find that 10.8 is the longest match and that we'll use en9. If we then look at a packet bound for 10.2.0.5, we pick en2 since it's the longest match.
Throughout this manual we've been working with IP addresses. But at the hardware level, networking hardware uses other types of addresses. For point-to-point links it's just ``the other end.'' For common access network media like Ethernet, it's some other type of address (a 48-bit number called a MAC address). Since IP addresses are 32-bit, we can see that there must be some sort of mapping between IP and MAC addresses. This could be held in a database like /etc/hosts, but that would make it hard to add a new machine to the network.
To handle address mapping, IP uses Address Resolution Protocol (ARP). If you have an interface directly on the network of the packet, then you can send out an arp request to find the full hardware address of that host.
If you get an answer back, then you can store that in a cache and continue with your network transaction. Later communications will only cost you a cache lookup, not a whole network transaction. If you don't talk to a host for a while, you can purge that entry from the cache.
If the destination isn't directly connected to your network - and you have a route to its network - then you can look up the address of the gateway (host that relays packets onto another network) for that destination and ARP for it. If you get an answer back, then you can continue with your network transaction sending the packet intended for the destination to the gateway instead.
This is all to introduce a simple little utility called arp, which lets the user list and manipulate the ARP cache. You can use arp to set up proxy arp, which is where you answer the ARP request for another host (possible on a SLIP or PPP link), thus providing a limited form of routing.
You can also use arp to identify when you've got the wrong address for a host. Options to arp let you list, delete, and set entries in the cache.
Both arp and netstat are fine tools for looking at routing on your local network, but they're not very good for examining what's going on across the network. You'll find nslookup and traceroute useful for this.
The nslookup utility lets you query the DNS database. For example, when you enter nslookup vir.com, you'll get:
Server: qnx.com Address: 198.53.31.1 Aliases: quics.qnx.com Non-authoritative answer: Name: vir.com Address: 199.84.154.69
This tells us that qnx.com thinks vir.com has the address 199.84.154.69. You can also ask what another host thinks a third host's address is. The command:
nslookup neocom.com vir.com
gives us:
Server: Zotique.Vir.com Address: 199.84.154.69 Non-authoritative answer: Name: neocom.com Address: 165.90.128.240
This tells us that vir.com thinks neocom.com is at 165.90.128.240. We can then ask man.net where neocom.com is by entering:
nslookup neocom.com man.net
This gives us:
Server: mars.man.net Address: 198.53.163.2 Non-authoritative answer: Name: neocom.com Address: 165.90.128.240
This tells us that at least these two hosts have a common view of where neocom.com is. This only hints at how useful nslookup can be. The utility allows you to find out what a certain host's MX records are, what their nameservers are, and all sorts of other information.
The traceroute utility lets you find out information about the route your packets take to a certain host. The utility takes the destination host as one of its arguments. The output of traceroute vir.com looks like this:
traceroute to vir.com (199.84.154.69), 30 hops max, 38 byte packets 1 cisco (198.53.31.2) 10 ms 10 ms 10 ms 2 border1.ottawa.istar.net (198.53.65.249) 10 ms 20 ms 20 ms 3 core1.ottawa.istar.net (198.53.250.10) 20 ms 20 ms 20 ms 4 core1.montreal.istar.net (198.53.254.57) 20 ms 20 ms 10 ms 5 core1.toronto.istar.net (198.53.254.61) 20 ms 20 ms 20 ms 6 border1.toronto.istar.net (198.53.252.1) 20 ms 20 ms 30 ms 7 border1.newyork.istar.net (198.53.254.13) 110 ms 90 ms 60 ms 8 te1.cnss36.New-York.t3.ans.net (192.103.63.5) 60 ms 60 ms 60 ms 9 mf0.cnss32.New-York.t3.ans.net (140.222.32.222) 60 ms 50 ms 80 ms 10 cnss40.New-York.t3.ans.net (204.149.4.8) 140 ms 130 ms 120 ms 11 t3.New-York-Mtl.t3.ans.net (198.168.57.25) 110 ms 120 ms 80 ms 12 ns.InterLink.NET (198.168.73.8) 130 ms * 90 ms 13 T1.Mtl.VIR.COM (198.168.92.73) 140 ms 120 ms 100 ms 14 Zotique.Vir.com (199.84.154.69) 120 ms 140 ms 140 ms
So what does this tell us? To go from the cisco at qnx.com in Ottawa to Zotique.Vir.com in Montreal takes 14 hops. The three times printed are for three probes sent to that site. An asterisk (*) is printed if the probe is lost.
If this data showed a bottleneck along the way, then it could be used to choose a better Internet provider or to look for a mirror of whatever service the destination provides.
To enable the host to act as a gateway (a machine that forwards packets between interfaces), specify the -d forward option to Socket:
Socket -d forward hostname &
With this option, data packets will be routed from one network to another. Note that each interface must reside on a different IP network.
We've covered the processes that constitute a basic client host. In this section, you'll learn about what's required to add server capabilities to a client host.
What does being a server mean? If a host is a server, it will invoke the appropriate daemon to satisfy a client's request. Note that most TCP/IP daemons have names ending with the letter ``d.''
A TCP/IP server typically runs the inetd daemon (also known as the ``super-server'').
The inetd daemon listens on the TCP/IP network for incoming client requests. Upon receiving a request, it executes the corresponding server daemon. For example, if a client requested an rlogin, then inetd would start rlogind (remote login daemon) to satisfy the request. In most instances, responses to client requests are handled this way (see TCP/IP Network Administration).
You use the /etc/inetd.conf file to specify the daemons that inetd can start. The distribution contains a sample inetd.conf file that has entries for all the servers currently supported by TCP/IP for QNX, including these commonly used daemons:
Remember that you shouldn't ``manually'' start the daemon processes listed in this file - they expect to be started by inetd.
|
The following daemons require that pseudo-tty
support also be available:
To have your host provide remote login or terminal sessions, make sure that the list of boot processes for the host (e.g. /etc/config/sysinit.node) includes the pseudo tty driver: Dev.pty & |
The following daemons don't need inetd to run:
These daemons listen on their own TCP ports and manage their own transactions. They're usually started when the computer boots and they then run continuously.
For example, if a server will be used only for Internet mail, then sendmail is the only server daemon required. Or if a server will be used only for Domain Name Services (DNS), then named is the only server daemon required.
These daemon processes have their own configuration files. For more information, see the TCP/IP Utilities chapter. See also TCP/IP Network Administration, which describes these daemons in detail.
The commands specific to TCP/IP are commonly placed in the /etc/netstart file. Typically executed from a computer's sysinit.node file, the /etc/netstart file provides a handy way to restart the TCP/IP services when you're testing and debugging a site's configuration.
Here are the contents of an example netstart file:
slay -f Socket Socket -s1 node$NODE & ifconfig en1 node$NODE up ifconfig lo0 localhost up
|
The line ifconfig en1 node$NODE up assumes that
host addresses have been set up in
/etc/hosts, with entries similar to:
192.9.200.4 node4 For more info, see the chapter on Name Service Concepts in TCP/IP Network Administration. |
Because the appropriate node ID is substituted for the workstation that /etc/netstart runs on, the above example file can work on any QNX workstation.
Throughout this manual we refer to Socket as the IP manager. But QNX TCP/IP actually contains three IP managers:
So far, we've looked at the considerations involved in supporting local TCP/IP hosts. In addition to those considerations, access to remote hosts requires that you set up definitions for the remote host terminal.
To run terminal applications that communicate with remote hosts (e.g. telnet, rlogin), you must enable correct support for remote terminals.
In QNX you should take advantage of ansi terminal emulation on a QNX console (see Dev.ansi), because it's quite similar to the traditional vt100 terminal type, which is widely supported on TCP/IP hosts.
For more information on terminal emulation, see the QNX Installation & Configuration guide.