test

ChorusOS 5.0 System Administrator's Guide

Part III Network Administration for ChorusOS 5.0

This part of the guide provides a description of network administration in the context of the ChorusOS product. It contains information on:

In the ChorusOS operating system, many network administration tasks are performed during system initialization. The process of how to initialize and configure a ChorusOS system, has already been described in "System Start-up". This part of the guide focuses on how network initialization fits into overall system initialization, on how to administer the ChorusOS operating system over a network.

In essence, the ChorusOS boot process involves loading the system image, initializing kernel structures and finally starting all boot actors. Network structures are not initialized until after the end of the boot process.

Initializing network structures is the task of the C_INIT(1M) boot actor. At system initialization, the C_INIT actor loads a special system initialization resource file, sysadm.ini(4CC), and executes the commands it contains sequentially.

Thus, an important point about sysadm.ini is that among other facilities it should contain all commands needed to set up networking on the ChorusOS target system. The rest of this guide focuses on the commands related to networking setup and on the networking capabilities such commands enable for system administrators of ChorusOS.

In terms of networking, sysadm.ini allows you to:

Chapter 9 Network Components

This chapter describes network interfaces, devices and protocols in the ChorusOS product. The goal is to improve your understanding of what is available in the ChorusOS operating system before you begin setting up networking on a ChorusOS system. This chapter does not describe how to set up network components.

Supported Protocols

Network protocols define how messages are formatted and packaged for transmission over the network. They provide support for sockets, which are endpoints for communication, described in socket(2POSIX).

ChorusOS systems provide support for the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) over the Internet Protocol (IP). TCP is a high-level, reliable, connection-oriented protocol. It verifies that messages it sends get to their destinations and re-sends them if necessary. To do so, TCP relies on connections between the sender and the receiver. In contrast, UDP is also high-level, but is unreliable. It sends messages without verifying if they arrive, making UDP faster and lighter on system rescources than TCP. Both TCP and UDP sit atop the lower-level IP, the transport protocol for the Internet. This version of the ChorusOS operating system supports IPv6 and IPv4. Both UDP and TCP are supported over both versions of IP. For details about the ChorusOS implementations of these protocols, see ip(7P), ip6(7P), tcp(7P), and udp(7P). See also inet6(7P) and icmp6(7P). This guide provides information on IPv6. See "IPv6 and the ChorusOS System".

The Network Time Protocol, (NTP), is also supported. See ntpd(1M) and "Network Time Protocol (NTP)" for more information.

ChorusOS systems also support remote inter-process communication (remote IPC), by allowing you to create an IPC stack in the C_OS system actor and attach the stack to an Ethernet device. For details, see ethIpcStackAttach(2K) and IPC(5FEA). A chapter on Configuring IPC is provided with this guide. See Chapter 14, Configuring IPC.

Finally, ChorusOS systems provide a mechanism to support Open Systems Interconnect (OSI), by allowing you to attach an OSI stack that you provide to an Ethernet device. For details, see ethOsiStackAttach(2K).

Supported Interfaces

ChorusOS systems provide support for Ethernet, loopback and PPP network interfaces.

Network interfaces are lower-level than network protocols, providing the link between network hardware and network protocols. Figure 9-1 illustrates how the ifnet interface does this for Ethernet connections. Figure 9-2 does the same for the ppp interfaces for PPP connections. (Note that BPF here is Berkeley Packet Filter, and is explained in "Supported Devices".

Figure 9-1 Ethernet Networking

Graphic

The following list describes the network interfaces provided:

ifethN

The ChorusOS Ethernet interface provides the standard solution for high-speed network connections with other systems.

loN

The loopback interface allows a system to communicate with itself through IP without sending packets over the network. It is a software-only interface and does not depend on network transport hardware.

pppN

A PPP interface allows the ChorusOS system to connect to another system using a direct serial line or modem connection in the same way as an Ethernet connection.

gifN

A gif interface allows tunneling IP in IP.

Figure 9-2 PPP Networking

Graphic

Supported Devices

Network devices are low-level software drivers that make it easier for applications to work closely with network hardware.

ChorusOS systems provide two important types of network devices, Berkeley Packet Filters (BPF) and Teletype (tty, ptyp, ttyp) devices. Each network device described here requires both a device structure and a special file in order to function.

Special files provide access either to peripheral devices, such as serial lines, or to logical "devices", such as Berkeley Packet Filters. Each special file:

By convention, special files are located in the /dev directory. Special files are created, usually during system initialization, using the mknod(1M) command. See also "Naming Conventions for Special Files".

The following list enumerates and describes the network devices provided:

bpfN

A Berkeley Packet Filter is a special character device that allows applications to access all network packets directly, independently of network protocols. It is used in ChorusOS systems by networking utilities such as dhclient(1M) and rarp(1M) and tcpdump(1M).

The BPF device name is built from bpf concatenated with a unit number, N. So to make a BPF device:


$ mkdev bpfN

The BPF special file name takes the form /dev/bpfN.

ttyN

Teletype character devices date from the time when systems wrote output on teletypewriters. ChorusOS systems use tty character devices for serial line communications. The two pseudo-tty devices, ptyp (master) and ttyp (slave), are used by PPP interfaces to detect when IP traffic occurs in order to configure tty devices for dial-up on demand. The pseudo tty are also used by rlogin to manage a remote terminal over a socket link. There may be many pseudo tty and only a very small number of serial tty.

The tty device name is built from tty concatenated with a unit number, N.

To make a tty device:


$ mkdev ttyN

The tty special file names take the form /dev/tty0M, /dev/ptyp0M, or /dev/ttyp0M, where M is 1, 2, 3....

Chapter 10 Setting Up Ethernet

The ChorusOS Ethernet interface provides the standard solution for high-speed network connections with other systems. This chapter takes you through the process of setting up an Ethernet connection for a ChorusOS system. The four stages of setting up Ethernet are described sequentially:

  1. Hardware Configuration

  2. Interface Creation

  3. Device Creation

  4. Interface Configuration

If your system does not support Ethernet, or if you do not plan to use Ethernet with your system, you may skip this chapter.

Configuring Hardware

ChorusOS systems may support multiple Ethernet devices that all have their own Ethernet interface. See the appropriate guide in the ChorusOS 5.0 Target Platform Collection for the list of supported Ethernet devices for your particular target system hardware.

If you are unsure which Ethernet device your system uses, yet you are able to boot the system, you can use the dtree(1M) utility to display devices listed in the target system device tree:


$ rsh target dtree

A ChorusOS system often uses the Ethernet interface in conjunction with the Dynamic Host Configuration Protocol (DHCP) client or Reverse Address Resolution Protocol (RARP) to obtain an IP address at boot time. As the system runs, it uses the Address Resolution Protocol (ARP) to find the Ethernet addresses of other systems, based on their IP addresses.

Creating Interfaces

During system initialization, many network administration tasks are performed when the commands in sysadm.ini(4CC) are executed by the C_INIT system actor. Interface creation is no exception. In order to create the network interfaces that the system needs to communicate through Ethernet devices, you use the mkdev(1M) utility to create one interface for each Ethernet device on your target, and one loopback device for your target.. The command to create an Ethernet device thus takes the form:

mkdev ifeth unito [pathname]

where unit is the number that makes the interface unique and pathname is as shown in the output from the dtree(1M) utility. If you do not include pathname in the command, the ChorusOS system simply attaches the interface to the first free device it finds.

Note -

At this point, the network interface is bound to the Ethernet low-level driver, but Ethernet is not configured for use.

Example 10-1 Ethernet Interface Creation

The following example sysadm.ini fragment creates an interface for an Ethernet device and the loopback interface needed for IP communication.

#
# Set the file creation mask to 0 during system configuration
#
umask 0

#
# Create an Ethernet interface for the first available device
#
# Since no dtree *pathname* is provided, the system uses the first
# device it finds
#
mkdev ifeth 0

#
# Create a loopback interface
# 
# Note that the loopback device is not attached to a device in
# the dtree, so no *pathname* argument is provided here either
#
mkdev lo 0

Creating Devices

Ethernet connections only require corresponding devices if you configure Ethernet interfaces using the dhclient(1M) or rarp(1M) utility. Both of these utilities require a Berkeley Packet Filter (BPF).

It is also possible that your applications require a BPF device for raw access to network packets.

In order to create the BPF device, you can include commands of the following form in the sysadm.ini file that you build into the system image for your target:

# Create the BPF device
mkdev bpf unit
# Create the associated special file
mknod /dev/bpfunit c 23 unit

where unit is the number that makes the interface unique. Note that mknod(1M) is used to create special files. The c refers to the fact that BPF devices are character devices, and 23 is, by convention, the major number used for BPF devices.

Example 10-2 BPF Device Creation

The following example sysadm.ini fragment creates an interface for an Ethernet device and the loopback interface needed for IP communication. It then creates a BPF device needed by dhclient(1M) and rarp(1M).

umask 0
mkdev ifeth 0
mkdev lo 0

#
# Create a Berkeley Packet Filter device and special file
#
# The BPF device is used by either the rarp or dhclient command to
# configure the Ethernet interface
#
mkdev bpf 0
mknod /dev/bpf c 23 0

Configuring Interfaces

Once an interface has been created, you must configure it. Configuring the interface means providing an IP address, a subnet mask and a broadcast mask, and setting the status of the interface to up or down, depending on whether you want it to be operational.

Note -

This is true for IPv4. The new standard IPv6 creates its own address in "plug'nplay" style. See "IPv6 and the ChorusOS System".

Three utilities are provided to configure Ethernet interfaces on ChorusOS systems:

ifconfig

ifconfig(1M) can be used to configure as many Ethernet interfaces as necessary as long as the IP addresses for those interfaces are fixed.

rarp

rarp(1M) allows the ChorusOS system to configure an Ethernet interface with an IP address based on the Ethernet device address using the default subnet mask and broadcast address. This utility is specific to the ChorusOS product. It requires a BPF device on the ChorusOS system and a RARP server on the local network.

dhclient

dhclient(1M) allows the ChorusOS system to configure all parameters of the Ethernet interface, and also configure the routing tables. It requires a BPF device on the ChorusOS system and a DHCP server on the local network. It also requires that you build the dhclient process into the ChorusOS system image for your target (see "Embedding the dhclient process into the ChorusOS system image" for information about how to do this).

The three examples that follow demonstrate how to use the utilities described above.

Example 10-3 Ethernet Configuration with ifconfig

The following example sysadm.ini fragment creates an interface for an Ethernet device and the loopback interface needed for IP communication. It then configures the Ethernet interface.

#
# Set the file creation mask to 0 during system configuration
#
umask 0

#
# Create an Ethernet interface for the first available device
#
# Since no dtree *pathname* is provided, the system uses the first
# device it finds
#
mkdev ifeth 0

#
# Create a loopback interface
# 
# Note that the loopback device is not attached to a device in
# the dtree, so no *pathname* argument is provided here either
#
mkdev lo 0

#
# Set the file creation mask back to the default value
#
umask 22

#
# Configure the Ethernet interface using ifconfig
#
# Note that ADMIN_IFCONFIG must be set to true in order for this to
# work
#
ifconfig ifeth0 129.157.197.88 netmask 0xffffff00 
broadcast 129.157.197.255 up

#
# Configure the loopback interface as well
#
ifconfig lo0 127.0.0.1 up
Example 10-4 Ethernet Configuration with rarp

The following example sysadm.ini fragment creates an interface for an Ethernet device and the loopback interface needed for IP communication. It then creates a BPF device needed by rarp(1M) and configures the interface.

#
# Set the file creation mask to 0 during system configuration
#
umask 0

#
# Create an Ethernet interface for the first available device
#
# Since no dtree *pathname* is provided, the system uses the first
# device it finds
#
mkdev ifeth 0

#
# Create a loopback interface
# 
# Note that the loopback device is not attached to a device in
# the dtree, so no *pathname* argument is provided here either
#
mkdev lo 0

#
# Create a Berkeley Packet Filter device and special file
#
# The BPF device is used by either the rarp or dhclient command to
# configure the Ethernet interface
#
mkdev bpf 0
mknod /dev/bpf c 23 0

#
# Set the file creation mask back to the default value
#
umask 22

#
# Configure the Ethernet interface using rarp
#
# Note that BPF and ADMIN_RARP must be set to true in order for this
# to work
#
# rarp requires a BPF device
#
rarp ifeth0

#
# Configure the loopback interface as well
#
ifconfig lo0 127.0.0.1 up
Example 10-5 Ethernet Configuration with dhclient

The following example sysadm.ini fragment creates an interface for an Ethernet device and the loopback interface needed for IP communication. It then creates a BPF device needed by dhclient(1M) and configures the interface.

#
# Set the file creation mask to 0 during system configuration
#
umask 0

#
# Create an Ethernet interface for the first available device
#
# Since no dtree *pathname* is provided, the system uses the first
# device it finds
#
mkdev ifeth 0

#
# Create a loopback interface
# 
# Note that the loopback device is not attached to a device in
# the dtree, so no *pathname* argument is provided here either
#
mkdev lo 0

#
# Create a Berkeley Packet Filter device and special file
#
# The BPF device is used by either the rarp or dhclient command to
# configure the Ethernet interface
#
mkdev bpf 0
mknod /dev/bpf c 23 0

#
# Set the file creation mask back to the default value
#
umask 22

#
# Configure the Ethernet interface using dhclient
#
# Note that BPF must be set to true in order for this to work
#
# dhclient requires a BPF device
#
# dhclient also requires that the dhclient process be included in the 
# system image
# /image/sys_bank/dhclient ifeth0 &

#
# dhclient does not return until the server has responded
#
# Wait until the Ethernet interface is up to avoid confusing the system
#
ifwait ifeth0

#
# Configure the loopback interface as well
#
ifconfig lo0 127.0.0.1 up

Testing the Interface

Once you think the interface is configured properly, verify that the Ethernet connection is working:


$ rsh target ping host_IPv4_address
host_IP_address is alive

or


$ rsh target ping6 host_IPv6_address
host_IP_address is alive

Another way of verifying that the Ethernet connection is working is to use ifconfig. See "ifconfig".

Chapter 11 Setting Up PPP

This chapter takes you through the process of setting up a Point-to-Point Protocol (PPP) interface on a ChorusOS system. PPP allows the target system to connect to another system using a direct serial line or modem connection in the same way as an Ethernet connection. If your system does not support serial connections, or if you do not plan to use PPP with your system, you may skip this chapter.

This chapter also describes how to enable PPP on a host for use with a ChorusOS system during application development.

The topics covered are:

Further information is provided in "pppstart".

Configuring Hardware

ChorusOS systems support multiple PPP interfaces, each of which is identified by a unique name such as ppp0. Depending on the number of serial lines physically available on the ChorusOS system, the binary distribution of the ChorusOS product provides support for up to two PPP lines. (If you have the source distribution, you can increase the number of lines possible by modifying the value of NPPP in the machine/ppp.h header file.) See the appropriate guide in the ChorusOS 5.0 Target Platform Collection to verify serial line support for your particular target system hardware.

Note -

The first serial line on the ChorusOS system is reserved for system debug, and for console access using the host workstation tip(1) utility. It cannot be used for PPP. The console requires a terminal type cable.

A direct connection between a host and a target requires a null modem cable. See "Asynchronous EIA-232-E Null Modem" in Solstice PPP 3.0.1 Administration Guide for details.

If you are unsure what serial lines your system uses, yet you are able to boot the system, you can use the dtree(1M) utility to display devices listed in the target system device tree:


% rsh target dtree

ChorusOS systems may be used with modems. The chat(1M) utility can help you handle modem connection and configuration. See "chat" for more information.

Note -

This document does not provide information about modem configuration commands, nor does it provide information about the cables required for connecting modems to targets. Please refer to your modem documentation for information regarding modem configuration.

Creating Interfaces

Interface creation for PPP is usually performed by including commands in the sysadm.ini file that you build into the ChorusOS system image for your target. In order to create a PPP interface, use the mkdev(1M) utility as follows:

mkdev ppp unit

where unit is the number that makes the interface unique. In order to allow the system to use IP, you must also create a loopback interface.

Example 11-1 PPP Interface Creation

The following example sysadm.ini fragment creates a PPP interface and the loopback interface needed for IP communication. These commands simply create the interface; nothing is configured for use, yet.

# Create a PPP interface
mkdev ppp 0

Creating Devices

PPP interfaces rely on tty devices to communicate directly with the serial hardware. You must therefore create at least one tty device for each PPP line you intend to open. If the ChorusOS system is configured to "dial on demand", in which case the line only opens when there are packets to send or receive, you must also create a pseudo-tty master (ptyp) and a pseudo-tty slave (ttyp) device for each PPP line.

It is also possible that your applications require a BPF device for raw access to network packets.

Example 11-2 PPP Device Creation

The following example sysadm.ini fragment creates a PPP interface and the loopback interface needed for IP communication. It then creates the tty devices needed to open a PPP line that may be configured for "dial on demand". Finally, it creates a BPF device for any applications that require one.

#
# Set the file creation mask to 0 during system configuration
#
umask 0

#
# Create a PPP interface
#
mkdev ppp 0

#
# Create a loopback interface
#
mkdev lo 0

#
# Create a tty device for the second serial port
#
# The first serial port is reserved for system debug and console access
# through the tip(1) utility on the host workstation
#
# If you do not know the device tree pathname to the second serial port,
# note that device tree is visible in the output of dtree(1M).
#
# Note that major number 0 is conventionally reserved for ttys
#
mkdev tty 0 # takes first available device
# Other possibilities include:
#mkdev tty 0 /pci/pci-isa/ns16650-2
#mkdev tty 0 /raven/w83c553/ns16650-2
#mkdev tty 0 /sabre/simba-b/ebus/ns16650-2
mknod /dev/tty01 c 0 0

#
# Create pseudo-tty devices for on-demand dialing
#
mknod /dev/ptyp0 c 5 0 # Master
mknod /dev/ttyp0 c 6 0 # Slave

#
# Create a Berkeley Packet Filter device and special file
#
mkdev bpf 0
mknod /dev/bpf c 23 0

See the appropriate document in the ChorusOS 5.0 Target Platform Collection for serial device IDs for other serial line hardware.

Configuring PPP

This section explains how to configure Point-to-Point Protocol (PPP) with the ChorusOS product standard interface and drivers. It assumes the serial line or modem is already physically connected. On some platforms, a unique serial line is used both for the console (accessed through tip), and for PPP. At boot time, the serial line connector must be connected to the host tip line.

Note -

Systems often have two IP addresses: one for Ethernet, one for PPP.

This document differentiates between Ethernet Internet addresses and PPP addresses. As you read, be aware that hostname refers to the Ethernet hostname corresponding to the Ethernet IP address, and that host_PPP refers to the hostname corresponding to the PPP address.

PPP as implemented in this version of the ChorusOS operating system handles IP traffic in a different way to previous releases of the ChorusOS operating system. The entire process is described in this chpater in detail but can be summarized as follows:

The process therefore remains the same whether you open one PPP line or multiple lines.

Figure 11-1 IP Traffic--PPP Only

Graphic

In order to make sure the Ethernet interface can still be used for IP traffic, use different IP addresses for Ethernet and IP.

Figure 11-2 IP Traffic--Both Ethernet and PPP

Graphic

It is strongly recommended for this release that you use different IP addresses for PPP and Ethernet.

As shown above, if each system has only one IP address, when an ifnet interface is set up between target_PPP and host_PPP, all traffic to host_PPP is routed through target_PPP. In other words, all IP traffic passes through the serial line.

Enabling PPP Services

Enabling PPP services involves using the pppstart process. You can choose to enable PPP services either automatically at boot time, or manually, via the command line.

Enabling PPP at Boot Time by Including pppstart in the System Image

  1. Change to the directory where you build system images:


    host% cd build_dir

  2. Use the hints in the table below to set system image features and tunables:

    Set... 

    Comments 

    VTTY=true 

    PPP requires virtual ttys.

    PPP=true 

     

    iom.nfs.rsize=1024 

    Optimizing NFS read and write buffer sizes for use with PPP by setting them to a maximum of 1024

    iom.nfs.wsize=1024 

     

    		 


    host% configurator -set VTTY=true


    host% configurator -set PPP=true

  3. Ensure that both serial lines and network interfaces are available for PPP by including the necessary commands in the conf/sysadm.ini file that you build into the system image. For example:

    # set umask to 0 during system configuration
umask 0

# Build the various interfaces you need using the mkdev command.
# All interfaces require a unit number. For bpf and tty, this number also 
# to the device minor. Thus:
#     mkdev tty  0 /pci/pci-isa/ns16550-2
#  corresponds to
#     mknod  /dev/tty01 major 0

# Create the tty interface using the second serial port
# because the first is reserved for the tip line

mkdev tty 0 /pci/pci-isa/ns16550-2 


# rarp needs bpf, again the unit number corresponds to the device minor.
mkdev bpf 0
mkdev bpf 1

# Create a PPP interface that is not bound to the tty yet.
mkdev ppp 0 


# Ethernet
# mkdev  ifeth 0 /pci/epic100
mkdev  ifeth 0


# loopback interface
mkdev  lo 0 

# Create a tty special file
mknod /dev/tty01 c 0 0 

# Pseudo tty devices, needed for dialup on demand.
# mknod /dev/ttyp0 c 5 0 
# mknod /dev/ptyp0 c 6 0 

# Enable PPP
# Requires pppstart in system image
# /image/sys_bank/pppstart &

pppd /dev/tty01 # Open a PPP line.

# Wait for the interface to be up.
#
ifwait ppp0

    See the appropriate document in the ChorusOS 5.0 Target Platform Collection for serial device IDs for other serial line hardware.

  4. Start the Ews configuration utility:


    host% ews conf/ChorusOS.xml &

  5. Include the pppstart process in the system image (see "Embedding the pppstart process into the ChorusOS system image" for information about how to do this).

  6. (Optional) If you need chat, include the chat process in the system image (see "Embedding the chat process into the ChorusOS system image" for information about how to do this).

  7. Rebuild the system image.

    host% make chorus

  8. Copy the system image to the boot server:


    host% rcp system_image_name boot_server:/tftpboot

  9. Reboot the target system:


    host% rsh target reboot
Enabling PPP Manually

  1. Make the serial lines and network interfaces available for PPP:

    • Create a tty interface: 


      host% mkdev tty 0

    • Create a PPP interface:


      host% mkdev ppp 0

    • Create a special tty file:


      host% mknod /dev/tty01 c 0 0

  2. Embed the pppstart process into the ChorusOS system image (see "Embedding the pppstart process into the ChorusOS system image").

  3. Run the pppstart process:


    host% rsh target pppstart &

Opening PPP Lines

Opening an available PPP line involves the built-in C_INIT command, pppd.

Opening a PPP Line Manually

  1. Run the built-in C_INIT command, pppd, on the target system:


    host% rsh target pppd device
pppd device:info: Using interface ppp0
pppd device:notice: Connect: ppp0 <--> device
pppd device:notice: local IP address local_addr
pppd device:notice: remote IP address remote_addr

    where device is either /dev/tty01 or /dev/tty02.

    See pppd(1M) for details.

Closing PPP Lines

Closing an open PPP line involves using the pppclose command.

Closing a PPP Line Manually

  1. Run the built-in C_INIT command, pppclose, on the target system:


    host% rsh target pppclose device
pppd device:info: Terminating on signal 15.
pppd device:notice: Connection terminated, connected for 2 minutes
pppd device:info: Exit.

    where device is either /dev/tty01 or /dev/tty02.

Disabling PPP Services

Disabling PPP services involves using the pppstop command. This kills the pppstop process daemon.

Disabling PPP Services Manually

    Run the built-in C_INIT command, pppstop, on the target system:


    host% rsh target pppstop

PPP on a Solaris Host

This section briefly describes how to configure PPP on the Solaris operating environment system to work with a ChorusOS system. Enough information is provided for you to set up a PPP connection, but for full details about setting up and using PPP on hosts running the Solaris operating environment, see the TCP/IP and Data Communications Administration Guide in the Solaris 7 System Administrator Collection and the System Administration Guide, Volume 3 in the Solaris 8 System Administrator Collection.

Note -

You must be root to install and configure PPP.

Checking for Required Packages

Before configuring PPP, check that the following packages are installed on the host workstation:

  1. SUNWbnuu

  2. SUNWbnur

  3. SUNWpppk

  4. SUNWapppu

  5. SUNWapppr


host% pkginfo | egrep '.*(bnu|ppp).*'
system SUNWapppr PPP/IP Asynchronous PPP daemon configuration files
system SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service
system SUNWbnur Networking UUCP Utilities, (Root)
system SUNWbnuu Networking UUCP Utilities, (Usr)
system SUNWpppk PPP/IP and IPdialup Device Drivers

If the packages are not installed, you must install them in the order specified above before you continue.

Configuration Files

This section describes all files which must be created or modified to configure PPP on a Solaris host.

Configuring the Network

  1. If you are using aliases for your IP addresses, it is important to ensure that the Solaris operating environment can resolve them. In /etc/hosts, include the following lines:

    # Host PPP address Host PPP hostname
host_PPP host_name
# Target PPP address Target PPP hostname
target_PPP target_name
Note -

Make sure /etc/hosts or the NIS configuration file, nsswitch.conf(4) includes PPP addresses for both the host and target systems. The nsswitch.conf file explains how to configure /etc/hosts.

Configuring PPP

You must provide the PPP Link Manager with information regarding each remote host with which the local host will communicate. This information is contained in the PPP configuration file asppp.cf. See also aspppls(1M).

Configure asppp.cf as follows:

  1. Run ifconfig, specify the PPP interface used, select the plumb option to enable IP to recognize the interface, define the local and target hosts and set the interface to up : 

    ifconfig ipdptp0 plumb host_PPP target_PPP up

    See "ifconfig" for more information about the ifconfig command.

  2. Configure the path by adding the interface number, the name of the target host, the ipcp_async_map and the timeout interval: 

    path
 interface ipdptp0
 peer_system_name .zsmon
 ipcp_async_map 0xa000
 inactivity_timeout 1000000

For further information regarding configuring PPP and the asppp.cf file, see "Configuring PPP" in TCP/IP and Data Communications Administration Guide from the Solaris 7 System Administrator Collection and "Overview of PPP" in System Administration Guide, Volume 3 from the Solaris 8 System Administrator Collection. There is also useful information in aspppd(1M)

Configuring a Terminal

This section describes how to modify the terminal configuration to allow a PPP connection without login.

Configuring a Terminal

  1. Become superuser:


    host% su
Password: root password

  2. Start admintool.

  3. Select Serial Ports from the Browse menu.

  4. Double-click the port to use for PPP.

  5. Click the Expert radio button in the Detail field.

  6. Use the hints in the table below to set options for the port.

    Field 

    State/Value 

    Service Enable 

    Selected 

    Baud Rate 

    9600

    Initialize Only 

    Not selected 

    Bidirectional 

    Selected 

    Software Carrier 

    Selected 

    Port Monitor Tag 

    zsmon

    Connect on Carrier 

    Selected 

    Service 

    /usr/etc/aspppls

    Streams Modules 

    ldterm, ttcompat

    Timeout (secs) 

    Never

Starting and Stopping PPP

Once properly configured, PPP starts automatically at boot time.

Starting PPP on the Host

  1. Become superuser:


    host% su
Password: root password

  2. Start PPP:


    # /init.d/asppp start

  3. Make sure PPP started successfully: 


    # netstat -i
Name Mtu Net Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 1386 0 1386 0 0 0
hme0 1500 host_name host_name 93612 1714 73065 0 860 0
ipdptp0 8232 target_PPP host_PPP 0 0 0 0 0 0
# tail /etc/log/asppp.log
12:31:34 Link manager (2099) started 11/27/99
12:31:34 parse_config_file: Successful configuration
12:31:40 000531 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=6b LEN=24
MRU=1500 ACCM=000a0000 MAG#=cdf1e77f ProtFCOMP AddrCCOMP

Stopping PPP on the Host

  1. Become superuser:


    host% su
Password: root password

  2. Stop PPP:


    # /etc/init.d/assppp stop

Making the PPP Target Visible to the Entire Network

If you want the PPP target to be visible from the whole network, you must enable routing on your workstation.

Enabling Routing

  1. Become superuser:


    host% su
Password: root password

  2. Enable routing:


    # ndd -set /dev/ip ip_forwarding 1

  3. Use the proxy-arp command to declare the PPP target as having the same Ethernet address as the workstation:


    # ypcat ethers | grep host
Ethernet_address host
# arp -s target_PPP Ethernet_address pub

Chapter 12 IP and the ChorusOS System

This chapter explains both IPv4 and IPv6 operations in the context of the ChorusOS operating system. It explains how to set up a ChorusOS system as an IPv4 gateway, also called a router. This allows a ChorusOS system to connect to two or more separate subnetworks. It also explains IPv6 in the ChorusOS operating system.

In order to behave as a gateway, a ChorusOS system needs to be installed on a multi-homed host; namely, a host with at least two network interfaces.

The ChorusOS system can act as a gateway in two different ways: either visibly using IP forwarding only (see "IP Forwarding") or transparently by acting as an ARP proxy, (Address Resolution Protocol), (see "The ChorusOS operating system as an ARP proxy").

IP Forwarding

This section explains IPv4 datagrams, and includes procedural instructions for configuring the gateway, and for configuring the hosts on subnetworks.

One of the ways in which the ChorusOS operating system can act as a gateway between separate subnetworks is through simply forwarding IP datagrams. A ChorusOS host with two or more ethernet adapters can be configured to make a link between different network interfaces, as shown in Figure 12-1 below.

Figure 12-1 ChorusOS as an IP Gateway

Graphic

In Figure 12-1 above, the ChorusOS system is a gateway bridging Subnetwork 1 to Subnetwork 2. In order to make this gateway:

For example, in order to send an IP datagram from Subnetwork 1 to Subnetwork 2, the ethernet interface IP addresses must to be created for ifeth0 and ifeth1 on the ChorusOS host. Then, in order to reach Subnetwork 2, datagrams received on the ifeth0 interface must be redirected through the ifeth1 interface. The default behavior would be for a ChorusOS system to drop silently the datagram after it is received at ifeth0, so a specific configuration is required to forward it between the two ethernet interfaces.

Configuring the Gateway

In order to configure the two ethernet interfaces from Figure 12-1 and to create the routing table to redirect the datagrams between the interfaces, add the following lines to the sysadm.ini file (see sysadm.ini(4CC)) of the ChorusOS gateway.

  1. Create the network interfaces:

    mkdev ifeth 0 
mkdev ifeth 1

  2. Configure the ifeth0 interface:

    ifconfig ifeth0 129.158.111.111 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

  3. Configure the ifeth1 interface:

    ifconfig ifeth1 129.159.222.222 netmask 0xffff0000 broadcast 129.159.255.255
ifwait ifeth1

  4. Set up the routes between ifeth0 and ifeth1:

    route add -net 129.158 -iface ifeth0
route add -net 129.159 -iface ifeth1

  5. Configure the ChorusOS operating system to forward the incoming IP datagrams to the corresponding ethernet interface. You do this by activating the net.inet.ip.forwarding state in the microkernel, by adding the following line to the sysadm.ini file:

    sysctl -w net.inet.ip.forwarding=1
Configuring the Hosts on the Subnetworks

You must now configure the hosts on the different subnetworks so that they will use the gateway to send datagrams to each other. For example, assuming that Host A on Subnetwork 1 in Figure 12-1 is running under a ChorusOS system, define a route for it to send datagrams to Subnetwork 2 via the gateway. To do this, add the following lines to the sysadm.ini file for Host A.

  1. Create the network interface:

    mkdev ifeth 0

  2. Configure this interface:

    ifconfig ifeth0 129.158.333.333 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

  3. Set up the routes. You can set up a simple route, which uses the network interface directly:

    route add -net 129.158 -iface ifeth0

    Or, you can specify a gateway explicitly, for example ifeth0 on the ChorusOS gateway from Figure 12-1, as the route to take:

    route add -net 129.159 129.158.111.111

As you can see, the gateway configuration using simple IP forwarding will only work if the hosts on the different subnetworks are correctly configured to send datagrams via the gateway. Since configuring all the hosts to use a specific machine as a gateway is not always possible, it is sometimes necessary to create a gateway between the subnetworks by configuring the ChorusOS operating system to act as an ARP proxy.

The ChorusOS operating system as an ARP proxy

The Address Resolution Protocol (ARP -- see ARP(7P)) maps IP addresses to specific machine addresses in a network. Where a ChorusOS system is acting as a gateway between two or more subnetworks, configuring it as an ARP proxy allows you to handle all the different physical subnetworks as if they are the same network. In other words, creating an ARP proxy makes a single virtual network composed of several physical subnetworks. Consequently, the different hosts located on these networks can communicate without being aware of the presence of the gateway.

This type of configuration is desirable in the following circumstances:

A ChorusOS host with two or more ethernet adapters can be configured as an ARP proxy linking different network interfaces to create a single, virtual network, as shown in Figure 12-2.

Figure 12-2 The ChorusOS system as an ARP Proxy

Graphic

Configuring the Gateway as an ARP Proxy

To configure the ChorusOS gateway to act as an ARP proxy, create the two network interfaces, set them up and create the routing table. To create the example shown in Figure 12-2, you add the following to the sysadm.ini file of the ChorusOS gateway:

  1. Create the two network interfaces:

    mkdev ifeth 0
mkdev ifeth 1

  2. Configure interface ifeth0:

    ifconfig ifeth0 129.158.110.111 netmask 0xffffff00 broadcast 129.158.110.255
ifwait ifeth0

  3. Configure interface ifeth1

    ifconfig ifeth1 129.158.112.222 netmask 0xffffff00 broadcast 129.159.112.255
ifwait ifeth1

  4. Set up the routes:

    route add -net 129.158.110 -iface ifeth0
route add -net 129.158.112 -iface ifeth1

  5. Configure the ChorusOS system to forward IP packets:

    sysctl -w net.inet.ip.forwarding=1

  6. Configure the ChorusOS system to forward ARP requests by activating the net.ether.inet.proxyall microkernel state:

    sysctl -w net.ether.inet.proxyall=1
Configuring the Hosts on the Subnetworks

You must now configure the individual hosts on the virtual network so that they use the ARP proxy gateway. To configure Host A in Figure 12-2 you add the following lines to its sysadm.ini file:

  1. Configure the ifeth0 interface:

    ifconfig ifeth0 129.158.110.333 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

  2. Set a default route, since the router simulates a single network:

    route add default -iface ifeth0

As you can see, when configuring the hosts on the network you are required only to specify the IP address of that particular host and the IP address of the virtual network. There is no requirement to specify the exact IP address of the gateway, thus rendering the gateway transparent to all the individual hosts on the network.

IPv6 and the ChorusOS System

Internet Protocol version 6 IPv6 adds increased address space and improves Internet functionality using a simplified header format, support for authentication and privacy, autoconfiguration of address assignments, and enables new quality-of-service capabilities. This section focuses on Internet Protocol Version 6, the new standard for the Internet and wireless devices. It explains the transition from IPv4 to IPv6, and the effect of IPv6, for a System Administrator.

To ensure that IPv6 works effectively on this version of the ChorusOS operating system, you must configure it as follows:


host% rsh target sysctl -w net.inet6.ip6.accept_rtadv=1


host% rsh target /sbin/rtsolifeth-0
This is necessary to ensure that IPv6 accepts global addresses in addition to link-local addresses. For more information, see "rtsol and rtsold".

These are the advantages of IPv6:

Note -

The IPSEC feature and IPv6 routing facilities are not supported in this version of the ChorusOS operating system. Some include files or utilities related to routing and security may however be present in binary and source product.

This version of the ChorusOS operating system can be used as an end IPv6 host only. You must have an IPv6 router on your network to answer router solicitations and to send router messages.

IPv4 to IPv6 Transition Process

When transitioning from IPv4 to IPv6, it is important to ensure that all existing hosts and routers that still operate on the network at any one time, can support IPv4-only operations. This is to reduce the risk of problems in the event of dual stack nodes, hosts and routers (those that can support both IPv4 and IPv6 operations) sending tasks through IPv4-only nodes. More information is contained in "Transitioning From IPv4 to IPv6" in System Administration Guide, Volume 3

Standardized Transition Tools

The Internet Engineering Task Force, (IETF) specification for advising companies making the transition from IPv4 to IPv6 is the RTF 1933 specification. For transitioning, this document sets out these transition mechanisms:

Configuring Name Services

A dual node must determine if the peer can support IPv6 or IPv4 to know which IP version to use when transmitting. Controlling what information goes in the name service accomplishes this. You define an IPv4 node's IP address and the IPv6 node's IP address in the name service. Thus, a dual node has both addresses in the name service.

However, the presence of an IPv6 address in the name service also signifies that the node is reachable, using IPv6 from all nodes that get information from that name service. This is no different than in IPv4 where some operations depend on there being only IPv4 addresses for nodes that can be reached using IPv4. When no reachability exists in IPv4 the name service must be partitioned so that IPv4 addresses are visible only where they are reachable.

The protocol used to access the name service is independent of the type of address that can be retrieved from the name service. This name service support, coupled with dual stacks, allows a dual node to use IPv4 when communicating with IPv4-only nodes and use IPv6 when communicating with IPv6 nodes, provided that there is an IPv6 route to the destination.

IPv6 Related Processes

Processes and procedures for ChorusOS networking are enhanced by the introduction of Plug'n'Play Free BSD 4.1 IPv6 and related features. See ip6(7P) and icmp6(7P) man pages for further information.

IP stacks: IPv4 and IPv6

The ChorusOS operating system provides TCP/IP and UDP/IP stacks (POSIX_SOCKETS), both over IPv4 and IPv6.

IPv4 and IPv6 can be used simultaneously.

Consult "Networking" in ChorusOS 5.0 Features and Architecture Overview to see the RFC list of the IPv4 and IPv6 protocols that are supported

See ip6(7P) man page for further information.

Chapter 13 Network Administration Commands and Daemons

This chapter explains the various network administration commands that a system administrator of the ChorusOS operating system requires. In this ChorusOS distribution, daemons are located in the directory /sbin, and other commands are in the directory /bin.

Note -

Note that any or all of these commands can be killed using the akill(1M) utility.

chat

The chat utility handles modem connections for use with PPP. See chat(1M), pppd(1M) and pppstart(1M) for more details.

In order to use chat, you must first embed the chat process into the ChorusOS system image.

Embedding the chat process into the ChorusOS system image

You can use Ews, the graphic configuration utility to embed the chat process:

  1. Open the Ews graphic configuration utility:

    host% ews <build_DIR>/conf/ChorusOS.xml &

  2. Select the Application file list node, as follows:

    ChorusOS configuration | ChorusOS System Image Configuration | Applications | Application file

  3. Click on Application File with the right-hand mouse button and select New Element.

  4. Double-click on the Empty file which appears in the Application File. A new window opens in Ews.

  5. Click twice on the Value cell next to Reference in this window, then click on the button marked "..." which appears on its right hand side. This opens a window entitled Select a Reference.

  6. Select chat from the list of options in the Select a Reference window.

  7. Close the Select a Reference window, then select file | save in the Ews graphic configuration tool to save the new settings.

  8. You must now build or re-build the ChorusOS system image:

    host% make chorus

dhclient

The Dynamic Host Configuration Protocol utility, dhclient(1M), allows the ChorusOS system to obtain network information, such as a dynamically assigned IP address, or the IP addresses of the default router and name server, from a DHCP server at boot time. In order to boot using dhclient you must first embed the dhclient process into the ChorusOS system image.

dhclient reads dhclient.cf(4CC) and dhcp.options(4CC).

Embedding the dhclient process into the ChorusOS system image

You can use Ews, the graphic configuration utility to embed the dhclient process:

  1. Open the Ews graphic configuration utility:

    host% ews <build_DIR>/conf/ChorusOS.xml &

  2. Select the Application file list node, as follows:

    ChorusOS configuration | ChorusOS System Image Configuration | Applications | Application file

  3. Click on Application File with the right-hand mouse button and select New Element.

  4. Double-click on the Empty file which appears in the Application File. A new window opens in Ews.

  5. Click twice on the Value cell next to Reference in this window, then click on the button marked "..." which appears on its right hand side. This opens a window entitled Select a Reference.

  6. Select dhclient from the list of options in the Select a Reference window. If necessary, follow the same procedure to select dhclient.cf in order to embed the optional dhclient configuration file.

  7. Close the Select a Reference window, then select file | save in the Ews graphic configuration tool to save the new settings.

  8. By default, ChorusOS boots using RARP. In order to boot using DHCP, you must change the sysadm.ini file. In the sysadm.ini file, you deactivate RARP by making the appropriate line into a comment and you activate DHCP by including the line corresponding to dhclient:

    # rarp ifeth0

    /image/sys_bank/dhclient ifeth0

  9. You must now build or re-build the ChorusOS system image:

    host% make chorus

    Further information on building the system image is supplied with the ChorusOS 5.0 Installation Guide.

See also "The Embedded Workshop Graphical Configuration Tool" for additional guidance on Ews.

gifconfig

Configures the physical address for the generic IPv6 tunnel interface. See gifconfig(1M).

ifconfig

ifconfig(1M) allows you to assign an IP address to a network interface, and to configure network interface parameters. It also allows you to check the interfaces you have configured.

Example 13-1 Configuring and Checking Interfaces with ifconfig

The following interactive example configures the primary Ethernet and loopback interfaces for target, then displays the result.


$ rsh target ifconfig ifeth0 129.157.197.88 netmask 0xffffff00 broadcast 129.157.197.253
$ rsh target ifconfig lo0 127.0.0.1 up
$ rsh target ifconfig -a
ifeth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 129.157.197.88 netmask 0xffffff00 broadcast 129.157.197.253
	ether 00:e0:29:3c:6c:7f 
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet 127.0.0.1 netmask 0xff000000

The example above uses ifconfig command that is built into the C_INIT(1M) system actor. You can also embed the ifconfig command in the sysadm.ini(4CC) system initialization script. ifconfig is also a standalone program.

pppstart

The pppstart(1M) function enables client PPP operations on the ChorusOS system. See Chapter 11, Setting Up PPP for details on configuring a ChorusOS system as a PPP client. In order to use PPP, you have to embed the pppstart process into the ChorusOS system image.

pppstart(1M) uses pppstart(2K). See the sysLog(2K) man page for examples of how to read the log.

Embedding the pppstart process into the ChorusOS system image

You can use Ews, the graphic configuration utility to embed the pppstart process:

  1. Open the Ews graphic configuration utility:

    host% ews <build_DIR>/conf/ChorusOS.xml &

  2. Select the Application file list node, as follows:

    ChorusOS configuration | ChorusOS System Image Configuration | Applications | Application file

  3. Click on Application File with the right-hand mouse button and select New Element.

  4. Double-click on the Empty file which appears in the Application File. A new window opens in Ews.

  5. Click twice on the Value cell next to Reference in this window, then click on the button marked "..." which appears on its right hand side. This opens a window entitled Select a Reference.

  6. Select pppstart from the list of options in the Select a Reference window.

  7. Close the Select a Reference window, then select file | save in the Ews graphic configuration tool to save the new settings.

  8. You must now build or re-build the ChorusOS system image:

    host% make chorus

arp

The arp(1M) utility lets you display and manipulate the tables used to translate IP addresses to Ethernet addresses according to the Address Resolution Protocol (ARP).

Example 13-2 Displaying the ARP Table

The following example displays the IP address/Ethernet address pairs known to a ChorusOS system that have no name service daemons operating:


$ rsh target arp -a

 (129.157.197.144) at 8:0:20:a7:d6:f3

Note that the only system known to the ChorusOS system is the boot server, and that its hostname is not known.

You may also use the ChorusOS rarp(1M) utility that makes it possible to configure the IP address of the ChorusOS system during system initialization from a RARP server on the local network.

gif

The gif interface is a generic tunneling pseudo device for IPv4 and IPv6. See gif(7P).

icmp6

This is the error and control message protocol used by the Internet Protocol family. See icmp6(7P).

inet6

The inet6 family is a collection of protocols layered on top of the ip6(7P) transport layer. The inet6 family provides protocol support for the SOCK_STREAM, SOCK_DGRAM and SOCK_RAW socket types. See inet6(7P).

Used in conjunction with socket. See socket(2POSIX).

netstat

netstat(1CC) displays information about network-related data structures, such as network interfaces (use the -i option) and routing tables (use the -r) option. The utility is available both as a C_INIT(1M) built-in command, and as a standalone actor that supports a wider range of options.

Example 13-3 Displaying Network Statistics with netstat

The following example uses the built-in version of netstat to view information about network interfaces and routing tables.


$ rsh target netstat -i
Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
ifeth 1500  <Link>      00.e0.29.3c.6c.7f       17     0       10     0     0
ifeth 1500  129.157       129.157.197.88        17     0       10     0     0
lo0   16384 <Link>                               0     0        0     0     0
lo0   16384 127           127.0.0.1              0     0        0     0     0
$ rsh target netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
127.0.0.1          127.0.0.1          UH          0        0       lo0
129.157            link#1             UC          0        0 
129.157.197.144    8:0:20:a7:d6:f3    UHLW        3       17    ifeth0   1178

netstat is also available as a stand-alone actor, netstat.

ndp

This command manages the IPv6 Neighbor Discovery Protocol, (NDP). Symbolically displays the contents of the Neighbor Discovery cache. See ndp(1M).

nfsstat

The nfsstat(1CC) command displays statistics about NFS activity between the server and the client. The ChorusOS implementation of this utility supports only the -w option.

Example 13-4 Displaying NFS Activity

The following example displays statistics about NFS activity every second:


$ rsh target nfsstat -w 1
         Getattr   Lookup Readlink     Read    Write   Rename   Access  Readdir
Client:      155       51        0      153        0        0      161        2
Server:        0        0        0        0        0        0        0        0
...

ping

The ChorusOS implementation of ping(1M), a basic tool for checking whether a network connection is working or not, requests an ICMP ECHO_RESPONSE from the specified host and simply displays 


host is alive
if the host responds within 20 seconds.

Example 13-5 Checking a Connection with ping

The following example uses the ping utility to check the connection with the system having IP address 129.157.197.1:


$ rsh target ping 129.157.197.1
129.157.197.1 is alive

The example below shows what happens when the host does not respond:


$ rsh target ping 129.157.197.44
no answer from 129.157.197.44

Note that ping supports options.

ping6

Elicits an ICMP6_ECHO_REPLY from a host or gateway. See ping6(1M).

rpcinfo

The rpcinfo(1M) utility is used to obtain information about RPC services registered through the rpcbind daemon. This utility can be used to see RPC services running on the target or on other hosts.

route

When a system using IP receives a network data packet, it uses the routing table, managed using route(1M), to determine where to send the packet. A properly configured routing table helps the system:

The route command in this version is also IPv6 enabled, to manually manipulate the network routing tables.

IPv4 forwarding allows the system to forward packets to other systems, such as the gateway. IP forwarding is enabled using the sysctl(1M) command as shown in Example 13-6.

Example 13-6 Routing with IPv4 Forwarding

The following example sysadm.ini fragment uses route to configure the routing table to deliver packets addressed to the local system (129.157.197.88), and to forward other packets to the Ethernet:

#
# Enable IP forwarding (requires the sysctl actor)
# sysctl -w net.inet.ip_forwarding=1
# /image/sys_bank/sysctl -w net.inet.ip_forwarding=1 
# if built into system image

#
# Deliver packets addressed to the local system
#
route add -host 129.157.197.88 lo0

#
# Send other packets back out to the Ethernet
#
route add default -interface ifeth0

Note that the first route command is unnecessary if the ChorusOS system IP address is assigned dynamically.

route is also available as a stand-alone actor, route.

tcpdump

This command dumps traffic on a network, and prints out headers of packets. Users must have read access to /dev/bpf*. See tcpdump(1M).

traceroute

This command prints the route packets to take to the network host. It does this by utilizing the IP protocol `time to live' field and by then attempting to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host. See traceroute(1M).

Name Services and ypbind

Name services make it possible to convert between IP addresses and system names.

The most basic name service solution on a ChorusOS system consists of using the information from the /etc/hosts file, or /etc/networks files.

ChorusOS systems usually rely on other systems to provide name services, however.

Example 13-7 Binding to an NIS Server

The following example configures the NIS daemon for the fictitious an.example.COM domain:


$ rsh target domainname an.example.COM
$ rsh target /sbin/rpcbind&
$ rsh target ypbind

Note that the actors in this example are normally found in a file system outside the system image, such as a root file system located on the host. The domain name must be configured before starting ypbind. As you can see from the example, rpcbind must also be started first, to start ypbind.

ypcat

You can use ypcat(1CC), ypmatch(1CC) and ypwhich(1CC) to obtain information from the NIS database if the ChorusOS system is bound to an NIS domain. See "Name Services and ypbind" for details about binding to the NIS server for the domain.

Example 13-8 Reading NIS Information

The following example uses ypcat to find "demo" networks mentioned in the NIS database:


$ rsh target ypcat networks | grep demo
demo                    129.157.171
demo2                   129.157.176

Note that ypcat, ypmatch and ypwhich require access to the NIS database in order to look up information.

ftpd and ftp

The ftpd(1M) function provides File Transfer Protocol services on ChorusOS systems. See also ftp(1CC).

Example 13-9 Sample ftp Session

The following example starts the ftpd server on the ChorusOS system and tests it:


$ rsh target /bin/ftpd &
$ ftp target
Connected to target.
220- Welcome to ChorusOS!
220  FTP server (Version 6.00) ready.
Name (target:user): 
331- Password not checked
331 Login ok.
Password:
230- Logging in with home=/
230 User user logged in.
ftp> ls
ls
200 PORT command successful.
150 Opening ASCII mode data connection for 'file list'.
bin
dev
etc
lib
Makefile
226 Transfer complete
30 bytes received in 0.11 seconds (0.28 Kbytes/s)
ftp> bye
bye
221 Goodbye.
$

Note that target is running in non-secure mode, so no password is required.

tftpd and tftp

This daemon is used if you want to boot the ChorusOS target from the network (using bootmonitor), with the DHCP and TFTP server running on a ChorusOS machine. The tftpd daemon is a standalone daemon. It is not started by the inetd command.

The command tftp is used to transfer files in the same way as ftp. See tftpd(1M).

systcl

The systcl target utility is used to get or set the microkernel state. See sysctl(1M).

mountd

This daemon is the server for NFS mount requests from other client machines. It reads the file /etc/exports(5) to find the list of exported file systems. See mountd(1M).

nfsd

The nfsd(1M) function provides Network File Services to NFS clients on the network. See Chapter 7, Sharing Target File Systems Over NFS for details about running an NFS server on a ChorusOS system.

Network Time Protocol (NTP)

The Network Time Protocol (NTP) public domain software from the University of Delaware is included in this version of the ChorusOS operating system. NTP is a server/client implementation that enables you to manage precise time and network clock synchronization in a network environment. The inclusion of NTP in the ChorusOS operating system provides increased time precision.

Pick one system to be the master clock (NTP server), and then set up all your other systems (NTP clients) to synchronize their clocks with the master clock. This is done using the ntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers.

The ntpd, ntpq, ntpdate and ntptrace utilities are available with the ChorusOS operating system. For further information on these utilities see ntpd(1M), ntpdate(1M), ntpq(1M), ntptrace(1M).

How to Use NTP

The ntpd daemon sets and maintains the system time-of-day.

The ntpd daemon reads the /etc/ntp.conf file at system startup. See ntpd(1M) for information about configuration options of ntpd.

An NTP client synchronizes automatically with an NTP server when it boots, and if it gets out of sync, it will resync again when it sees a time server.

Note -

The method of authentication provided in the NTP implementation of the ChorusOS operating system is MD5.

The only reference clock driver supported is the undisciplined local clock.

Setting up an NTP Client

  1. Become superuser.

  2. Change to the /etc directory.

  3. Copy the ntp.client file to the ntp.conf file: 

    # cp ntp.client ntp.conf

  4. Synchronize the date manually, by using the ntpdate command: 


    # rsh target ntpdate <timeserver>
    where <timeserver> is the NTP server running on the network.

  5. Start the ntpd daemon: 


    # rsh target ntpd

Setting up an NTP Server

  1. Become superuser.

  2. Change to the /etc directory.

  3. Copy the ntp.server file to the ntp.conf file. 

    # cp ntp.server ntp.conf

  4. Start the ntpd daemon: 


    # rsh target ntpd

rpcbind

In order to start RPC services, the rpcbind daemon must be running on the system. The rpcbind daemon is required, for example, by the ypbind daemon and other yp tools, and by the nfsd NFS daemon. The rpcbind path is /bin/rpcbind.

rtsol and rtsold

The rtsold daemon sends ICMPv6 router solicitation messages on specific interfaces. The rtsold daemon sends only one router solicitation message to the specified interface and exits.

Configuring the ChorusOS operating system for IPv6 router solicitation:

  1. Configure the ChorusOS IPv6 stack to accept IPv6 router advertisements:


    host% rsh target sysctl --w net.inet6.ip6.accept_rtadv=1

  2. Send a router solicitation message on the ifeth0 interface. An IPv6 router on the network should answer with a router advertisement message.


    host% rsh target /sbin/rtsolifeth-0

For further information see rtsold(1M) man page. See also the icmp6(7P) and ip6(7P) man pages.

telnetd

The telnetd(1M) daemon enables remote login operations in the ChorusOS operating system using the Telnet virtual terminal protocol. For further information regarding Telnet, see ChorusOS man pages section 3TELD: Telnet Services.

Chapter 14 Configuring IPC

This chapter describes how to configure the IPC feature within the ChorusOS operating system to provide either local IPC communication or remote IPC communication over Ethernet.

Generic IPC Configuration

IPC Feature Configuration

The ChorusOS IPC feature is an optional component of the ChorusOS microkernel that can be added in two different configurations:

  1. Local IPC. This configuration provides only local IPC communications.

  2. Local IPC + remote IPC. This configuration enables local and remote IPC communications to take place over a network data-link such as Ethernet or ATM (Asynchronous Transfer Method). This data-link is also called an external data-link, which means that the data-link driver is implemented within an independent driver outside of the microkernel.

The comand-line configuration tool configurator(1CC) is used to set up each configuration.

To configure the local IPC feature:


% configurator -set IPC=true

To configure the local IPC + remote IPC feature:


% configurator -set IPC_REMOTE=true

Site Number Administration

The IPC feature has the concept of a site number, a 32-bit unsigned integer that uniquely identifies a target board. Applications exchange messages through IPC ports, which are designated by a global identifier that includes the site number of the target board where the port is located.

The site number of a target is sent to the microkernel at boot time in one of two ways:

  1. dynamically, by the boot program, which sets the siteNumber field of the bootConf structure before invoking the microkernel start entry.

  2. statically, by setting the chorusSiteId microkernel tunable in the ChorusOS system image built on the host:


    % configurator -set chorusSiteId=n

    n is the site number assigned to the target board. This number can be specified in hexadecimal, by prefixing the number with 0x, or decimal.

When the site number is set dynamically, it is the responsibility of the boot program to determine the site number of the target. The method by which the site number is found by the boot program is fully boot dependent, and specific to the target board. It may, for example, be stored in NVRAM, dynamically generated from a unique board identifier. When the target is booted with the standard ChorusOS network boot monitor, the whole IP address used by the boot monitor is provided as the site number of the target.

When the site number is set statically, the site number is fixed within the system image. This approach is less flexible than the dynamic method because the same system image cannot be booted on similar target boards. A system image with a unique site number must be built for each target. For this reason, it should only be used when there is no way for the boot program to determine the site number of the target board.

Note -

The value of the site number set with the chorusSiteId tunable takes precedence over the value of the site number provided by the boot program.

The site number is set to zero by default. If the IPC_REMOTE feature has been enabled, and the site number remains at zero, the following message is displayed on the system console:

WARNING - LOCAL SITE ID. NOT SET => REMOTE IPC disabled

Only local IPC communications are enabled if the site number has not been set.

Specific IPC Configuration

Remote IPC over Ethernet Data-link

To configure the remote IPC over Ethernet feature, set the IPC_REMOTE feature to true. In addition, switch on the IOM_IPC feature:


% configurator -set IOM_IPC=true

This adds the Ethernet-specific module into the C_OS component which acts as the IPC Ethernet data-link driver.

Once you have built and booted the ChorusOS system image on the target board tgtbd1, the IPC Ethernet data-link can be dynamically started. Use the built-in ethIpcStackAttach command of C_INIT (running on the target board tgtbd1) :


% rsh tgtbd1 ethIpcStackAttach ethernet-device-name

The ethernet-device-name argument is the name of the Ethernet device with which your remote IPC stack will communicate. This name is the full pathname of the Ethernet device in the target device tree, displayed on the target system console by the system at boot time. For example, a genesis2 board with a dec21140 Ethernet controller connected through a raven PCI bridge, has the pathname /raven/pci1011,9@e,0. This argument is only needed when the target board has more than one Ethernet controller.

See the ethIpcStackAttach(1M) man page for more details.

The following example describes how to build a ChorusOS system image for two similar PowerPC-based target boards, tgtbd1 and tgtbd2, each with an Ethernet controller. Site numbers must be unique and statically configured in each ChorusOS system image.

  1. Configure Remote IPC over Ethernet, if not already configured:


    % configurator -set IPC=true
% configurator -set IPC_REMOTE=true% configurator -set IOM_IPC=true

  2. Assign a site number to tgtbd1, then build and uniquely identify the ChorusOS system image:


    % configurator -set chorusSiteId=1
% make chorus
% mv chorus.RAM chorus.RAM.tgtbd1

    Assign a site number to tgtbd2, then build and uniquely identify the ChorusOS system image:


    % configurator -set chorusSiteId=2
% make chorus
% mv chorus.RAM chorus.RAM.tgtbd2

  3. Once you have booted the chorus.RAM.tgtbd1 system image on tgtbd1 and the chorus.RAM.tgtbd2 system image on tgtbd2, run the ethIpcStackAttach command:


    % rsh tgtbd1 ethIpcStackAttach
% rsh tgtbd2 ethIpcStackAttach

Applications that need to communicate through remote IPC can now be launched on the tgtbd1 and tgtbd2 targets.