Configuration

This chapter covers the following topics:

Introduction

Before you begin...

You'll now 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 (indicated chapters are from TCP/IP Network Administration):

In order to:Refer to:
Select the IP address of each hostChapters 1 to 4
Determine conventions for naming hostsChapters 1 to 4
Identify accessibility to local and remote serversChapters 1 to 4
Determine the availability of “default” gateways to other networksChapter 7
Decide if you need to use TCP/IP subnetsChapters 1 to 4
Decide if you need to use Domain Name ServersChapter 8

Please also note that if you:

The QNX approach

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!

Client vs server configurations

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.

A word about protocols

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

Logging to syslogd

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.

Configuring network hardware

In order to configure TCP/IP you need some type of networking hardware. With QNX TCP/IP, your networking choices include:

Several configuration aspects are common to all of the setups described here.

General setup procedure

To configure your machine to be a client on an Ethernet, Token Ring, or FDDI network, follow these steps:

  1. Configure the network adapter as described in the QNX Installation & Configuration guide. This involves bringing up Net and Net.driver. If Net isn't configured before Socket is started, then Socket won't be able to access the network.
  2. Bring up Socket. The only argument you must pass to Socket is a canonical name for the host. For example:

    Socket mymachine &
    

    Typically the string mymachine comes from the /etc/hosts file.

  3. Once Socket is running, configure your interfaces using the ifconfig command. For example:

    ifconfig en1 192.9.200.1
    ifconfig lo0 localhost
    

    In the above example, the identifier en1 refers to an Ethernet interface on logical LAN 1 in a QNX network.

    For setups involving two QNX machines, it's easiest to configure QNX networking first.

Summary of interface IDs

The following table gives the QNX LAN interface IDs for the various hardware protocols supported:

For this protocolUse this interface:
Ethernetenx
FDDIfddix
PPPpppx
SLIPslx
Token Ringtrx

The value of x is simply the logical LAN running the selected hardware (i.e. the argument of the -l option to the Net.driver or the index of the PPP or SLIP device). For more information, see the man page for the Net.driver in the QNX Utilities Reference.

Setting up a SLIP serial link

There are two ways to connect to a SLIP server:

  • via sliplogin
  • via slattach

For both of these methods, we assume that Socket is started with the -s1 parameter. This creates the sl0 (first SLIP) device.

The sliplogin method

Compared to slattach, the sliplogin utility provides a more transparent method of setting up SLIP interfaces — it doesn't need to be told which specific device to use.

The sliplogin method is preferred, but to take advantage of it you must first specify correct information in your configuration files.

Let's look at an example. We'll assume the following files exist on your home and work machines.

/etc/passwd

#/etc/passwd -- home machine
Swork::102:100:Paul Slip:/home/pk:/etc/sliplogin

#/etc/passwd -- work machine
Shome::103:100:Paul Slip:/home/pk:/etc/sliplogin

/etc/hosts

# Host Database
127.1               localhost 
192.168.200.202     sliphome
192.168.200.200     slipwork

/etc/slip.hosts


# login  local-addr  remote-addr  mask           opt1     opt2

Swork    sliphome    slipwork     255.255.255.0  compress
Shome    slipwork    sliphome     255.255.255.0  compress

slip.login script

#!/bin/sh - This '/etc/slip.login' script is launched by
# sliplogin
#
#   slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#

/etc/ifconfig sl$1 $4 $5 netmask $6  
exit 0

To establish a SLIP connection from work to home:

  1. Dial up using qtalk, then log in as Swork:

    qtalk -m /dev/ser1
    ...
    login: Swork
    

    This login invokes /etc/sliplogin Swork (from the password file), which will configure the line (i.e. slattach ttyname baudrate) and invoke the shell script slip.login.

  2. Press Ctrl-A, then type x to exit qtalk without hanging up. If you do this, you'll need to make sure that -hupcl is set on the serial port. See stty in the QNX Utilities Reference for more information.
  3. Configure the local side. Assuming the above configuration, enter:

    sliplogin Shome </dev/ser1

If you want to talk to the network on the other side of a point-to-point link, see the sections on routing and debugging for more information.

The slattach method

To establish the SLIP connection between your machine and the server you could use slattach. This involves typing commands on both ends of the connection. In these examples, slipserv is the server and home is your machine — both are defined in the /etc/hosts file on both hosts. Note that instead of an alphanumeric name, you can use an IP address (e.g. 192.168.200.202)

Assuming both hosts are using /dev/ser1 and the serial connection is established, enter these commands on the server:

/etc/slattach /dev/ser1 38400
/etc/ifconfig sl0 slipserv home up

On your machine, enter these commands:

/etc/slattach /dev/ser1 38400
/etc/ifconfig sl0 home slipserv up

You can easily establish a serial connection by using qtalk and exiting without hanging up the line. For details, see the sliplogin man page in this manual or the qtalk man page in the QNX Utilities Reference.

To ensure that the line won't be hung up, use the stty utility to set the hupcl line control parameter off on both serial ports:

stty -hupcl

For more information, see the stty man page in the QNX Utilities Reference.

Setting up a PPP serial link

PPP (Point-to-Point Protocol) is a link-level protocol used to transport IP packets over point-to-point media (usually a serial/telephone line). PPP is more flexible and is becoming more popular than SLIP.

Setting up QNX PPP

To use PPP under QNX, you need to start the Socket manager with the -p option. You'll also need a serial device such as /dev/ser1 (which is typically managed by Dev.ser). And you'll need to start pppd with the appropriate configuration, which depends on what you're trying to accomplish and the security measures you want enforced.

PPP options and negotiations

PPP has a well-defined set of defaults, designed to work for various platforms. Although these defaults will always work, sometimes you'll want to stray from the defaults to increase performance or add security measures.

When a PPP link is initiated, each side of the link gets the opportunity to tell the other side of its capabilities and requirements, which are one way only. (For example, if server A tells client B it needs authentication, and client B agrees, then client B needs to authenticate itself to server A. But server A doesn't need to authenticate itself to client B.)

Either side has the opportunity to refuse the peer, and sometimes negotiations will fail. Depending on what option failed negotiation, the line might be dropped and the link terminated (usually this occurs only with authentication options or negotiating IP addresses).

To diagnose which option is causing the problem, run pppd with the debug option. The pppd daemon will send messages that usually indicate the point of failure to the syslogd daemon. Look for “ConRej” (configure reject) messages that contain the rejected option. Also look for “TermReq” (terminate request) messages to determine which side initiated the termination.

Here's an example from a logfile:

... pppd[6706]: sent [LCP ConfReq id=0x1 <mru 1500> <auth upap> ...]
... pppd[6706]: rcvd [LCP ConfRej id=0x1 <auth upap>]

This shows that the local pppd wants to use PAP (upap) but the remote side refused.

Note that you can specify options on the pppd command line as well as in configuration files (/etc/ppp/options; ~/.ppprc).

Example PPP configurations

For these examples, we assume that:

  • all commands will be executed with root privileges.
  • all pppd options are issued on the command line (i.e. no configuration files are present).

You'll find four examples here, presented in order of complexity:

  1. NULL-modem configuration — basic configuration
  2. client configuration — connecting to an ISP
  3. server configuration — servicing clients
  4. authentication — using PAP/CHAP and a “secrets” file

Note that since PPP is commonly used to connect to an ISP (Internet service provider), you may find Example #2 the most useful.

Example #1 — QNX-QNX via NULL-modem cable

The purpose of this example is to demonstrate some of the basic concepts of PPP while keeping the configuration simplified. In this example, we have two QNX nodes connected via a NULL-modem cable on /dev/ser1. Each node is running Socklet -p1, with hostnames of node1 (10.0.0.1) and node2 (10.0.0.2). Interface lo0 and optional interface en1 have already been configured using /usr/ucb/ifconfig.

To make sure the two nodes are talking the same dialect, run the following on both nodes:

stty baud=115200 bits=8 stopb=1 par=none +raw < /dev/ser1

Now, on both nodes at the same time, run the following command:

/usr/ucb/pppd /dev/ser1

Wait a couple seconds for the link to be established.

At this point, run:

/usr/ucb/netstat -in

The output from node1 should look like this:


Name  Mtu   Network   Address     Ipkts  Ierrs  Opkts  Oerrs  Coll
en1   1500  <Link>                  699      0      1      0     0
en1   1500  10        10.0.0.1      699      0      1      0     0
ppp0  1500  <Link>                    4      0      6      0     0
ppp0  1500  10        10.0.0.1        4      0      6      0     0
lo0   1536  <Link>                   16      0     16      0     0
lo0   1536  127       127.0.0.1      16      0     16      0     0

Note that the ppp0 interface is now configured with the same IP address as the en1 interface. This is because neither side specified IP addresses to negotiate — each side chose the default, which is the IP address of the hostname specified on the Socket command line. In this example, Socket was started as:

/usr/ucb/Socket -p1 node1 &

where node1 is defined in /etc/hosts as: 10.0.0.1 node1.

Usually, the server side (the side that answers the phone) will negotiate both IP addresses of the PPP link.

Now, node1 will be able to ping 10.0.0.2 using the PPP link.

Example #2 — QNX as a client

This example is useful in demonstrating how to connect to a typical ISP over a telephone line. We assume you're using a modem connected to /dev/ser1.

Before trying to connect to an ISP, you'll need the following information:

  • ISP telephone number (and how to initiate a PPP session).
  • ISP IP address (optional)
  • DNS IP address (optional)
  • serial line configuration (parity, number of bits, etc.)

If you know your ISP is going to provide Domain Name Service (DNS) for you (it most likely will), put the supplied IP address in your /etc/resolv.conf file. For example, the contents of /etc/resolv.conf when the ISP IP = 198.53.31.1 would be:

nameserver 198.53.31.1

If you'll always be assigned the same IP address (most likely not), you could enter that in your /etc/hosts file and use the associated name to start up Socklet.

To connect to the ISP:

  1. Using the stty command, set up the /dev/ser1 device so that both ends are talking the same dialect. For example:
    /bin/stty baud=115200 bits=8 stopb=1 par=none -hupcl +raw < /dev/ser1
    
  2. Start up Socket with -p and the appropriate hostname. For example:
    /usr/ucb/Socket -p1 node1 &
    
  3. Configure your loopback address. For example:
    /usr/ucb/ifconfig lo0 127.0.0.1
    
  4. Phone the ISP using qtalk. Once connected, the ISP usually (but not always — each is different) offers a login prompt or some kind of menu to indicate what kind of service you want. This may be a regular login session, a SLIP session, or a PPP session.

    Once the ISP knows what service you want, quit qtalk using Ctrl-A to get to the menu and x to exit without dropping the line.

  5. Now simply run:
    /usr/ucb/pppd defaultroute /dev/ser1
    

    and wait a couple seconds for the link to be established. The defaultroute option tells pppd to set up a default route out the connection it establishes. See the routing section for more information.

Using the netstat/ifconfig commands, you can find out what IP addresses were assigned to either end of the link. You should also be able to ping the remote end at this point.

Example #3 — QNX as a server

This example shows how to configure PPP to answer the phone and allow clients to make a connection. As the server, there's a lot more to consider when deciding which configuration is best for your situation. And such configuration requires a better understanding of the “administration” aspects of QNX.

We assume that you're familiar with:

  • maintaining user accounts
  • the tinit and modem utilities
  • the /etc/sysinit file

The first step is to get your system to answer the phone line when it rings. This is usually done with the tinit and modem commands. For example:

tinit -c /bin/modem -T /dev/ser1 

By default, the modem process will start the login process. This will require the client to login successfully (adding a layer of authentication) before initiating the PPP link. Another benefit of the login procedure is that you can multiplex the phone line — it can service both regular login sessions as well as PPP sessions. All you need is to set up two user accounts:

  • a regular account
  • an account that will use pppd as the login shell.

For example, an /etc/passwd file might contain these two lines:

user1:x:315:300:User1 FullName:/home/user1:/bin/sh
pppuser1:x:415:300:User1 FullName:/home/user1:/usr/ucb/pppd

The client would login as user1 when he wanted a regular login session, or as pppuser1 when he wanted a PPP session.

The client would need to know the appropriate passwords (if any) that will usually suffice for authentication. However, if such a client will be granted access to confidential material, you might consider using an authentication protocol (see Example #4 below).

If you choose, you don't need to run login when a client connects. You can have pppd start immediately by changing the default of the modem utility. For example:

tinit -c "/bin/modem -c /usr/ucb/pppd" -T /dev/ser1 

Either method will work as long as the client knows what he must do to initiate the PPP link.

The next issue to be considered is the matter of IP addresses. Usually the server is responsible for assigning the address of both ends of the PPP link. The reasoning behind this is that the client becomes part of the same network as the server. This will allow the client to use the server's name and routing services.

In assigning IP addresses, the server's local PPP address is almost always assigned the same as its hostname's IP address. The address to be concerned about is the one assigned to the client's PPP interface. This address should be on the same IP network as that of the server's hostname's IP address.

For example, if the server accesses a router (or whatever to get Internet access) through interface en1 with IP address of 198.34.5.67, it should assign a remote PPP IP address (the client's local PPP IP address) belonging to IP network 198.34.5.

It's important to keep the client's IP address within the server's IP network because the server will typically need to become a proxy ARP server for the client. To clarify this, let's walk through a simple scenario:

  1. The client establishes a PPP link. Its local PPP IP address is 10.0.0.5 and the server's en1 IP address is 10.0.0.1. The IP address of the router that the server uses is 10.0.0.100.
  2. The client runs the ping command, and the ping request goes out its PPP interface because the client has set up a default route through it.
  3. The server sees the ping request, determines it's destined for another host, and forwards it to the router.
  4. Eventually, the ping request reaches the destination and is replied to. When back tracking, the ping reply makes it back to the router.
  5. The router examines the reply destination and notices that it's on the same IP network as its 10.0.0.100 interface. Because it's on the same IP network, the router assumes it has direct access to that address (i.e. no routing or forwarding should be necessary to reach that IP address). The router then issues an ARP request for IP address 10.0.0.5.
  6. The server, acting as a proxy-server for the client, will respond to the ARP request specifying its own MAC address. This will cause the router to send the ping reply to the MAC address of the server, with a destination of 10.0.0.5. The server will then see this packet (because it was sent to its MAC address) and forward it to the destination — the client's PPP IP address.

To act as a proxy-server for the client, the server simply specifies the proxyarp option to pppd. For example, the pppd command line for the above scenario would look like this:

/usr/ucb/pppd proxyarp 10.0.0.1:10.0.0.5 /dev/ser1

Example #4 — Authentication

The QNX PPP supports two authentication protocols:

  • Password Authentication Protocol (PAP)
  • Challenge-Handshake Authentication Protocol (CHAP)

PAP is widely considered less secure than CHAP. PAP authenticates once at startup, whereas CHAP randomly “challenges” the peer for authentication as long as the link is up.

Both protocols are configured using a secrets file:

  • /etc/ppp/pap-secrets (PAP secrets file)
  • /etc/ppp/chap-secrets (CHAP secrets file)

Both secrets files are of the same format, which specifies one entry per line, with each entry made of at least three fields:

This field:Indicates:
firstthe client (or authenticatee)
secondthe server (or authenticator)
thirdthe secret

The rest of the line can be an optional list (comma-separated) of IP addresses. The client/server fields are used to scan for a secret, which will be compared against what the peer offers as its secret.

For example, here's an authentication entry shared by both pppclient and pppserver:

pppclient  pppserver  pppsecret

By default, when the authenticator scans the secrets file for a secret, it looks for a match between its hostname and an entry's second field. At the time of this scanning, the client's name is not known. If the secrets file is ambiguous (because it specifies several secrets for several clients), you may need to specify the remotename option to pppd. This will cause the scan to match both the client and server fields, ensuring the proper secret is selected.

For example, when pppserver scans its secrets file, it just looks for its hostname (pppserver) in the second field of each entry. If there are multiple entries with “pppserver” in the second field, you may need to pass the remotename option so the scan will also require a match of remotename (in this case “pppclient”) in the first field.

The authenticatee scans the secrets file in the same manner as the authenticator, except that it matches its hostname with the first field of each entry, and the optional remotename option with the second field.

In both the client and server side, you can specify the “other side” using the remotename option. Likewise, you can specify the “local side” (which defaults to the hostname) by using the name option to pppd. This option is usually needed only when multiple users use the same host as client (or when using PAP with the login option).

By default, pppd won't require the peer to authenticate itself, but will be ready to authenticate itself to the peer (if it has access to secrets files). Using either (but you can't use both!) the +pap or +chap options to pppd will require the remote side to authenticate itself. Usually, only the server (the side that answers the phone) will ask for authentication, but under certain circumstances, you might want both the server and client to require the peer to authenticate itself. Furthermore, each side may use a different protocol — the server may require CHAP, while the client may require PAP.

Let's assume the server is called pppserver and the client is called pppclient and that only the server is requesting authentication. Both the server's and the client's secrets file will need to contain at least the following entry:

pppclient  pppserver  secret1

Both the server and client will scan the secrets file and will use the “secret1” secret.

If both the server and client request authentication, another entry (in the appropriate secrets file — remember one may request CHAP, the other may request PAP) will be needed to describe the other secret. For example:

pppserver  pppclient  secret2

Again, when dealing with multiple clients/servers, you may need to specify either the remotename or name option (or both) to pppd to get rid of any ambiguity when selecting the secret.

Note that you can request PAP authentication without having a secrets file by specifying the login option to pppd. With this option, the client name and secret represent a user account and password in the system password database. From the above example, a user account of pppclient with a password of secret1 must exist on the server side for authentication to succeed.

If a pap-secrets file exists when using the login option, a match must exist in the pap-secrets file before the system database is checked.

Using the login option requires at least one side to keep a text-based user:passwd combination, which might be considered a security breach in itself!

Routing

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:

  • minimal routing — if you're isolated on your own network (single piece of wire), then it's unlikely you'll need to do anything to route packets.
  • static routing — if you're on a network with a small (and static over time) number of gateways, then you can use the route command to configure the routing tables within Socket and leave them that way. This is a very common configuration.
  • dynamic routing — if you're on a network with more then one possible route to the same destination on your network, then you might need to use dynamic routing. This relies on routing protocols to distribute information about the changing state of the network. If you need to react to these changes, then you need to run routed or gated.

There's often confusion between routing and routing protocols. Routing is done by Socket via routing tables; routing protocols allow those tables to change.

Debugging

Utilities for debugging

Several utilities are useful for debugging TCP/IP configurations:

When you want to:Use this utility:
Ascertain connectivity between hostsping
Get status of Socket configurationnetstat and route
Configure and query interfacesifconfig
Get reports on route and delays through networktraceroute
Configure and query hardware-to-protocol address translationarp
Lookup the translation of alphanumeric names to IP addressesnslookup

ping

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:

  • If nothing is displayed, ping may be having problems resolving the hostname. Try the IP address directly to bypass the resolver (see the /etc/resolv.conf file).
  • If only the first line of the above successful output is displayed, then ping isn't receiving a response from the specified host.
  • All other problems and errors will output an obvious message (e.g. “No route to host”).

netstat and route

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. An IP address is a 32-bit quantity usually displayed as four octets separated by dots. During routing, a gateway divides the address into two parts: the network and the host.

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.

Address mapping via arp

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.

nslookup

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.

traceroute

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.

Configuring a gateway

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 should reside on a different IP network.

Configuring TCP/IP servers

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.

Daemons

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

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:

  • ftpd — file transfer
  • rlogind — remote login
  • rshd — remote shell
  • telnetd — remote terminal session

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:
  • rlogind — remote login
  • telnetd — remote terminal session

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 &

Resident daemons

The following daemons don't need inetd to run:

  • bootpd
  • gated
  • lpd
  • named
  • routed
  • rwhod
  • smtpd

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 Chapter 5, Utilities, and Chapter 6, Files. See also TCP/IP Network Administration, which describes these daemons in detail.

Starting TCP/IP commands in /etc/netstart

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.

Optimizing your configuration

Throughout this manual we've referred to Socket as the IP manager. But QNX TCP/IP actually contains two IP managers:

  • Socket (includes NFS)
  • Socklet

Socket provides support for NFS as well as the other IP facilities we've described.

If you don't need NFS, you should use the “lighter” IP manager, Socklet, which consumes less memory.

Configuring terminals

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.