This section introduces the network protocols, libraries, and commands offered by the ChorusOS operating system. For full details of networking with the ChorusOS operating system, see the ChorusOS 5.0 System Administrator's Guide.
The ChorusOS operating system provides TCP/IP and UDP/IP stacks (POSIX-SOCKETS), both over IPv4 and IPv6.
IPv4 and IPv6 can be present and used simultaneously.
IPv4 provides the host capabilities as defined by the Internet Engineering Task Force (IETF). The following IPv4 protocols are supported:
IPv4 RFC |
Description |
---|---|
RFC 1122 |
Requirements for Internet Hosts, Communication Layers |
RFC 1123 |
Requirements for Internet Hosts, Application and Support |
RFC 791 |
Internet Protocol |
RFC 792 |
Internet Control Message Protocol |
RFC 768 |
User Datagram Protocol |
RFC 793 |
Transmission Control Protocol |
RFC 2236 |
Internet Group Multicast Protocol |
RFC 950 |
Internet Standard Subnetting Procedure |
RFC 1058 |
Routing Information Protocol |
RFC 1112 |
Host Extensions for IP Multicast |
RFC 854 |
Telnet Protocol Specification |
RFC 855 |
Telnet Option Specification |
RFC 959 |
File Transfer Protocol |
RFC 783 |
TFTP Protocol |
RFC 1350 |
The TFTP Protocol (Revision 2) |
RFC 1034 |
Domain Names - Concepts and Facilities |
RFC 1035 |
Domain Names - Implementation and Specification |
RFC 1055 |
Transmission of IP over Serial Lines |
RFC 826 |
Address Resolution Protocol |
RFC 903 |
A Reverse Address Resolution Protocol |
RFC 1661 |
Point-to-Point Protocol |
RFC 1570 |
PPP LCP Extensions |
RFC 2131 |
Dynamic Host Configuration Protocol |
RFC 951 |
Bootstrap Protocol |
RFC 1497 |
BOOTP Vendor Information Extensions |
RFC 1532 |
Clarifications and Extensions for the Bootstrap Protocol |
RFC 1577 |
Classical IP and ARP over ATM |
RFC 2453 |
RIP Version 2 |
The following IPv6 RFCs are supported:
IPv6 RFC |
Description |
---|---|
RFC 1981 |
Path MTU Discovery for IPv6 |
RFC 2292 |
Advanced Sockets API for IPv6 |
RFC 2373 |
IPv6 Addressing Architecture: supports node required addresses, and conforms to the scope requirement. |
RFC 2374 |
An IPv6 Aggregatable Global Unicast Address Format supports 64-bit length of Interface ID |
RFC 2375 |
IPv6 Multicast Address Assignments Userland applications use the well known addresses assigned in the RFC |
RFC 2460 |
IPv6 specification |
RFC 2461 |
Neighbor discovery for IPv6 |
RFC 2462 |
IPv6 Stateless Address Autoconfiguration |
RFC 2463 |
ICMPv6 for IPv6 specification |
RFC 2464 |
Transmission of IPv6 Packets over Ethernet Networks |
RFC 2553 |
Basic Socket Interface Extensions for IPv6. IPv4 mapped address and special behavior of IPv6 wild card bind socket are supported |
RFC 2675 |
IPv6 Jumbograms |
RFC 2710 |
Multicast Listener Discovery for IPv6 |
The following utilities are available with IPv6 functionality:
Command |
Description |
---|---|
ifconfig |
Assign address to network interface and configure interface parameters |
netstat |
Symbolically displays contents of various network-related data structures |
ndp |
Symbolically displays the contents of the Neighbor Discovery cache |
route |
Manually manipulate the network routing tables |
ping6 |
Elicit an ICMP6_ECHO_REPLY from a host or gateway |
rtsol |
Send only one Router Solicitation message to the specified interface and exit |
rtsold |
Send ICMPv6 Router Solicitation messages to the specified interfaces |
gifconfig |
Configures the physical address for the generic IP tunnel interface |
ftp |
Transfer files to and from a remote network site |
tftp |
Transfer files to and from a remote machine |
For a full description of the implementation of IPv6 in the ChorusOS operating system, see "IPv6 and the ChorusOS System" in ChorusOS 5.0 System Administrator's Guide.
The PPP feature allows serial lines to be used as network interfaces using the Point-to-Point Protocol. This feature needs to be configured for the ChorusOS operating system to fully support the various PPP-related commands provided by the ChorusOS system. These PPP-related commands are listed below:
Enables client PPP connections
Disables PPP services on the system by killing the pppstart daemon
Requests that the pppstart daemon close a previously opened PPP line
Starts a PPP line
These services are complemented by chat(), which defines a conversational exchange between the computer and the modem. Its primary purpose is to establish the connection between the Point-to-Point Protocol daemon (pppd) and a remote pppd process.
The PPP feature does not export any APIs itself. It simply adds support of the PPP ifnet to the system.
For details, see the PPP(5FEA) man page.
The Network Time Protocol is implemented in the ChorusOS operating system as a set of daemons and commands whose purpose is to synchronize dates for different ChorusOS operating systems.
The NTP feature does not provide any specific API and relies on the following utilities and daemons:
Client/server daemon. The server feature provides a reference clock available to all systems on the network. The client feature is used to compute a clock according to other sources and keep the system clock synchronized with it.
Determines where a given NTP server gets its time, and follows the chain of NTP servers back to their master time source.
The Network Time Protocol Query Program dynamically gets or sets the ntpd configuration.
Sets the local date from the one provided by a remote NTP server
NTP services rely on the adjtime() system call.
The ChorusOS operating system supports the client side of the NTP protocol (RFC 1305).
The BPF
feature provides a raw interface to
data link layers in a protocol independent fashion. All packets on the network,
even those destined for other hosts, are accessible through this mechanism.
It must be configured when using the Dynamic Host Configuration Protocol (DHCP)
client (dhclient(1M)).
For details, see the BPF(5FEA) man page.
The ChorusOS operating system supports DHCP as a client and as a server. The ChorusOS boot framework has also been enhanced so that it can use the DHCP protocol to retrieve the system image and boot it on the local node, provided there is a correctly configured DHCP server on the network. The client side of DHCP is provided by the ChorusOS dhclient(1M) utility.
The ChorusOS operating system supports both NFSv2 and NFSv3, from client and server points of view. This is described in "Network File System (NFS)".
NFS works over TCP or UDP on IPv4.
The IOM_IPC
feature provides support for the ethIpcStackAttach(2K) system call and the corresponding
built-in C_INIT(1M)
command, ethIpcStackAttach. If the feature is not configured,
the ethIpcStackAttach(2K) system call of the built-in C_INIT
command will display an error message.
If the IOM_IPC
feature is set to true, an IPC stack is included in the IOM system actor. The IPC stack may be attached
to an Ethernet interface.
For details, see the IOM_IPC(5FEA) man page.
The IOM_OSI
feature provides support for the ethOSIStackAttach(2K) system call.
If the IOM_OSI
feature is set to true, an OSI stack is included in the IOM system actor. The OSI stack may be attached
to an Ethernet interface.
For details, see the IOM_OSI(5FEA) man page.
The POSIX_SOCKETS feature is explained in "POSIX Sockets (POSIX_SOCKETS)".
This section describes the network libraries provided with the ChorusOS product.
The RPC library is compatible with Sun RPC, also known as ONC+. Extensions have been introduced into the library provided with the ChorusOS operating system, as well as into the Solaris operating environment, to support asynchronous communication.
The RPC library calls are available with the POSIX_SOCKETS feature. These calls support multithreaded applications. This feature is simply a library that might or might not be linked to an application. It is not a feature that can be turned on or off when configuring a system.
For details about RPC in the ChorusOS operating system, see RPC(5FEA).
The Lightweight Directory Access Protocol (LDAP) provides access to X.500 directory services. These services can be a stand-alone part of a distributed directory service. Both synchronous and asynchronous APIs are provided. Also included are various routines to parse the results returned from these routines.
The basic interaction is as follows. Firstly, a session handle is created. The underlying session is established upon first use, which is commonly an LDAP bind operation. Next, other operations are performed by calling one of the synchronous or asynchronous search routines. Results returned from these routines are interpreted by calling the LDAP parsing routines. The LDAP association and underlying connection is then terminated. There are also APIs to interpret errors returned by LDAP server.
The LDAP API is summarized in the following table:
Function |
Description |
---|---|
ldap_add() |
Perform an LDAP adding operation |
ldap_init() |
Initialize the LDAP library |
ldap_open() |
Open a connection to an LDAP server |
ldap_get_values() |
Retrieve attribute values from an LDAP entry |
ldap_search_s() |
Perform synchronous LDAP search |
ldap_search_st() |
Perform synchronous LDAP search, with timeout |
ldap_abandon() |
Abandon an LDAP operation |
ldap_abandon_ext() |
Abandon an LDAP operation |
ldap_delete_ext() |
Perform an LDAP delete operation |
ldap_delete_ext_s() |
Perform an LDAP delete operation synchronously |
ldap_control_free() |
Dispose of a single control or an array of controls allocated by other LDAP APIs |
ldap_controls_free() |
Dispose of a single control or an array of controls allocated by other LDAP APIs |
ldap_extended_operation_s() |
|
ldap_msgtype() |
Returns the type of an LDAP message |
ldap_msgid() |
Returns the ID of an LDAP message |
ldap_count_values() |
Count number of values in an array |
ldap_explode_dn() |
Takes a domain name (DN) as returned by ldap_get_dn() and breaks it into its component parts |
ldap_dn2ufn() |
Turn a DN as returned by ldap_get_dn() into a more user- friendly form |
ldap_explode_dns() |
Take a DNS-style DN and break it up into its component parts |
ldap_dns_to_dn() |
Converts a DNS domain name into an X.500 distinguished name |
ldap_value_free() |
Free an array of values |
ldap_is_dns_dn() |
Returns non-zero if the DN string is an experimental DNS-style DN |
ldap_explode_rdn() |
Breaks an RDN into its component parts |
ldap_bind() |
Perform an LDAP bind operation |
ldap_bind_s() |
Perform an LDAP bind operation synchronously |
ldap_simple_bind() |
Initiate asynchronous bind operation and return message ID of the request sent |
ldap_simple_bind_s() |
Initiate synchronous bind operation and return message ID of the request sent |
ldap_sasl_cram_md5_bind_s() |
General and extensible authentication over LDAP through the use of the Simple Authentication Security Layer (SASL) |
ldap_init() |
Allocates an LDAP structure but does not open an initial connection |
ldap_modify_ext_s() |
Perform an LDAP modify operation |
ldap_modrdn_s() |
Perform an LDAP modify RDN operation synchronously |
ldap_search() |
Perform LDAP search operations |
For details, see the ldap(3LDAP) man page.
The FTP utility is the user interface to the ARPANET standard File Transfer Protocol. The program allows a user to transfer files to and from a remote network site.
The FTP API is summarized in the following table:
Function |
Description |
---|---|
ftpd() |
Internet File Transfer Protocol server |
ftpdStartSrv() |
Initializes FTP service |
ftpdHandleCnx() |
Manages an FTP connection |
lreply() |
Reply to an FTP client |
perror_reply() |
Reply to an FTP client |
reply() |
Reply to an FTP client |
ftpdGetCnx() |
Accepts a new FTP connection |
ftpdOob() |
Check for out-of-band data on the control connection |
For details, see the ChorusOS man pages section 3FTPD: FTP Daemon Library.
You can perform remote login operations on the ChorusOS operating system using the Telnet virtual terminal protocol. The Telnet API is summarized in the following table:
Function |
Description |
---|---|
inetAccept() |
Wait for a new INET connection |
inetBind() |
Bind, close INET sockets |
inetClient() |
Wait for a new INET connection |
inetClose() |
Bind, close INET socket |
telnetdFlush() |
Write or flush a Telnet session |
telnetdFree() |
Initialize or free a Telnet session |
telnetdGetTermState() |
Get or set Telnet terminal state |
telnetdInit() |
Initialize or free a Telnet session |
telnetdPasswd() |
Telnet session authentication |
telnetdRead() |
Read from a Telnet session |
telnetdReadLine() |
Read a line of characters from a Telnet session |
telnetdSetTermState() |
Get or set Telnet terminal state |
telnetdUser() |
Telnet session authentication |
telnetdWrite() |
Write or flush a Telnet session |
See the ChorusOS man pages section 3TELD: Telnet Services.
The ChorusOS operating system offers the following network commands:
Table 3-1 ChorusOS Network Commands
Command |
IPv4 Compatible |
IPv6 Compatible |
---|---|---|
arp |
Yes |
N/A |
ftp |
Yes |
Yes |
ftpd |
Yes |
No |
gifconfig |
Yes |
Yes |
ifconfig |
Yes |
Yes |
ndp |
No |
Yes |
netstat |
Yes |
Yes |
nfsd |
Yes |
No |
nfsstat |
Yes |
No |
ping |
Yes |
N/A |
ping6 |
N/A |
Yes |
pppstart |
Yes |
No |
route |
Yes |
Yes |
rpcbind |
Yes |
Yes |
rpcinfo |
Yes |
Yes |
teld |
Yes |
No |
tftpd |
Yes |
Yes |
ypcat |
Yes |
No |
ypmatch |
Yes |
No |
ypwhich |
Yes |
No |
dhclient |
Yes |
No |
dhcpd |
Yes |
No |
ntpd |
Yes |
No |
ntpdate |
Yes |
No |
ntpq |
Yes |
No |
tcpdump |
Yes |
Yes |
rtsol |
N/A |
Yes |
rtsold |
N/A |
Yes |
traceroute |
Yes |
No |
Naming services in the ChorusOS operating system are provided by DNS and NIS.
The Domain Name System (DNS) commands provide a standard, stable and robust architecture used for the naming architecture on the Internet Protocol. DNS is used widely on the Internet.
Name resolution is ensured by DNS servers (named), one of which is the primary server. This server reads the name records stored in a database on disk (this database file is managed by the administrator). The other servers are secondary, which means that they acquire the name records from the primary server, and do not read them from the main database file. However, these secondary servers may store records in a cache file on disk to improve restart performances. These cache files are not intended to be edited manually. The user program performs the name resolution by sending queries to DNS name servers. Generally, each host is configured such that it knows the addresses of all name servers (primary and secondary).
The ChorusOS operating system can also be bound to a Network Information Service (NIS) database.
The naming service API is summarized in the following table:
Command |
Description |
---|---|
named |
DNS server |
named-xfer |
Perform an inbound zone transfer |
gethostbyname |
Convert name into IP address |
gethostbyaddress |
Convert IP address into name |
gethostbyname2 |
Perform lookups in address families other than AF_INET |
gethostbyaddr |
Get network host entry from IP address |
gethostent |
Reads /etc/hosts, and opens file if necessary |
sethostent |
Opens and/or rewinds /etc/hosts |
endhostent |
Closes the file |
herror |
Print an error message describing a failure |
hstrerror |
Returns a string which is the message text corresponding to the value of the err parameter |
getaddrinfo |
Protocol-independent nodename-to-address translation |
freeaddrinfo |
Frees structure pointed to by the ai argument |
gai_strerror |
Returns a pointer to a string describing a given error code |
getnetent |
Get network entry |
getnetbyaddr |
Search for net name by address |
getnetbyname |
Search for net address by name |
setnetent |
Opens and rewinds the file |
endnetent |
Closes the file |