TOC PREV NEXT INDEX

QNX Logo

10 Connecting Networks

This chapter covers the following topics:

Information to be added

[Author's Comments: User query: how do I set up a n/w boot server?]

[Author's Comments: Is it necessary to use the file /etc/net.cfg? What is the syntax of this file? Is it possible to have the hostname only once (file HOSTNAME and file net.cfg)? Is it possible to have the IP address only once (file hosts and file net.cfg)?]

Introduction

All RTP installations have networking capability: a single computer running RTP can be considered a one-node network.

RTP networking is based on the idea of full availability of resources. As long as a user has the required permission, that user may access any resource that is connected to any network node (for a fuller discussion of this philosophy, see Network distribution of kernels in System Architecture). The normal permission restrictions apply across the whole network, just as if the network was one computer.

As with other QNX 6 service-providing processes, the networking services execute outside the kernel. The network architecture used allows applications to be presented with a single unified interface, regardless of the configuration and number of networks involved (for more information on the network architecture used, see Networking Architecture in System Architecture.

RTP supports a variety of network interfaces and protocols. It can make use of Ethernet interfaces and serial connections (PPP). It supports TCP/IP with two different stacks: a tiny stack (npm-ttcpip.so) and a full BSD 4.4 TCP/IP stack (npm-tcpip.so). The tiny stack is ideal for resource-constrained environments because it is so small, but it contains only a minimal set of TCP/IP functions. RTP also supports a native network QNX 6 protocol called Qnet. This protocol allows transparent networking between QNX 6 hosts. This chapter tells you how these network interfaces and protocols work and how you can use them to create and maintain your network.

First, we'll take a look at the network processes that RTP starts when you boot.

How the network manager gets started when you boot

When you boot, enumerators look for the network adapters installed on your node and then tell the node's network manager to start the device drivers and protocol interfaces appropriate for that node.

One of the system initialization scripts starts enum-devices, the device-enumerator manager (see enum-devices in Utilities Reference). This manager reads configuration files and then spawns enumerators as required to find all the devices, including buses, present on your system. The enumerators pipe information on what they find back to their manager. If a bus enumerator reports that its bus has another bus connected to it, the manager will start another bus enumerator to report on that bus and so on until all devices and buses have been identified. After verifying that the configuration files cover a particular device found, enum-devices follows whatever course of action is listed in the configuration information for that device.


There are certain configuration files provided with RTP and they are stored in the /etc/system/enum/ directory tree when you install RTP on your system. When the system initialization script (e.g. /etc/rc.d/rc.devices) calls enum-devices, it includes an option -c that tells enum-devices where to look for these configuration files.

In the case of a network device, the configuration files for network devices (stored in /etc/system/enum/devices/net) will probably require the device-enumerator manager to start a network manager utility called io-net. The configuration file will then tell enum-devices to tell io-net to load the appropriate network protocols and start the network device drivers your system requires. For a description of io-net including some examples of how it's used, see io-net in Utilities Reference.

What the network manager does

The network manager, io-net, loads shared objects (DLLs) to provide the protocols and device drivers needed by your system. For information on shared objects for specific network devices, see the devn-* documentation in Utilities Reference. For information on the shared objects for protocols, see the npm-* documentation in Utilities Reference.

Apart from loading necessary protocols and drivers, io-net also manages network traffic between the network adapters and the various loaded protocols. For information on how io-net interacts with its protocol and driver interfaces, see Networking Architecture in System Architecture.

Once io-net is started, you can find out for future reference which driver shared objects were used. To determine which shared objects are loaded by io-net, use the pidin command (see pidin in Utilities Reference): 

pidin -p 4476961 mem

where 4476961 is the pid of io-net (find this pid by running pidin with no options).

The output would look something like this: 

# pidin -p 4476961 mem
  pid  tid  name               prio STATE       code data  stack
4915233  1  o-net/x86/o/io-net 10o  SIGWAITINFO 40K  324K  8192(516K)*
4915233  2  o-net/x86/o/io-net 10o  RECEIVE     40K  324K  4096(12K)
4915233  3  o-net/x86/o/io-net 10o  RECEIVE     40K  324K  4096(12K)
4915233  4  o-net/x86/o/io-net 21r  RECEIVE     40K  324K  4096(132K)
4915233  5  o-net/x86/o/io-net 21o  RECEIVE     40K  324K  4096(132K)
4915233  6  o-net/x86/o/io-net 17f  CONDVAR     40K  324K  4096(132K)
4915233  7  o-net/x86/o/io-net 18o  RECEIVE     40K  324K  4096(12K)
4915233  8  o-net/x86/o/io-net 19f  CONDVAR     40K  324K  4096(132K)
4915233 11  o-net/x86/o/io-net 18f  CONDVAR     40K  324K  4096(132K)
          ldqnx.so.1         @b0300000        296K   12K
          devn-el900.so      @b034d000         44K  4096
          npm-tcpip.so       @b035c000        184K   44K

In this example, the driver for 3Com 90x Network Interface Cards (devn-el900.so) is loaded, along with the full TCP/IP stack (npm-tcpip.so).

Configuring a machine for network connection

Log in as root.

mount -T io-net npm-qnet.so

For more information on the Photon TCP/IP and dialup configuration tool, see phlip in Utilities Reference.

For more information on the TCP/IP Configuration Manager, see netmanager in Utilities Reference.

What can go wrong?

If you have set up a node on the network but other nodes cannot see it:

[Author's Comments: what is this network directory and where is it?]
[Author's Comments: what about the netmask?]

QNX 6 native networking

In RTP, the QNX 6 OS uses the Qnet protocol for native QNX 6 networking. Qnet lets you access QNX 6 services and resources located on one node from any other node on the network. If you wish to run Qnet, you tell the RTP network manager to load its shared object, npm-qnet.so. For technical information on:

Finding nodes on Qnet

In past QNX networks, every node had an identification number; in Qnet, each network node is identified by a pathname instead. The following description tells you how this naming convention works; for a more technical discussion on the way Qnet resolves node names, see "Name resolution and lookup" in System Architecture.

When RTP is initially installed on a stand-alone machine, the machine's node name is set to the environment variable $HOSTNAME (initially assigned as localhost or, if RTP is installed in a Windows partition, the Windows hostname).

As root, you can change the assigned hostname using the hostname utility (see Utilities Reference). Or you could change it by altering the buildfile you use to make your image: select the hostname you want to use on startup by specifying the -N option in the buildfile startup command.

For such a stand-alone machine, the node's system initialization file and other configuration files are physically located on the node's hard disk (e.g. sysinit will probably be found in the /etc/system directory).

If a node is connected to a network, however, its configuration files may be physically located on a hard disk anywhere in the network. When a node boots from the network, it may be configured using either standard generic configuration files or node-specific configuration files. Node-specific configuration files will be used if any can be found, otherwise the standard generic configuration files will be used.

Loading Qnet

You load Qnet by mounting it after io-net has started. First make sure that io-net is running (with a TCP/IP stack if you want to connect to other networks outside your LAN) and that you have a unique hostname, and then type:

mount -Tio-net npm-qnet.so

After you have mounted Qnet, you can access any resource connected to any other node on the network. E.g. to access /dev/ser1 on a node with the hostname remote-node, you would simply refer to the pathname /net/remote-node/dev/ser1.

The pathname /net looks like a real directory but really, it is a fake. It isn't a part of the file system, it is only a pathname prefix that Qnet registers with the QNX 6 process manager; it exists as a resource only as long as Qnet is running. Qnet owns the /net pathname space; when Qnet is done with it, it disappears.
 This is the way the QNX 6 process manager allocates and keeps track of all resources (for a detailed explanation of the way QNX 6 manages the pathname space, see Pathname management in System Architecture).

Qnet lets you use QNX 6 resources on the remote node just as if they were located on your own node. Suppose you work for Acme Inc. and you have a colleague called Wally; Wally's computer might have the node name wally and Acme's network domain might be acme.com. Using Qnet, the following pathname would get you to serial port 1 on Wally's computer: 

/net/wally.acme.com/dev/ser1



  
  

    
 






    
 The wally.acme.com part of this pathname is called a Fully Qualified Node Name (FQNN). The FQNN consists of the node name plus the node domain tacked together, but you don't always need the node domain part: if another node's node domain is the same as yours, you won't see its domain name in /net.

How Qnet finds other nodes

When you enter an FQNN, Qnet finds the node you are referring to using name resolution. There are three methods of name resolution you can choose from:

ndp (default)

The Node Discovery Protocol method of name resolution attempts to discover other nodes on a network dynamically. This method uses an ARP-like protocol which broadcasts node name address requests to resolve the node name to an address; all nodes on the network receive this request and the one that recognizes its own node name replies with its physical hardware address.

dns

The Domain Name Service method translates the FQNN into an IP address using the gethostbyname() function.

file

The file method searches for the FQNN in a static file which maps node names to network layer addresses; a Qnet over IP configuration file would contain entries which map node names to IP addresses.

You specify which method to use when you mount Qnet, e.g. 

mount -Tio-net -o "resolve=dns" npm-qnet.so

You can specify more than one method of name resolution. The different methods you specify will be tried in the order given. E.g. the following command will try to resolve the name using the ndp method first and, if that fails, will then try the dns method: 

mount -Tio-net -o "resolve=ndp,resolve=dns" npm-qnet.so

Selecting the network path

It is possible to have more than one network path between nodes; Qnet allows you to influence the way these paths are chosen by deciding which Quality of Service (QoS) policy will be used. The QoS policies are:

Load balanced

Load balanced delivery allows the network manager to decide which link path it uses to transmit data according to its own criteria (based on link speed and current load); this policy maximizes throughput by using the whole network bandwidth.

Redundant

Redundant delivery allows multiple copies of the data packet to be transmitted simultaneously on all available links; this policy produces a very reliable system.

Sequential

Sequential delivery allows the user to specify the order of priority in which links will be used; this allows you to use a slower backup link if the main link should fail.

Preferred

Preferred delivery is similar to sequential delivery, but falls back to load balanced delivery if the listed interfaces cannot be used.

The QoS parameter always begins with a tilde (~) character; specify which QoS to use like this:

qtalk -m/net/mary~redundant/dev/ser1

This command line expects to communicate with the modem attached to /dev/ser1 located on the node named mary using a very reliable method of transmission (for more on qtalk, see Utilities Reference).

If you want to change the QoS from redundant to sequential policy, change the command line like this: 

qtalk -m/net/mary~sequential:12.0.0.1,13.0.0.1/dev/ser1


You can use a symbolic link instead of having to remember such a long command line if you set it up like this:
 
ln -sP /net/mary~sequential:12.0.0.1,13.0.0.1 /net/marys
Now, instead of having to type:
 
qtalk -m/net/mary~sequential:12.0.0.1,13.0.0.1/dev/ser1
each time, you can just type:
 
qtalk -m/net/marys/dev/ser1
Using a symbolic link like this is also useful if something goes wrong with the node named mary: just change the link to point somewhere else, then anyone using qtalk can keep using the same path.

For more information on QoS, see System Architecture.

Configuring your network

[Author's Comments: (User query: How do I make my n/w fault-tolerant?--setting up a fault-tolerant network by using multiple boot servers (in case the primary boot server becomes inoperative).]

[Author's Comments: add something on avoiding boot bottlenecks by distributing the boot resources.)]

One network or more?

If you're setting up a small network, it will probably need only a single boot server, but if you're setting up a larger network that will span several departments, you could set up a boot server for each department which could also act as the department's major file server. The users of each department will still be able to access files (subject to file access permission) in other departments. This setup creates a fault-tolerant environment: A failure in one department won't stop another department from booting. It also helps avoid a booting bottleneck when many users want to boot at the same time (e.g. when they start work).

Multiple network links

Having more than one network link in a computer provides fault-tolerance and increased throughput.

In QNX RTP, a node can communicate with multiple networks simultaneously. [Author's Comments: this needs to be expanded to show how]

You can't boot across a bridge.

Network cards and drivers

RTP contains drivers for many different types of network cards (see our web site for the current list of supported network drivers). All current RTP network drivers are documented in the Utilities Reference: look for entries with the devn- prefix (or take a look at the Network drivers (dev-*) section of the Utilities Summary).

TCP/IP networking

Introduction

This section gives you information on setting up for TCP/IP networking on an RTP network. The TCP/IP protocols enable computers to share computing resources through multiple networks implemented on many operating systems over a variety of network media. A QNX RTP system that supports TCP/IP can access resources located on any other system that supports TCP/IP. You can install all of the normally available TCP/IP services on an RTP network.

For all its benefits, TCP/IP requires skillful configuration. As a system administrator, you should become familiar with the basic concepts and terms. Fortunately, because TCP/IP networking has become so popular, many books have been written on the subject. For a discussion of QNX 6 TCP/IP specifics, see System Architecture.

RTP supports TCP/IP with two different stacks: a tiny stack (see npm-ttcpip.so) and a full BSD 4.4 TCP/IP stack (see npm-tcpip.so in Utilities Reference). The tiny stack is meant for resource-constrained applications where it is not necessary to have all TCP/IP services present; for a list of the services not covered in the tiny stack, see the limitations listed in Utilities Reference. Our Knowledge Base website has more information on switching between stacks. [Author's Comments: include the article on Switching between Tiny and Big TCP/IP stacks here]

[Author's Comments: Include a note about selecting from among several tcpip hosts on a network]

QNX and TCP/IP two different network models

The networking model used by TCP/IP differs from that used by Qnet, the native QNX 6 network. These networking models can coexist with each other even on the same cable.

The native QNX 6 networking protocol, Qnet, provides a LAN with a fast, seamless interface between nodes. In Qnet, a program can transparently access any resource whether it's a file, a device, or a process on any other node in the network. A program can also transparently execute on other nodes. Nevertheless, Qnet nodes can communicate only with other computers that are running RTP on the same Qnet network.

TCP/IP can send information across multiple intermediate hops to reach its destination TCP/IP isn't limited to LANs. These hops can span many physical networks, over a wide or local area.

Some terminology explained

Hosts and gateways

In TCP/IP terminology, we always refer to network-accessible computers as hosts or gateways.

host

A host is a node running TCP/IP that doesn't forward IP packets to other TCP/IP networks; a host usually has a single IP (Internet Protocol) address associated with it.

gateway

A gateway is a node running TCP/IP that does forward IP packets to other TCP/IP networks; a gateway always has more than one physical interface to allow it to connect to more than one network, and each interface has a different IP address. The number of gateway computers you need will be based on your network's need to access other TCP/IP networks.

Clients and servers

There are two types of TCP/IP hosts: clients and servers. A client requests TCP/IP service; a server provides it. In planning your network, you will have to decide which hosts will be servers and which will be clients.

Processes

In RTP, 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 an RTP node, you have to start several processes. You start different processes for each node according to the services you want that node to provide. By adding the appropriate processes to a node's startup script file (e.g. /etc/rc.d/rc.local.node), you can easily enable a node to be a Qnet workstation, a TCP/IP client, a TCP/IP server, or all three!

Protocols

The term 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 and to find a node's IP address, you need a nameserver.

Nameservers

People normally access a TCP/IP or Internet host with a text name [Author's Comments: need url element tag] (www.qnx.com) rather than an IP address (209.226.137.1). To make this possible, you must have either:

The simple way to map between alphanumeric names [Author's Comments: @@url tag] (e.g. www.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 have something a bit more complicated than a small internal network with a few hosts, you need a nameserver (e.g. for an ISP connection to the Internet). A nameserver is a database containing the name and IP address of hosts. If someone attempts to connect to a TCP/IP host using a name, the nameserver is asked for the corresponding IP address and the connection is then made to that IP address.

If you are using phlip, the Photon TCP/IP and dialup configuration tool, to configure the network, and specify nameservers, they are loaded in the configuration string CS_RESOLVE. This will always be searched first instead of the /etc/resolv.conf file if it exists. If you are not using phlip, you can add your nameserver entries in the /etc/resolv.conf file. For example: 

nameserver 10.0.0.2 nameserver 10.0.0.3

For more information on finding TCP/IP host names and nameservers, see /etc/hosts and /etc/resolv.conf in Utilities Reference.

Routing

Routing determines how to get a packet to its intended destination. There are three general categories of routing:

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

Debugging

Several utilities (fully described in the Utilities Reference) are useful for debugging TCP/IP configurations:
When you want to:
 		Use this command:
Configure and query network interfaces
 		ifconfig
Configure and query hardware-to-protocol address translation
 		arp
Display infromation about a particular network interface connection
 		nicinfo
Get information about network status (big stack)
 		netstat
Get information about network status (tiny stack)
 		cat /proc/ipstats
Get reports on routes and delays through the network
 		traceroute
Look up the translation of alphanumeric names to IP addresses
 		nslookup
Manipulate the routing tables
 		route
Test a connection to a specified host
 		ping

Using the debugging utilities

The following examples show how you can use some of these debugging utilities.

Configuring PPP

A common problem involves configuring a PPP interface correctly. Assume that a user has established the connection using pppd. Now she can ping the machine she's dialed into (isp.com), but she can't get any further (e.g. to the Internet). The user's routing tables (from netstat -rn) might 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 she really needs is a route to anywhere she doesn't have in her 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).

Other routing problems

In some 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 on 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 of the address shows how to get to the outside entry point in a network; the host part shows how to get to a particular host on that network.

Use the ifconfig command to find the netmask for a specific interface. E.g. 

ifconfig en9

might give 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 might find that en2 has the netmask ff000000. So, how do we know which interface to use when we transmit a certain packet? We find the longest match. Say we have a packet going to 10.0.0.5. If we bitwise AND 10.0.0.5 with ff000000, we see that no portion of the network address will be masked, so the packet will go out the en2 interface. If we then look at a packet bound for IP address 10.8.0.67; we find that ff000000 would mask the .8 portion of the IP address, but ffff0000 would not, so we use en9.

Address mapping

Networking hardware does not recognize IP addresses, it uses other types of addressing. For point-to-point links it's just "the other end". For a common access network medium it's some other type of address; Ethernet for instance uses 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 maintenance messy because each machine on the network has its own /etc/hosts file and all of them would have to be updated when there's a change.

IP uses the Address Resolution Protocol (ARP) to handle address mapping, To obtain the hardware address of a host, the arp utility broadcasts a request containing the IP address of the required host. When that host receives the request and recognizes its own IP address, it returns a message to the sending host giving its hardware address. The arp utility stores that relationship in a cache for future use.

You can use arp to set up a 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 check the address for a host. Options to arp let you list, delete, and set entries in the cache.

Finding addresses through DNS

The nslookup utility lets you query the DNS database. For example, suppose you enter this: 

nslookup vir.com

you might see this display: 

Server:   qnx.com
Address:  209.226.137.1
Aliases:  quics.qnx.com

Non-authoritative answer:
Name:     vir.com
Address:  199.84.154.65

This tells us that qnx.com thinks vir.com has the address 199.84.154.65. You can also check addresses by getting a second opinion on the correct address for a host, e.g the command: 

nslookup neocom.com vir.com

might give us: 

Server:   RosedeLima.Vir.com
Address:  199.84.154.65

Name:     neocom.com
Address: 207.155.85.26

This says that vir.com thinks that neocom.com is at 207.155.85.26. We can then ask mars.man.net where neocom.com is by entering: 

nslookup neocom.com mars.man.net

This gives us: 

Server:    ns1.astra.mb.ca
Address:    198.53.163.2

Non-authoritative answer:
Name:      neocom.com
Address:    207.155.85.26

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.

Tracing routes

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. E.g. if you type: 

traceroute vir.com

you might get an output looking something like this: 

traceroute to vir.com (199.84.154.65), 30 hops max, 38 byte packets
 1  router.qnx.com (209.226.137.126) 70 ms 10 ms 10 ms
 2  206.47.248.129 (206.47.248.129) 70 ms 10 ms 10 ms
 3   corocor01-fa0-0-0.ottawa.advantage-internet.bell.ca (206.47.228.209) 70 ms 10 ms 80 ms
 4  corsmcr02-atm6-0-35.toronto.advantage-internet.bell.ca (206.47.228.13) 70 ms 70 ms 20 ms
 5  205.207.238.193 (205.207.238.193) 70 ms 110 ms 110 ms
 6  bxcix-h1-1-0.toronto.canet.ca (205.207.238.202) 70 ms 100 ms 100 ms
 7  198.133.49.2 (198.133.49.2) 80 ms * 50 ms
 8  205.150.159.65 (205.150.159.65) 70 ms 40 ms 40 ms
 9  f100.bb2.mtl1.uunet.ca (198.168.69.2) 80 ms 110 ms 110 ms
 10 delphi4k.dsuper.net (205.205.255.20) 130 ms 130 ms 130 ms
 11 Viateur.Soo.com (199.84.154.66) 150 ms * 140 ms
 12 RosedeLima.Vir.com (199.84.154.65) 150 ms 240 ms 350 ms

So what does this tell us? To go from the router at qnx.com in Ottawa to RosedeLima.Vir.com in Montreal takes 12 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 service 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 forward option to npm-tcpip.so (see Utilities Reference). With this option, data packets will be routed from one network to another. Note that each interface must reside on a different IP network.

[Author's Comments: (@@check and expand this)]

Configuring TCP/IP servers

If a host is a server, it invokes the appropriate daemon to satisfy clients' requests. A TCP/IP server typically runs the inetd daemon (also known as the Internet super-server).

The Internet super-server daemon

The Internet super-server daemon (see inetd in Utilities Reference) 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 a remote login, inetd starts rlogind (the remote login daemon) to satisfy the request. Most client requests are handled this way.

You use the super-server configuration file (see /etc/inetd.conf in Utilities Reference) to specify the daemons that inetd can start. As shipped in the RTP distribution, this file describes all currently supported QNX 6 TCP/IP daemons and some nonstandard pidin services. Unless you want to add or remove daemon definitions, you don't need to modify this file. You shouldn't manually start the daemon processes listed in this file they expect to be started by inetd.

Other resident daemons

The following daemons can run independently of inetd. You can find descriptions of them in Utilities Reference.
Find the daemon for:
 		Under this reference:
Implementing Internet boot protocol
 		bootpd
Managing line printer spools
 		lpd
Mapping Internet domain names
 		named
Managing network routing tables
 		routed
Maintaining system status database
 		rwhod
Tiny HTTP web server
 		slinger
SNMP agent
 		snmpd

These daemons listen on their own TCP ports and manage their own transactions. They're usually started when the computer boots and then run continuously although, to conserve system resources, you can have inetd start bootpd only when a boot request arrives.

Modem configuration

[Author's Comments: (@@How do I set up a modem config?)]

Serial networking

[Author's Comments: (@@Are QNX4 TCP/IP utilities sliplogin and slattach relevant to RTP? What is a serial network configuration? What do I need to configure one? ]

Tiny Stack

The tiny stack is for use when you need to conserve resources. It contains many of the functions found in the full TCP/IP stack, but not all of them: see npm-ttcpip.so in Utilities Reference for a list of its limitations.

To see how you have configured your system or to view the current network connections when using the tiny stack, read the /proc/ipstats file, like this: 

cat /proc/ipstats

You'll see something like this: 

Ttcpip Jun 15 2000 22:36:01

verbosity level 0
ip checksum errors: 0
udp checksum errors: 0
tcp checksum errors: 0

packets sent: 0
packets received: 0

en0 : addr 10.0.0.100    netmask 255.0.0.0    down
lo0 : addr 127.0.0.1     netmask 255.0.0.0    up

DST: 10.0.0.0      NETMASK: 255.0.0.0     GATEWAY: en0
DST: 127.0.0.0     NETMASK: 255.0.0.0     GATEWAY: lo0
DST: 0.0.0.0       NETMASK: 0.0.0.0       GATEWAY: 10.0.0.1

Here you can see that the interface has been configured to 10.0.0.100 and the default route has been set to 10.0.0.1

Full TCP/IP Stack

The full TCP/IP stack is based on the BSD 4.4 TCP/IP stack and supports similar features. If you are not using phlip to configure the full stack, it uses a set of utilities to configure the network rather than command line options. To start, the TCP/IP shared object (DLL) must be loaded into io-net: 

io-net -dne2000 -ptcpip

To configure an interface with an IP address, you must use the ifconfig utility. To configure your network interface with an IP address of 10.0.0.100, you would use the following command: 

ifconfig en0 10.0.0.100

If you also wanted to specify your gateway, you would use the route command: 

route add default 10.0.0.1

This configures the gateway host as 10.0.0.1.

If you then wanted to view your network configuration, you would use the netstat command (netstat with the -in option displays information about the network interfaces): 

Name Mtu    Network   Address           Ipkts Ierrs Opkts Oerrs Coll
lo0  32976  <Link>                       0    0     0     0     0
lo0  32976  127       127.0.0.1          0    0     0     0     0
en0  1500   <Link>    00:50:da:c8:61:92 21    0     2     0     0
en0  1500   10        10.0.0.100        21    0     2     0     0

To display information about the routing table in the full stack, use netstat with the -rn option; the resulting display looks like this: 

Routing tables

Internet:
Destination Gateway    Flags Refs Use Mtu Interface
default     10.0.0.1   UGS   0    0   -   en0
10          10.0.0.100 U     1    0   -   en0
10.0.0.100  10.0.0.100 UH    0    0   -   lo0
127.0.0.1   127.0.0.1  UH    0    0   -   lo0

The table shows that the default route to the gateway was configured (10.0.0.1) [Author's Comments: (@@check this)]

Dynamic TCP/IP configuration

[Author's Comments: explain pppd, phlip, phdialer]

PPP

[Author's Comments: (anything needed here?)]

Networking for Internet and mail

[Author's Comments: (networking considerations only--see photon chapter for other) ]

How To Configure Your Network Interfaces

Configuring a boot server

This section shows you how to set up a single boot server. Once you've set up a single server, you can set up the booting nodes. If your site requires additional boot servers, see "Setting up multiple servers".

This assumes that your machine currently boots RTP from its own hard disk.

To convert an RTP node into a boot server:

Installing network cards

Installing multiple cards on one machine

The nettrap utility detects installed network cards and, optionally, starts their drivers (see Utilities Reference for details). You must be root to use nettrap.

Setting up a server

[Author's Comments: (@@How do I set up a server? How do I set up multiple servers?)]

configuring a boot server

[Author's Comments: user queries--@@How do I configure my boot server? Booting a QNX system using the BOOTP protocol? How do I set up a node to boot off a Neutrino network What is a BOOTP server? How do I boot a node using BOOTP? Why would I want to? How do I set up a node to boot from its hard disk? Why would I want to? What are multiple boot servers and how would I set them up and use them? What is meant by broadcast booting with a QNX ROM? What is Netboot?)]

Setting up a workstation

[Author's Comments: (@@How do I configure a workstation?) ]

Setting up a node to boot off a QNX 6 network

setting up boot servers and workstations

[Author's Comments: (@@Q: under QNX4 I have multiple machines as different nodes. How do I do this in QNX RTP? (i.e. where is the net table where I list the different nodes with the pertinent hardware information?) A1: No need to do that configuration now. It's called Qnet on RTP, to start it, being root and just do a: mount -Tio-net /lib/dll/npm-qnet.so. You should be able to see everybody who is running this under /net. Then it's just ls /net/ somebody instead of ls //2 ) A2: You have to mount the equivalent of QNX4 FLEET, it's called Qnet. mount -T /dev/io-net npm-qnet.so: This will create a directory call net into which you should see all the other machine (assuming qnet was also started)) ]

Booting a node using a BOOTP server

Setting up a node to boot from its hard disk

Setting up multiple servers

Network examples

[Author's Comments: (find and include some n/w examples]

Configuring and starting network drivers

[Author's Comments: (@@How do I set up n/w drivers? How do I start n/w drivers?)]

Adding network cards

[Author's Comments: (@@How do I add n/w cards? (add link to new support page or to beta site?) How do I set up 2 or more NICs on 1 machine?)]

Configuring network cards

[Author's Comments: (@@Q: My netgear card is not detected at startup. Thus, I must type the following lines into the terminal to get it up: slay io-net in-net -d ns83815 -p ttcpip netmanager -r en0After that, I must go to network config and set my IP and netmask, as well as enable the device. And how do I get it to do this during bootup? A: You should only need to do network config once, basically, put all your input into a file and let netmanager read the file and set everything for you. Edit/Create /etc/rc/rc.local, put those 3 lines in it, make sure you did a chmod a+x /etc/rc/rc.local. The rc.local script file executes on system startup.) ]

Communicating across networks

[Author's Comments: (@@What are multiple n/w links? What are their benefits? How do I communicate across n/ws? How do I configure multiple n/w links)]

Setting up a two-node Ethernet network

[Author's Comments: (@@Move this up later)]

Here's how to set up a functioning RTP network from scratch. We start with two machines, say a desktop and a laptop, and then proceed to turn them into a two-node Ethernet network, step by step.

Setting up the hardware connection

First, get your hardware connection set up:

Setting up network support

Now get the necessary network support:

You might be wondering why we didn't tell io-net to load the Qnet protocol when we started it. Well, when io-net starts up, the device driver it loads (e.g. devn-ne2000.so, as above) might need some time to fully initialize. If we were to start Qnet too soon it might start sending packets before the driver is ready and those packets may be lost. That's why it is safer to mount Qnet as a separate step after io-net has loaded the drivers.

You might also be wondering why we didn't load a TCP/IP stack. So far, we are only interested in constructing an internal LAN with no outside connections, but when we expand the LAN to get to the outside world and connect to other networks, we will load the tiny TCP/IP stack either when we start io-net, like this: 

io-net -dne2000 -pttcpip

Or we can mount it after we have started io-net, like this: 

mount -Tio-net npm-ttcpip.so

For more information on the Qnet shared object, see npm-qnet.so in Utilities Reference.

Checking your setup

Now, when you type ls /net, you should see desktop and laptop (or whatever else you decided to call them) listed as the nodes connected to your network). You can reach files on laptop from desktop by referring to /net/laptop; for example, on desktop, ls /net/laptop/etc shows you the files in the etc directory on laptop; cd /net/laptop/etc places you in the /etc directory of laptop, and so on.

If you wish, you can identify a remote node's directories and files using a symbolic link, see the -s option of the ln command in Utilities Reference.

Finding and fixing network problems

[Author's Comments: (@@Diagnosing network problems--how can I diagnose my n/w? Are there any n/w statistics available? How do I interpret them? Network diagnostics (originally using the netinfo and ditto utilities))]

[Author's Comments: check this] I have a supported network card installed and pin and pin con finds it, but Photon network configuration shows no devices tab.: What do I need to do to get this card to work? As root from a terminal enter the following commands: 1) slay io-net 2) pin (then note the I/O port and IRQ for your card) 3) io-net -dne2000 ioport=0xaaa,irq=bb -pttcpip if=en0:xx.xx.xx.xx where aaa is the I/O port, bb is the IRQ, and xx.xx is your IP address. 4) nicinfo This should show tell you whether your Ethernet adapter is receiving and transmitting packets and its MAC address)

No modem detected

You can find out if RTP detects a modem on a particular serial port from Photon or from the command line.

Incorrect serial port settings

When RTP launches the serial communications manager (e.g. devc-ser8250) at boot time, it makes certain assumptions about the settings to use; sometimes these assumptions are wrong. Check your settings by looking at the arguments used when devc-ser8250 was started, like this: 

# pidin ar | grep devc-ser8250

You`ll see something like this: 

131089 devc-ser8250 -u1 3f8,4 -u2 2f8,3

This result tells us that RTP set up two serial ports: one at address 0x3f8, using IRQ 4 and another at 0x2f8 using IRQ 3. If the options used are incorrect, slay the serial communications manager and start it again with the correct options (see devc-ser8250 in Utilities Reference).

No NIC detected

From the Photon shelf, select Network Cfg, then select the devices tab in the TCP/IP Configuration dialog box. If your Ethernet network card was not detected, no devices will be shown (and there will be no en* entries in the /dev/io-net directory).

Not all network cards are supported at this time. If you have installed your NIC properly but running nettrap gives no response, your NIC is not supported.

Wrong protocol loaded

Find io-net using pidin, like this: 

#pidin | grep io-net

You should see something like this: 

503825 1 o-net/x86/o/io-net 10o SIGWAITINFO
503825 2 o-net/x86/o/io-net 18o RECEIVE 1
503825 3 o-net/x86/o/io-net 10o RECEIVE 1
503825 4 o-net/x86/o/io-net 21r RECEIVE 3
503825 5 o-net/x86/o/io-net 20o RECEIVE 6
503825 7 o-net/x86/o/io-net 19f CONDVAR 80528a8

Here, we see that io-net has a process ID of 503825. Use this ID to check the devices and protocols loaded, like this: 

#pidin -p503825 mem

This command will produce a display like this: 

503825 1 o-net/x86/o/io-net 10o SIGWAITINFO 40K 360K 8192(516K)*
503825 2 o-net/x86/o/io-net 18o RECEIVE     40K 360K 4096(12K)
503825 3 o-net/x86/o/io-net 10o RECEIVE     40K 360K 4096(12K)
503825 4 o-net/x86/o/io-net 21r RECEIVE     40K 360K 4096(132K)
503825 5 o-net/x86/o/io-net 20o RECEIVE     40K 360K 4096(132K)
503825 7 o-net/x86/o/io-net 19f CONDVAR     40K 360K 4096(132K)
        ldqnx.so.1 @b0300000 296K 12K
        devn-el900.so @b034d000 56K 4096
        npm-tcpip.so @b035c000 184K 44K

Here we see that io-net loaded the 3Com 90x NIC device driver (devn-el900.so) and the full TCP/IP stack (npm-tcpip.so).

No network connection

From Photon, select Network Cfg, then select the Network tab in the TCP/IP Configuration dialog box, and then check the network data you see there. You can also check the state of the TCP/IP stacks as follows:

Use the following suggestions to narrow down network connection problems:

Gathering Data for Troubleshooting

When you have a problem that can't be solved using the usual troubleshooting methods, using the following commands to gather information can sometimes shed sufficient light on the problem to indicate the solution. If you contact us for help, we will ask you for this information to help us diagnose your problem.

Run these commands as root.

pci

If RTP does not detect your network card, it may be that the PCI detection scheme doesn't recognize the way your card identifies itself. The output of the following command will help us understand more about your hardware configuration. Be sure to include this in any hardware related bug reports: 

pci -v 



   For more information on this command, see pci in Utilities Reference.
pidin

This command tells you what processes are running on your system and how they are interacting with each other. The output display may help you locate the problem; e.g. if io-net is not listed, you have identified your networking problem: this process must be running. Other problems could be related to the state a process is in. For more information on this command, see pidin in Utilities Reference.

pidin mem

This is a specific option of pidin to display the DLLs that are loaded into io-net. This will help determine whether the proper network driver is running and also what TCP/IP stack is being used.

pidin ar

You can use this option of pidin to list the command-line arguments used when specific processes were started.

getconf CS_RESOLVE

This will list the nameserver information. This configuration string is used instead of /etc/resolv.conf (if it exists). For more information on this command, see getconf in Utilities Reference.

cat /etc/resolv.conf

This will list nameserver information from the resolver configuration file. If the configuration string above isn't used, this file will be used to locate the nameservers. For more information on this file, see resolv.conf in Utilities Reference.

cat /etc/hosts

This shows a database file that maps hostnames to IP addresses. This file is usually used as an alternative to a name server, but can be used with a nameserver. If used with a nameserver, it's usually checked before the nameservers are queried. For more information on this file, see Utilities Reference.

nicinfo

This utility will list information related to the network adapters and how well they're working. For more information on this command, see Utilities Reference.

nettrap

This command will query the hardware to determine what network driver should be used. If this doesn't match the output from pidin mem above, then you're probably using the wrong network driver DLL. For more information on this command, see Utilities Reference.

netstat

If you're running the full TCP/IP stack (io-net has loaded npm-tcpip.so), the following netstat options will give you information about the full TCP/IP stack:

syslogd

If a specific TCP/IP application may be causing the problem, check the system log: most TCP/IP applications write debug information into syslog. You'll need to start syslogd and probably create the file that the log is written to (see /etc/syslog.conf in Utilities Reference).

To test syslogd, type logger test: this test line should appear in the log file. If it doesn't appear, please review the syslogd documentation in Utilities Reference. If it does appear, the TCP/IP application should be able to log events as well.

slogger

The system logger, slogger, is the central manager for logging applications' system messages. It maintains these messages in a circular buffer, allowing them to be read later or in real time. When the buffer fills, new messages replace the oldest ones in the buffer. The -l and -f options cause slogger to write the messages to a log file.

Filing bug reports

[Author's Comments: where and when should users send this information?]
QNX Software Systems Ltd.
http://www.qnx.com
Voice: +1 613 591 0931
Fax: +1 613 591 3579
info@qnx.com
TOC PREV NEXT INDEX