This chapter covers the following topics:
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 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!
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, directly from the InterNIC, or from your MIS department.
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
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.
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.
To configure your machine to be a client on an Ethernet, Token Ring, or FDDI network, follow these steps:
Socket mymachine &
Typically the string mymachine comes from the /etc/hosts file.
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.
The following table gives the QNX LAN interface IDs for the various hardware protocols supported:
For this protocol | Use this interface: |
---|---|
Ethernet | enx |
FDDI | fddix |
PPP | pppx |
SLIP | slx |
Token Ring | trx |
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.
There are two ways to connect to a SLIP server:
For both of these methods, we assume that Socket is started with the -s1 parameter. This creates the sl0 (first SLIP) device.
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 -- home machine Swork::102:100:Paul Slip:/home/pk:/etc/sliplogin #/etc/passwd -- work machine Shome::103:100:Paul Slip:/home/pk:/etc/sliplogin
# Host Database 127.1 localhost 192.168.200.202 sliphome 192.168.200.200 slipwork
# login local-addr remote-addr mask opt1 opt2 Swork sliphome slipwork 255.255.255.0 compress Shome slipwork sliphome 255.255.255.0 compress
#!/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:
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.
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.
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.
stty -hupcl
For more information, see the stty man page in the QNX Utilities Reference.
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.
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 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).
For these examples, we assume that:
You'll find four examples here, presented in order of complexity:
Note that since PPP is commonly used to connect to an ISP (Internet service provider), you may find Example #2 the most useful.
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.
Now, node1 will be able to ping 10.0.0.2 using the PPP link.
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:
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:
/bin/stty baud=115200 bits=8 stopb=1 par=none -hupcl +raw < /dev/ser1
/usr/ucb/Socket -p1 node1 &
/usr/ucb/ifconfig lo0 127.0.0.1
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.
/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.
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:
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:
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:
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
The QNX PPP supports two authentication protocols:
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:
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: |
---|---|
first | the client (or authenticatee) |
second | the server (or authenticator) |
third | the 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.
Routing is the act of determining how to get a packet to its intended destination.
There are really three general categories of routing:
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 |
Lookup 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. 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.
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 should 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.
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 Chapter 5, Utilities, and Chapter 6, Files. 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
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've referred to Socket as the IP manager. But QNX TCP/IP actually contains two IP managers:
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.
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.