Spru 524 A

TMS320C6000 TCP/IP
Network Developer’s Kit (NDK)

Programmer’s Reference Guide
Literature Number: SPRU524A

October 2001
Printed on Recycled Paper

IMPORTANT NOTICE
Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections,
modifications, enhancements, improvements, and other changes to its products and services at
any time and to discontinue any product or service without notice. Customers should obtain the
latest relevant information before placing orders and should verify that such information is current
and complete. All products are sold subject to TI’s terms and conditions of sale supplied at the
time of order acknowledgment.
TI warrants performance of its hardware products to the specifications applicable at the time of
sale in accordance with TI’s standard warranty. Testing and other quality control techniques are
used to the extent TI deems necessary to support this warranty. Except where mandated by
government requirements, testing of all parameters of each product is not necessarily performed.
TI assumes no liability for applications assistance or customer product design. Customers are
responsible for their products and applications using TI components. To minimize the risks
associated with customer products and applications, customers should provide adequate design
and operating safeguards.
TI does not warrant or represent that any license, either express or implied, is granted under any
TI patent right, copyright, mask work right, or other TI intellectual property right relating to any
combination, machine, or process in which TI products or services are used. Information
published by TI regarding third party products or services does not constitute a license from TI
to use such products or services or a warranty or endorsement thereof. Use of such information
may require a license from a third party under the patents or other intellectual property of that third
party, or a license from TI under the patents or other intellectual property of TI.
Reproduction of information in TI data books or data sheets is permissible only if reproduction

is without alteration and is accompanied by all associated warranties, conditions, limitations, and
notices. Reproduction of this information with alteration is an unfair and deceptive business
practice. TI is not responsible or liable for such altered documentation.
Resale of TI products or services with statements different from or beyond the parameters stated
by TI for that product or service voids all express and any implied warranties for the associated
TI product or service and is an unfair and deceptive business practice. TI is not responsible or
liable for any such statements.
Mailing Address:
Texas Instruments
Post Office Box 655303
Dallas, Texas 75265
Copyright  2001, Texas Instruments Incorporated

Preface
Read This First
About This Manual

This programmer’s guide is intended to aid the development of network ap-
plications and describes the various API functions provided by the stack li-
braries. It will be the central reference document used when programming the
stack. Users should first refer to the TMS320C6000 TCP/IP Network Develop-
er’s Kit (NDK) User’s Guide (SPRU523) to familiarize themselves with the
stack libraries and in using the stack with DSP/BIOS and Code Composer
Studio.
How to Use This Manual

This document contains the following chapters:
- Chapter 1 – Introduction, summarizes the various API sets described in

the NDK documentation.
- Chapter 2 – Operating System Abstraction API, describes the API used

by the adaptation layer to access the operating system.
- Chapter 3 – Sockets and Stream IO API, describes the file and sockets
API functions.
- Chapter 4 – Initialization and Configuration, describes the TCP/IP

stack initialization and configuration, including the Configuration Manager
API and the Network Control module.
- Chapter 5 – Network Tools LIbrary Support Functions, describes the

network support functions contained in the NETTOOLS library.
- Chapter 6 – Network Tools Library Services, describes the network

servers and services contained in the NETTOOLS library.
- Appendix A – Internal Stack Functions, contains a partial list of internal

stack functions provided to aid in the comprehension of kernel oriented
calls.
Read This First iii

Related Documentation From Texas Instruments
Text Conventions
- Appendix B – Network Address Translation, describes the optional

Network Address Translation component, how to set up virtual networks,
and protocol proxies.
- Appendix C – Point to Point Protocol, describes the operation of the

PPP and PPPoE support API included in the TCP/IP stack, and how to in-
terface a serial device.
- Appendix D – Hardware Abstraction Layer (HAL), describes the opera-

tion of the HAL, and the HAL API functions.
- Appendix E – Web Programming with the HTTP Server, describes how

to get information from an embedded network device through the web
server.
Related Documentation From Texas Instruments
The following reference is provided for further information:
TMS320C6000 TCP/IP Network Developer’s Kit (NDK) User’s Guide

(literature number SPRU523)
TMS320C6000 TCP/IP Network Developer’s Kit (NDK) Porting Guide

(literature number SPRU030)
TMS320C6000 TCP/IP Network Developer’s Kit (NDK) Technical Data

Quick Reference Guide (literature number SPRU568)
Text Conventions
The following typographical conventions are used in this specification:
- Text inside back-quotes (‘‘) represents pseudo-code
- Program source code, function and macro names, parameters, and com-
mand line commands are shown in a mono-spaced font.
Trademarks
TMS320C6000, Code composer Studio, and DSP/BIOS are trademarks of

Texas Instruments.
iv
Contents
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.2 Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
2 Operating System Abstraction API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1 Operating System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.2 Task Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.3 Semaphore Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.4 Memory Allocation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.5 Print and Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.6 File I/O Support for Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
3 Sockets and Stream IO API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 File Descriptor Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.2 File Descriptor Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.3 Sockets Programming Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3.4 Full Duplex Pipes Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34
4 Initialization and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2 Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.3 Network Control Initialization Procedure (NETCTRL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.4 Configuration Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
5 Network Tools Library Support Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1 Generic Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.2 DNS Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.3 TFTP Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
6 Network Tools Library Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 Service Calling Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.2 Telnet Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.3 DHCP Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
6.4 DHCP Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
6.5 HTTP Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.6 DNS Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
6.7 Network Address Translation (NAT) Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
v
Contents
A Internal Stack Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

A.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
A.2 Stack Executive (Exec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
A.3 Packet (Pkt) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
A.4 Packet Fragment (Frag) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14
A.5 Link Layer Address (LLA) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20
A.6 Link Layer Information (LLI) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22
A.7 Interface (IF) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24
A.8 Ether Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28
A.9 Binding Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-32
A.10 Timer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34
A.11 Route Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-36
A.12 Route Control Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-46
A.13 Configuring the Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-50
A.14 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-57
A.15 Obtaining Stack Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-59
B Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

B.1 NAT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
B.2 NAT Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
B.3 NAT Proxy Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20
C Point to Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

C.1 Low-Level PPP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
C.2 Serial HDLC Client and Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-14
C.3 PPPoE Client and Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-20
C.4 Creating PPP Sever User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-25
D Hardware Abstraction Layer (HAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

D.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2
D.2 Low-Level Timer Driver (llTimer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
D.3 Low-Level Packet Driver (llPacket) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5
D.4 Low-Level Serial Port Driver (llSerial) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-10
E Web Programming with the HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

E.1 Adding WEB Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2
E.2 Writing CGI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-4
E.3 CGI Function Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-7
E.4 HTTP Sever Exported Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-11
vi
Figures
Figures
A–1 Packet and Packet Fragment Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
A–2 FRAG Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
B–1 Basic Home Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
B–2 Public Servers on the Home Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
C–1 Standard PPP Frame Over Serial Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
C–2 PPP Frame Processed by PPP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
C–3 Serial Interface (SI) Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3
Contents vii
Chapter 1
Introduction
This chapter serves as an introduction to the programming API reference for

the TMS320C6000 TCP/IP Network Developer’s Kit (NDK).
Topic Page
1.1 This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

1.2 Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1-1
This Document
1.1 This Document

This Programmer’s Reference Guide for the TCP/IP Stack Network Develop-
er’s Kit (NDK) is mainly a programming API reference guide. It is intended to
aid in the development of network applications and describes the various API
functions provided by the stack libraries.
1.1.1 Supplemental API Information

The following information appears as appendices to this document. These
sections contain optional information that may be useful in understanding the
low-level application interface, but is not required when developing traditional
network applications.
- Appendix A: Internal TCP/IP Stack Library Functions

The stack library internal function specification describes a subset of the
low level programming interface to the stack. These functions allow the
application writer to make use of kernel level function APIs. As a general
rule, it is not necessary to use this API for application development, al-
though some of this sample application included in the NDK make these
use of these function calls.
- Appendix B: Network Address Translation

The stack library includes Network Address Translation module. This ap-
pendix describes the operational theory of NAT, and how to use the NAT
functions included in the library.
- Appendix C: Point to Point Protocol

The stack library has internal device sections for both traditional Ethernet,
and PPP. The PPP module can act as PPP client, server, or both (assum-
ing multiple interfaces). This appendix describes the operation of the PPP
module, the PPP over Ethernet (PPPoE) module, and how to interface an
HDLC based serial device. More information on the serial interface is sup-
plied in the NDK Porting Guide.
- Appendix D: Hardware Abstraction Layer

Appendix D describes the hardware and operating system interfaces used
by the stack. It also illustrates how the device layer may be ported to a new
hardware platform. However, the NDK Porting Guide is the primary source
of information used when porting the stack library to a new platform.
- Appendix E: Web Programming with the HTTP Server

Included with the NDK is a standard set of network services, including a
HTTP protocol server. This server includes support for an embedded file
1-2
Additional Documentation
system and CGI POST functionality. This appendix describes how to add
web page content and CGI functions to a network application using the
HTTP server, including documenting the HTTP server’s web content API.
1.2 Additional Documentation

The following additional documents are also available.
1.2.1 TMS320C6000 TCP/IP NDK User’s Guide

Although this Programmer’s Reference Guide will be the central reference
document used when programming the stack, users should first refer to the
TCP/IP NDK User’s Guide to familiarize themselves with the stack libraries,
and in using the stack with DSP/BIOS and Code Composer Studio.
The TCP/IP NDK User’s Guide contains the following information about the
TCP/IP NDK:
- TCP/IP NDK Installation and Test
- Running the Example Applications
- TCP/IP Stack Library Overview
- Network Application Development
1.2.2 TMS320C6000 TCP/IP NDK Porting Guide

The NDK Porting Guide describes the inner workings of the individual stack
layers.
The TCP/IP stack is designed to be executed in different operating modes with

varying types of scheduling and exclusion methods. The NDK Porting Guide
describes the NETCTRL and OS layers of the stack and how to adjust them
to fit any environment.
The stack is hardware dependent at its HAL and SERIAL interface layers, but
even these layers are divided into hardware dependent and independent por-
tions. The NDK Porting Guide describes these layers, and discusses how to
port device drivers for Ethernet, system timers, and serial devices.
Introduction 1-3
Chapter 2
Operating System Abstraction API
In order to keep the stack system portable, it was coded to a very compact Op-
erating System Abstraction. The stack can execute in any operating environ-
ment by porting the functions described here. Most of these functions will map
directly to a native OS counterpart.
Applications programmers that program to this API are assured that their ap-
plications will execute on any system to which this abstraction is ported.
Topic Page
2.1 Operating System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.2 Task Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
2.3 Semaphore Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.4 Memory Allocation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.5 Print and Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.6 File I/O Support for Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . 2-17
2-1
Operating System Configuration
2.1 Operating System Configuration
2.1.1 Synopsis
The OS has a couple of configuration options that regulate its behavior. These
are stored in a data structure. The types of properties defined in the structure
are those that would typically be macros, but using a data structure allows the
values to be changed without rebuilding the libraries.
The structure is described here for completeness, but applications should use
the configuration system to make alterations to these values. The configura-
tion system is described later in this document.
2.1.2 Configuration Structure
The stack internal configuration structure is _oscfg. Any element in this struc-
ture may be modified before the system is booted. System initialization is cov-
ered later in this document.
The _oscfg structure of type OSENVCFG, which is defined as follows:

// Configuration Structure
typedef struct _osenvcfg {
uint DbgPrintLevel; // Debug message print threshold
uint DbgAbortLevel; // Debug message sys abort threshold
int TaskPriLow; // Lowest priority for stack task
int TaskPriNorm; // Normal priority for stack task
int TaskPriHigh; // High priority for stack task
int TaskPriKern; // Kernel–level priority (highest)
int TaskStkLow; // Minimum stack size
int TaskStkNorm; // Normal stack size
int TaskStkHigh; // Stack size for high volume tasks
} OSENVCFG;
The structure entries as defined as follows:
_oscfg.DbgPrintLevel Debug Message Print Threshold
Default Value DBG_INFO
Description This is the lowest severity level of a system debug message (call to DbgPrintf()
function) that will be recorded into the debug log. The threshold may be raised.
The legal values for this variable are: DBG_INFO, DBG_WARN,
DBG_ERROR, and DBG_NONE.
2-2
_oscfg.DbgAbortLevel Debug Message Abort Threshold
Default Value DBG_ERROR

Description This is the lowest severity level of a system debug message (call to DbgPrintf()
function) that will result in a system shutdown (call to NC_NetSop()). The
threshold may be raised. The legal values for this variable are: DBG_INFO,
DBG_WARN, DBG_ERROR, and DBG_NONE.
_oscfg.TaskPriLow Priority Level for Low Priority Stack Task
Default Value 3
Description This is the priority at which low priority stack task threads are set. Setting a
thread to a lower priority than this will not disrupt the system, but no system
or service supplied in this package will attempt it.
_oscfg.TaskPriNorm Priority Level for Normal Priority for Stack Task
Default Value 5
Description This is the priority at which most stack task threads are set. Task threads that
are created by the system or services will usually run at this level.
_oscfg.TaskPriHigh Priority Level for High Priority for Stack Task
Default Value 7
Description This is the priority at which high priority stack task threads are set. Setting a
thread at a higher priority than this may disrupt the system and cause unpre-
dictable behavior if the thread calls any stack related functions. High priority
tasks (like interrupts) can execute at higher priority levels, but should signal
lower priority tasks to perform any required stack functions.
_oscfg.TaskPriKern Priority Level of High Priority Kernel Tasks
Default Value 8
Description This is the priority that tasks threads execute at when they are inside the ker-
nel. Setting tasks to this priority level ensures that they will not be disrupted
by another task calling stack functions. The proper method of entering the ker-
nel is to call llEnter() and llExit(). This functions are discussed in the appen-
dices, as they are not required for the applications programmer.
Operating System Abstraction API 2-3

_oscfg.TaskStkLow Minimum Task Stack Size
Default Value 3072
Description This is the stack size used for network task that do very little network process-
ing, or do not use TCP.
_oscfg.TaskStkNorm Normal Task Stack Size
Default Value 4096
Description This is the stack size used for a network task with an average network band-
width using TCP. It is used for the majority of network tasks in the network tools
library that use TCP.
_oscfg.TaskStkHigh High Volume Task Stack Size
Default Value 5120
Description This is the stack size used to network tasks that require a high network band-
width using TCP. It is also used for tasks calling HTTP CGI functions.
2-4
Task Support
2.2 Task Support

2.2.1 Synopsis
The task object provides a method of manipulating task threads using a gener-
ic task handle. Task threads are executed on a priority based method, with a
least–recently–run algorithm used on those with equal priority. Each task
thread has its own private stack.
2.2.2 Function Overview

The Task Object access functions (in functional order) are as follows:
TaskCreate() Create new task thread
TaskDestroy() Destroy a task thread
TaskSelf() Get handle to current task thread
TaskExit() Exit (terminate) current task thread
TaskYield() Yield to another task thread at the same priority
TaskSleep() Block a task thread for a period of time
TaskBlock() Block a task thread
TaskSetPri() Set task thread priority level
TaskGetPri() Get task thread priority level
TaskSetEnv() Assign one of three private environment handles to
task thread
TaskGetEnv() Retrieve one of three private environment handles
2.2.3 Task API Functions
TaskBlock Block Task From Execution
Syntax void TaskBlock( HANDLE hTask );

Parameter(s) hTask Handle to target task
Return Value nothing
Description Permanently blocks the specified task from execution.
Calling this function may cause a task switch.
TaskCreate Create a Task Thread
Syntax HANDLE TaskCreate( void(*pFun)(), char *Name, int Priority, uint Stack-
Size,UINT32 Arg1, UINT32 Arg2, UINT32 Arg3 );
Parameter(s) pFun Pointer to task entry-point function
Name NULL terminated task name (truncated after 11 characters)

Task Support
Priority Task priority level (0–15)

StackSize Task stack size
Arg1 Optional task function argument 1
Return Value Returns a Task Handle on success or NULL on memory failure.
Description Creates a new task object. If successful, TaskCreate() returns a handle to the
newly created task.
The task name supplied in Name is used for informational purposes only, and
does not need to be unique.
The task priority specified in Priority determines the task thread’s priority rela-
tive to other tasks in the system. The value of Priority is constrained only by
the size of an int on the target environment, but a range of 0 to 15 is recom-
mended. 0 is the lowest priority and should be reserved for an idle task. If the
specified priority is negative, the task is blocked.
The task stack size specified by StackSize is not examined or adjusted by the
create function. The size should be made compatible with the native environ-
ment (a multiple of 4 bytes should be sufficient).
Arg1 through Arg3 are optional arguments that can be passed to the calling
function (they are always pushed onto the stack, but the task function need not
reference them).
There is no limit to the number of tasks that can be installed in the system. The
only possible failure on TaskCreate() is a memory allocation error.
If the priority level of the new task is higher than the priority level of the current
task. The entrypoint function pFun is executed immediately (before Task-
Create() returns to the caller).
2-6
Task Support
TaskDestroy Destroy a Task Thread
Syntax void TaskDestroy( HANDLE hTask );

Description Terminates execution of the task object specified by the supplied handle
hTask, and frees task object from system memory. Note that memory allocated
by the task thread is not associated with the task thread and must be freed
manually by the programmer.
TaskExit Exit a Task Thread
Syntax void TaskExit();

Parameter(s) none
Return Value Does not return
Description This function is used to gracefully exit a task thread. It should always be called
immediately before the task entry-point function is about to return, but it may
be called from anywhere.
TaskGetEnv Get Task Environment Handle
Syntax HANDLE TaskGetEnv( HANDLE hTask, int Slot );

Slot Environment slot to use (1–3)
Return Value Private environment handle or NULL
Description NOTE: This function is currently not available under DSP/BIOS
Returns a private environment handle for the supplied task handle hTask
which was previously stored with the TaskSetEnv() function. The slot specified
in Slot specifies the address (1–3) of the environment handle. There are actu-
ally four slots, but slot 0 is reserved.
TaskGetPri Get Task Priority
Syntax int TaskGetPri( HANDLE hTask );

Return Value Task priority level
Description Returns the priority of the target task. See TaskSetPri() for more information
on priority.

Task Support
TaskSelf Get the Handle to the Currently Executing Task Thread
Syntax HANDLE TaskSelf();
Parameter(s) none
Return Value Handle to currently executing thread, or NULL on error
Description Returns the task handle of the currently executing task thread. This function
is used mainly in other task object calls where the caller wishes to operate on
the current thread, but does not know the current thread’s handle.
If called on an illegal (system) thread, this function returns NULL. Only certain
implementations of the OS even have a system thread, and then, no user code
should ever be executed on it. A NULL may also result if Task functions are
called before the operating system is initialized.
TaskSetEnv Set Task Environment Handle
Syntax void TaskSetEnv( HANDLE hTask, int Slot, HANDLE hEnv );

Slot Environment slot to use (1–3)
hEnv Private environment handle
Description NOTE: This function is currently not available under DSP/BIOS
Sets and stores a private environment handle for the supplied task handle
hTask. This handle can be later retrieved by TaskGetEnv(). The slot specified
in Slot assigns an address (1–3) to the environment handle. There are actually
four slots, but slot 0 is reserved.
Environment handles can be used to associate private data with a task thread.
This is useful when multiple threads share the same code base, but require
their own instance of static data.
2-8
Task Support
TaskSetPri Set Task Priority
Syntax int TaskSetPri( HANDLE hTask, int Priority );

Priority Task priority level
Return Value Previous task priority level
Description Sets the priority of the target task to the specified value. The value of Priority
is constrained only by the size of an int on the target environment, but a range
of 0 to 15 is recommended. 0 is the lowest priority and should be reserved for
an idle task. If the specified priority is negative, the task is blocked.
TaskSleep Sleep Task for Period of Time
Syntax void TaskSleep( UINT32 Delay );
Parameter(s) Delay Time (in milliseconds) of sleep
Description Sleeps the calling task for a period of time as supplied in Delay. The sleep time
can not be zero.
TaskYield Yield Execution to Another Task Thread
Syntax void TaskYield();
Parameter(s) none
Return Value none
Description This function is used to yield execution to another thread. Its only function is
to cause a round-robin task switch among “ready” task threads executing at
the same priority level.
This function always causes a task switch, however the original calling task
may be the next to execute.

Semaphore Support
2.3 Semaphore Support
2.3.1 Synopsis
The semaphore object provides a method of manipulating counting sema-
phores using a generic handle.
Semaphores can be used for both task synchronization and mutual exclusion.

The Semaphore Object access functions (in functional order) are as follows:
SemCreate() Create new semaphore

SemDelete() Delete semaphore
SemPend() Wait on semaphore, optionally for a period of time
SemCount() Get the current semaphore count
SemPost() Release semaphore – increment count
SemReset() Reset semaphore and set new count
2.3.3 Semaphore API Functions
SemCreate Create New Semaphore
Syntax HANDLE SemCreate( int Count );
Parameter(s) Count Initial semaphore count
Return Value Handle to semaphore or NULL on error
Description Creates a new semaphore object with an initial count.
SemCount Get Current Semaphore Count
Syntax int SemCount( HANDLE hSem );
Parameter(s) hSem Handle to Semaphore
Return Value Current semaphore count
Description Returns the current count of the semaphore object.
2-10
Semaphore Support
SemDelete Delete Semaphore
Syntax void SemDelete( HANDLE hSem );
Description Deletes the semaphore object and frees related memory.
Any task currently waiting on this semaphore is blocked forever – even if it orig-
inally specified a timeout to SemPend(). With a little care in programming, this
will not occur.
SemPend Wait for a Semaphore
Syntax int SemPend( HANDLE hSem, UINT32 Timeout );

Timeout Max time to wait (in milliseconds)
Return Value 1 if the semaphore was obtained, and 0 if not
Description This function is used to wait on a semaphore.
If the semaphore count is greater than 0, the semaphore count is decrement

and this function immediately returns.
If the semaphore count is zero, the task is placed on a waiting list for the sema-
phore and blocked. If the semaphore becomes available in the time period
specified in Timeout, the function returns. However the function returns re-
gardless once the timeout has expired. A timeout value of 0 always returns
without blocking or yielding. A timeout value of SEM_FOREVER causes the
caller to wait on the semaphore without timeout.
The waiting list is “first in, first out”, without regard to priority. Thus semaphores
can be used to round-robin task threads at different priority levels.
Calling this function may cause a task switch (unless called with Timeout set
to 0).

Semaphore Support
SemPost Signal a Semaphore
Syntax void SemPost( HANDLE hSem );
Description This function is used to signal a semaphore.
If the semaphore count is greater than 0 (or is equal to 0, but without any pend-
ing task threads), the semaphore count is incremented and this function imme-
diately returns.
If the semaphore count is zero and there are tasks threads pending on it, the
count remains at zero, and the first thread in the pending list is unblocked.
SemReset Reset Semaphore
Syntax void SemReset( HANDLE hSem, int Count );

Count Initial semaphore count
Description This function resets the semaphore, first setting an initial semaphore count,
and then unblocking all tasks that are pending on the semaphore.
This function should be used with care. Tasks that are pending on the sema-
phore may exhibit unexpected behavior since all tasks pending on the sema-
phore will return from their respective SemPend() calls regardless of re-
quested timeout. The return value for the respective SemPend() calls will al-
ways be correct in that one or more tasks may get the semaphore (depending
on the value of Count), but tasks that called SemPend() without a timeout may
assume they have obtained the semaphore without checking the SemPend()
return value.
2-12
Memory Allocation Support
2.4 Memory Allocation Support
2.4.1 Synopsis
As part of normal stack operation, memory will be allocated and freed on a reg-
ular basis. It is therefore recommended that a memory support system have
the ability to allocate and free small memory blocks in a variety of sizes, without
memory fragmentation. The functions described here work on a memory buck-
et system of predefined fixed sizes. Although it allocates more memory than
requested, when the memory is released, it can be reused without fragmenta-
tion.

The Memory Allocation access functions (in functional order) are as follows:
mmAlloc() Allocate Small Memory Block
mmFree() Free mmAlloc() Memory Block
mmBulkAlloc() Allocate Unrestricted Memory Block
mmBulkRealloc() Reallocate mmBulkAlloc() Memory Block
mmBulkFree() Free mmBulkAlloc() Memory Block
2.4.3 Memory Allocation API Functions
mmAlloc Allocate Memory Block
Syntax void *mmAlloc( uint size );
Return Value Pointer to allocated memory or NULL on error
Description Allocates a memory block of at least size bytes in length. The function should
return a pointer to the new memory block, or NULL if memory is not available.
The size of the allocation cannot be more than 3068 bytes.
mmFree Free Memory Block
Syntax int mmFree( void *pv );
Return Value If a memory tracking error occurs, this function returns 0, else it returns 1
Description Frees a previously allocated memory block by supplying the pointer that
mmAlloc() originally returned.

Memory Allocation Support
mmBulkAlloc Allocate Bulk Memory Block
Syntax void *mmBulkAlloc( INT32 Size );

Return Value Pointer to allocated memory or NULL on error
Description Allocates a memory block of at least size bytes in length. The function returns
a pointer to the new memory block, or NULL if memory is not available. The
size of the allocation is not restricted.
mmBulkFree Free Bulk Memory Block
Syntax void mmBulkFree( void *pv );

Description Frees a previously allocated memory block by supplying the pointer that
mmBulkAlloc() originally returned.
mmBulkRealloc Reallocate Bulk Memory Block
Syntax void *mmBulkRealloc( void *pv, INT32 Size );

Return Value Pointer to reallocated memory or NULL on error or when Size is zero
Description Reallocate a previously allocated memory block by supplying the pointer that
mmBulkAlloc() originally returned. If Size is zero, the block is simply freed and
this function returns NULL. Otherwise, a NULL return indicates that the block
could not be reallocated and the original memory pointer (pv) is still valid. On
success, this function returns a pointer to the new memory block.
mmCopy Copy Memory
Syntax void mmCopy( void *pDst, void *pSrc, uint size );

Description Called to copy size bytes of data memory from the data buffer pSrc to the data
buffer pDst.
mmZeroInit Zero Memory
Syntax void mmZeroInit( void *pDst, uint size );

Description Called to initialize size bytes of data memory in the data buffer pDst to NULL.
2-14
Print and Debug Support
2.5 Print and Debug Support
2.5.1 Synopsis
The OS abstraction includes a family of compact printf() functions that print us-
ing a fixed buffer. The size of the buffer (max printf() length) is defined in the
OS abstraction layer. The code to print to the standard output device is also
provided, and this function can be modified to print or log as required.
The stack also provides another form of the printf function called DbgPrintf().
This function is used to print debug messages to a global debug log. The se-
verity threshold at which the debug message is recorded can be adjusted as
well as at what point the error causes a system shutdown.
2.5.2 Standard Print Functions

The standard set of printf functions is supported:
int printf(const char *format, ...);
int sprintf(char *s, const char *format, ...);
int vprintf(const char *format, va_list arg);
int vsprintf(char *s, const char *format, va_list arg);
2.5.3 Debug API Functions
DbgPrintf Print a Debug Message to the Debug Log
Syntax void DbgPrintf( int ErrLevel, char *Format, … );
Parameter(s) ErrLevel Severity level of the error

Format Standard printf format string
Description This function prints a debug message to the global debug log buffer. The log
buffer is defined as follows:
#define LL_DEBUG_LOG_MAX 1024
extern char DebugLog[LL_DEBUG_LOG_MAX]; // DebugLog
Buffer
extern int DebugLogSize; // Bytes of data currently
in DebugLog
The buffer behaves like one large NULL terminated string. The contents are
cleared by setting DebugLogSize to 0.

Print and Debug Support
The value of ErrLevel determines if the message is printed and additionally,

if the message results in a system shutdown. Both thresholds can be modified
through the OS configuration. The definition of the severity levels are as fol-
lows:
#define DBG_INFO 1
#define DBG_WARN 2
#define DBG_ERROR 3
#define DBG_NONE 4
2-16
File I/O Support for Embedded Systems
2.6 File I/O Support for Embedded Systems
2.6.1 Synopsis
The next section of this document discusses the support for stream IO that is
built into the stack library. The support documented in that section is intended
to augment the basic functions provided by the native operating system (in the
case where the stack is ported to a new environment).
This section details functionality required by the Network Tools services deal-
ing with File IO. The functionality described here is much more likely to have
a local counterpart. The API described in this section must be ported to allow
the network services that use it to operate.
Please Note: This API is unrelated to the stream API provided for Sockets. If
the services that require this API are not required, then this module can be dis-
carded from the OS abstraction. Currently, only the HTTP Server service
makes use of this API.
The API described here was taken from the Unix standard. The names of the
functions have been prefixed with the designation “efs_” which stands for em-
bedded file system. This was done so that the functions would not conflict with
any existing file system. The EFS API is a very simple RAM based file system.
A couple of new functions are included which allow the creation of RAM ”files”
by supplying pointers to static data buffers.
For systems with existing file systems most of the functions in this API become
shims to their standard IO counterparts.

The following functions are more specific to this implementation, but can be
ported:
efs_createfile() Create (declare) RAM based file
efs_destroyfile() Destroy RAM based file
efs_getfilesize() Get the length of file data
efs_loadfunction() Load “executable” file and return entry-point
function
As previously mentioned, most of the API closely matches its standard C coun-
terpart:
efs_fclose() Close file
efs_feof() Check for end of file
efs_fopen() Open file

efs_fread() Read from file

efs_fseek() Set file position
efs_ftell() Get file position
efs_fwrite() Write to file
efs_rewind() Reset file position to start of file
2.6.3 EFS Custom API Functions
efs_createfile Create (declare) a RAM Based File
Syntax void efs_createfile( char *name, INT32 length, UINT8 *pData );
Parameter(s) name Filename (max length of EFS_FILENAME_MAX)

length Length of file datap
Data Pointer to file data
Description This function creates an internal record of the RAM based file with the indi-
cated filename, file length, and data pointer. The file data is not copied, so the
buffer must be statically allocated. The filename is copied, so it does not need
to be static.
A static buffer based system is more efficient for embedded systems since the
data must already be present in RAM or ROM. However, the efs_createfile()
function could easily be altered to use allocated buffers which are later freed
when efs_destroyfile() is called. These create and destroy functions are only
called by the sample application code, and thus the system programmer is free
to alter the operation of these functions – so long as they create “files” that are
compatible with the rest of this API.
efs_destroyfile Destroy (remove declaration from a) RAM Based File
Syntax void efs_destroyfile( char *name );
Description This function deletes the internal file record associating the filename with the
static data pointer as originally passed to efs_createfile().
2-18
data must already be present in RAM or ROM. However, the efs_createfile()
function could easily be altered to use allocated buffers which are later freed
when efs_destroyfile() is called. These create and destroy functions are only
called by the sample application code, and thus the system programmer is free
to alter the operation of these functions – so long as they create ”files” that are
compatible with the rest of this API.
efs_getfilesize Get the Length of a File
Syntax INT32 efs_getfilesize( EFS_FILE *stream );
Parameter(s) stream Pointer to open stream (file)
Return Value File size in bytes
Description This function returns the length in bytes of the indicated file. The file must al-
ready have been opened via a call to efs_fopen().
efs_loadfunction Load Executable File and Return Entrypoint
Syntax EFSFUN efs_loadfunction( char *name );
Return Value Pointer to executable function
Description This function “loads” an executable file and returns a pointer to the entrypoint
function. The type EFSFUN is declared as:
typedef void (*EFSFUN)();
The application is really free to treat this function in whatever manner is re-
quired. This executable file is created with a call to efs_createfile() where the
pData parameter points to a function that is already loaded in memory. This
allows the HTTP server to call services “contained” in CGI files.
data must already be present in RAM or ROM. However, the HTTP can be
made to work with physical CGI files by porting this function to load CGI.

2.6.4 EFS Standard API Functions
efs_fclose Close File
Syntax int efs_fclose( EFS_FILE *stream );
Return Value Returns EOF if any errors occurred, and zero otherwise
Description This function performs a logical “close” on an open file. It is functionally equiva-
lent to fclose().
efs_feof Test for End of File
Syntax int efs_feof( EFS_FILE *stream );
Return Value Returns non-zero if EOF has been reached, and zero otherwise
Description This function tests to see is the file position has reached the end of the file. It
is functionally equivalent to feof().
efs_fopen Open File
Syntax EFS_FILE *efs_fopen( char *name, char *mode );
Parameter(s) name Name of file to open

mode Desired mode of open file
Return Value Returns a stream pointer or NULL on error
Description This function performs a logical “open” on the named file and returns a stream
or NULL if the attempt fails. It is functionally equivalent to fopen().
The mode parameter determines the mode for with the file is opened. In the
embedded file system version of this function, the list of supported modes is
quite simple:
“rb” – open binary file for reading
The flags are still passed though to ensure compatibility with a full file system.
2-20
efs_fread Read from a File
Syntax size_t efs_fread( void *ptr, size_t size, size_t nobj, EFS_FILE *stream );
Parameter(s) ptr Pointer to data buffer to receive data
size Size in bytes of a read “object”
nobj Number of objects to read
stream Pointer to open stream (file)
Return Value Returns the number of objects read
Description This function reads from the indicated stream in the array ptr at most nobj ob-
jects of a length specified by size. It returns the number of objects read; this
may be less than the number of objects requested. It is functionally equivalent
to fread().
efs_feof() can be used to detect end of file.
efs_fseek Set File Position
Syntax INT32 efs_fseek( EFS_FILE *stream, INT32 offset, int origin );

offset Offset of desired new position
origin Base reference point for offset
Return Value Returns non-zero on error
Description This function sets the file position of the indicated stream to that specified by
offset from a base reference point specified by origin. It is functionally equiva-
lent to fseek().
The origin parameter can be set to one of the following:
- EFS_SEEK_SET – Position by offset from the beginning of the file
- EFS_SEEK_CUR – Position by offset from the current position
- EFS_SEEK_END – Position by offset from the end of the file
efs_ftell Get File Position
Syntax INT32 efs_ftell( EFS_FILE *stream );

Return Value Returns file position or –1L on error
Description This function returns the current file position of the indicated stream. It is func-
tionally equivalent to ftell().

efs_fwrite Write to a File
Syntax size_t efs_fwrite( void *ptr, size_t size, size_t nobj, EFS_FILE *stream );
Parameter(s) ptr Pointer to data buffer to receive data

size Size in bytes of a read “object”
nobj Number of objects to read
stream Pointer to open stream (file)
Return Value Returns the number of objects written (0)
Description This function writes to the indicated stream from the array ptr, up to nobj ob-
jects of a length specified by size. It returns the number of objects written; this
may be less than the number of objects requested on an error. It is functionally
equivalent to fwrite().
Nothing in the stack package requires write capability, thus this function al-
ways returns zero.
efs_rewind Reset File Position to Start of File
Syntax void efs_rewind( EFS_FILE *stream );
Description This sets the position of the indicated stream to zero, and clears any current
error. (Errors are not tracked in this implementation.)
2-22
Chapter 3
Sockets and Stream IO API
In order to facilitate a comfortable development environment for the experi-

enced network application programmer, and to allow for easier porting of net-
work applications, the TCP/IP stack library provides a standard file descriptor
environment and a Berkeley compatible sockets API. This layer is built on top
of DSP/BIOS, and designed to not conflict with any pre-existing file support.
The resulting file and sockets API functions are described in this section.
Topic Page
3.1 File Descriptor Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.2 File Descriptor Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.3 Sockets Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
3.4 Full Duplex Pipes Programming Interface . . . . . . . . . . . . . . . . . . . . . . 3-34
3-1
File Descriptor Environment
3.1 File Descriptor Environment
In most embedded operating system environments, support for file descriptors

varies greatly. In most cases, only the bare minimum functionality is provided,
and trimmed down support functions are provided using the common “re-
served” names (read(), write(), close(), etc.).
Since this stack supports the standard sockets interface functions, and these
functions require file descriptor support, the stack provides its own small file
system. This section describes the basic mechanics of the file system.
3.1.1 Organization
The basic building block of the stack code internally is an object handle. Inter-
nally to the stack, both sockets and pipes are addressed by object handles.
However, at the application level, sockets and pipes are treated as file descrip-
tors, which are integer indices. Integer representation is necessary to support
the classic Unix concept of the select() call.
The stack API supports the use of integer file descriptors, by adding a file des-
criptor layer of abstraction to the native operating environment. It is this layer
that implements the standard sockets and file IO functions. The stack works
by associating a file descriptor table with each caller’s thread (or in our ter-
minology, ’task’). In this system, each task has its own file descriptor table. The
file descriptor index passed to a file function is used to lookup the actual file
handle contained in the task’s associated file descriptor table. This enables the
stack to support both an object oriented and the classical Unix sockets API.
Note again that file descriptors are private to each particular task thread while
the actual pipe and socket objects are addressed by object handles. It is some-
times necessary to convert a file descriptor to a handle and back again in order
to pass the object to another task.
3.1.2 Initializing the File System Environment
In order to use the file system and socket functions provided by the stack, a
task must first allocate a file descriptor table (called a file descriptor session).
This is accomplished at the application layer by calling the file descriptor func-
tion fdOpenSession(). When the task is finished using the file descriptor API,
or when it is about to terminate, fdCloseSession() is called.
3-2
3.1.2.1 When to Initialize the File Descriptor Environment
All that is required for correct stack operation, is that a task must open a file
descriptor session before calling any file descriptor related functions, and
close it when it is done.
For example, the most straightforward approach would be for a task to open
its file session when it starts, and close it when it completes. For example:
Socket Task:
void socket_task( int IPAddr, int TcpPort )
{
SOCKET s;
// Open the file session
fdOpenSession( TaskSelf() );
< socket application code >
// Close the file session
fdCloseSession( TaskSelf() );
}
A second option would be for the task that creates the socket task to also open
the file descriptor session. Note that the parent task must guarantee that the
child task’s file session is open before the child task has had a chance to exe-
cute. This can be done via task priority, but it can be messy. Thus, it is not a
very common approach.
A third, more common option is to allow a child task to open its own file session,
but where a parent task monitors its children and has the ability to destroy
them. Here, the parent task must close the file session of the children it de-
stroys. Thus the child task must block when finished instead of terminating.
The following example illustrates this concept:
Child Socket Task:

void child_socket_task( int IPAddr, int TcpPort )
{
SOCKET s;
// Open the file session
fdOpenSession( TaskSelf() );
< socket application code >
// We’re done, but our parent thread will close
// our file session and destroy this task, so here
// we just block.
TaskBlock( TaskSelf() );
}
Sockets and Stream IO API 3-3

The parent task functions would look something like the following:
Parent Task Functions:

void create_child_task()
{
// Create System Tasks
// Create a child task

hChildTask = TaskCreate( &child_socket_task, … );
}
void destroy_child_task()
{
// First close the child’s file session
// (This will close all open files)
fdSessionClose( hChildTask );
// Then destroy the task
TaskDestroy( hChildTask );
}
3-4
File Descriptor Programming Interface
3.2 File Descriptor Programming Interface
3.2.1 Synopsis
The purpose of supporting a file system is to support the sockets API. Unfortu-
nately, the sockets API is not a complete IO API as it was originally designed
to integrate into the Unix file system. Thus, several file descriptor functions that
have become very important to the application programmer are not really
socket calls at all. The stack library supports a handful of what would normally
considered file functions so that sockets applications can be programmed in
a more traditional sense. In order that these functions will not conflict with any
other file functions in the system, their names have been altered slightly from
the standard definitions.
The stream IO object can take two forms. In the vast majority of cases, it will
be in the form of a local file descriptor. The following functions can operate on
file descriptors:
fdOpenSession() Open file descriptor support session

fdCloseSession() Close file descriptor support session
fdSelect() Wait on one or more file events (same as stan-
dard select())
fdClose() Flush stream and close file descriptor (same as
standard close())
fdError() Return last error value (same as standard errno)
fdSelectAbort() Terminates a previous call to fdSelect() by simu-
lating a timeout condition
fdGetFileHandle() Convert local task file descriptor to global file
HANDLE
fdTransfer() Transfer file descriptor from one task to another
The file descriptor can be converted to a global file handle, which can then be
passed to another task thread. The handle is usually converted back to a file
descriptor by the receiving task thread. The following functions can operate on
file handles:
FileHandleClose() Close file HANDLE (without converting back to

file descriptor)
FileHandleGetFd() Convert global file HANDLE to local task file
descriptor

The fdSelect() function uses file descriptor sets to specify which file descrip-
tors are being checked for activity and which have activity detected. There is
a small set of MACRO functions for manipulating file descriptor sets. These
include the following:
FD_SET() Add a file descriptor to a file descriptor set
FD_CLR() Remove a file descriptor from a file descriptor set
FD_ISSET() Test to see if a file descriptor is included in a file
descriptor set
FD_COPY() Copy a file descriptor set
FD_ZERO() Clear (initialize) a file descriptor set
3.2.3 File Descriptor API Functions
fdOpenSession Open File Descriptor Session
Syntax int fdOpenSession( HANDLE hTask );
Parameter(s) hTask Task Thread Handle
Return Value 1 on success or 0 on memory allocation error
Description This function opens a file descriptor session on a task thread so that the task
can begin using file descriptor and other stream IO functions.
A task thread normally calls fdOpenSession() when it is first created, and

fdCloseSession() before it exits. Use of these functions was described in more
detail in the previous section.
fdCloseSession Close File Descriptor Session
Syntax void fdCloseSession( HANDLE hTask );
Parameter(s) hTask Task Thread Handle
Description This function closes a file descriptor session that was previously opened with
fdOpenSession(). When called, any remaining open file descriptors are
closed.
A task thread normally calls fdOpenSession() when it is first created, and

fdCloseSession() before it exits. Use of these functions was described in more
detail in the previous section.
3-6
fdSelect Wait on One or Multiple File Events
Syntax int fdSelect( int maxfd, fd_set *readset, fd_set *writeset, fd_set *exceptset,
struct timeval *timeout );
Parameter(s) maxfd The highest index contained in any of the three supplied
descriptor sets
readset Set of file descriptors to check for reading
writeset Set of file descriptors to check for writing
exceptset Set of file descriptors to check for exceptional conditions
(OOB data)
timeout Pointer to timeval structure of time to wait (or NULL)
Return Value Returns a positive count of ready descriptors (combined from all three possible
sets), 0 on timeout, or –1 on error. When an error occurs, the error type can
be obtained by calling fdError().
Description This function allows the task to instruct the stack to wait for any one of multiple
events to occur and to wake up the process only when one of more of these
events occurs or when a specified amount of time has passed.
The definition of the timeval structure is:
struct timeval {
INT32 tv_sec;
INT32 tv_usec;
};
Passing in a NULL pointer for timeout specifies an infinite wait period. Passing
a valid pointer to a timeval structure with both tv_sec and tv_usec set to zero
specifies that the function should not block.
fdClose Close File Descriptor
Syntax int fdClose( int fd );

Parameter(s)
Return Value 0 on success or –1 on error. When an error occurs, the error type can be ob-
tained by calling fdError() (errno is also equated to this function).
Description This function closes the indicated file descriptor.
fdError Get the Last File Error
Syntax int fdError();

Description This function returns the last file error that occurred on the current task. In the
ERRNO.H header file, errno is equated to this function.

Note: The error code returned via fdError() is stored in the file descriptor ses-
sion associated with a task. If a task calls a file or socket function before it
opens a file descriptor session, an error condition results. Obviously however,
no error code can be stored for retrieval by fdError() since the file descriptor
session doesn’t exist to hold it.
fdSelectAbort Terminate a Previous Call to fdSelect()
Syntax void fdSelectAbort( HANDLE hTask );

Parameter(s) hTask Handle to the task thread which is blocked in fdSelect()
Description This function aborts a previous call to fdSelect() on another thread by simulat-
ing a timeout condition (even when no timeout was originally specified). It can
be used to wake a thread using an alternate method than socket or pipe activi-
ty. It is particularly useful in callback functions where the handle to the task
thread to “wake” is known, but nothing it known about the current thread.
The return value from the fdSelect() called on the target thread is still valid
(most likely an empty descriptor set).
fdGetFileHandle Convert a File Descriptor Index to a File Handle
Syntax HANDLE fdGetFileHandle( int fd );

Parameter(s) fd File descriptor to convert
Return Value Non-zero handle on success or NULL on error. When an error occurs, the error
type can be obtained by calling fdError().
Description Although file descriptors are nice for functions like fdSelect(), they have a dis-
advantage in that they are not global across tasks. However, a file descriptor
can be converted to a file handle, which is global, and can be passed to another
task.
This function converts a file descriptor to a file handle. Note that after this call,
the file descriptor becomes invalid and can not be used. The handle can be
converted back to a file descriptor by calling the FileHandleGetFd() function.
fdTransfer Transfer File Descriptor from One Task to Another
Syntax int fdTransfer( HANDLE hSrcTask, int fdsrc, HANDLE hDstTask, int *pfddst
);
Parameter(s) hSrcTask Handle of task which currently owns the file descriptor
fdsrc File descriptor to transfer
3-8
hDstTask Handle of task to receive the file descriptor

pfddst Pointer to where to write new file descriptor
Return Value Returns zero on success or –1 on error. If an error occurs, the state of the file
descriptor is not altered.
advantage in that they are not global across tasks. However, a file descriptor
can be transferred from one task to another so long as the task handles for both
tasks are known. This is an alternative to using the fdGetFileHandle() function.
This function transfers the file descriptor from the descriptor of hSrcTask to the
descriptor table of hDstTask. Note that after this call, the file descriptor be-
comes invalid for hSrcTask and can no longer be used by that task.
Note: Both the source and destination tasks must have called fdOpen-
Session() before the transfer can take place. This can make using
fdTransfer() tricky when one of the two tasks has been recently created.
In a parent/child relationship, it is safer for the child to call fdTransfer()
and then signal the parent if necessary to allow it to terminate.
A better alternative for transferring a file descriptor from one task to

another is for the source task to call fdGetFileHandle(), and pass the re-
sulting global handle to the second task. The second task can then call
FileHandleGetFd() on the handle once it has created its file descriptor
environment with fdOpenSession(). There are no synchronization is-
sues with this method.
3.2.4 File Handle API Functions
FileHandleClose Close a File Handle
Syntax void FileHandleClose( HANDLE hFile );
Parameter(s) hFile Handle to file
Return Value File descriptor or –1 on error. This function is not strictly part of the file descrip-
tor function set, and does not elaborate on error conditions via fdError().
Description When a file is in handle form (i.e., does not belong to any task), there is not
much that can be done with it. However, in some cases it may be necessary
to close the handle without converting back to a file descriptor. This occurs
mostly when shutting down an application where multiple children share a
common file handle.
This function closes a file while in handle format.

FileHandleGetFd Convert a File Handle to a File Descriptor
Syntax int FileHandleGetFd( HANDLE hFile );
Parameter(s) hFile Handle to file to convert
Return Value File descriptor or –1 on error. This function is not strictly part of the file descrip-
tor function set, and does not elaborate on error conditions via fdError().
advantage in that they are not global across tasks. However, file handles are
global and can be passed from one task to another. This function converts a
global file handle to a file descriptor that is local to the calling task. The returned
file descriptor can then be used in other file or socket calls.
This function converts a file handle to a file descriptor. Note that after this call,
the file handle should no longer be used.
3.2.5 File Descriptor Set (fd_set) Macros
FD_SET Add a File Descriptor to a File Descriptor Set
Syntax void FD_SET( int fd, fd_set *pFdSet );
Parameter(s) fd File descriptor to add

pFdSet Pointer to fd_set data type
Return Value Should be treated as a void function. The true return value is dependent on the
implementation of the macro.
Description This function is used to add a file descriptor to a file descriptor set, typically
before using the set in a call to fdSelect(). Note that after declaring a fd_set
data type, it should be initialized using FD_ZERO() before attempting to set
individual file descriptors.
FD_CLR Remove a File Descriptor from a File Descriptor Set
Syntax void FD_CLR( int fd, fd_set *pFdSet );
Parameter(s) fd File descriptor to remove

3-10
Return Value Should be treated as a void function. The true return value is dependent on the
implementation of the macro.
Description This function is used to remove a file descriptor from a file descriptor set, typi-
cally after the file descriptor has been “processed” in a loop that continuously
checks a file descriptor set.
FD_ISSET Test to See if a File Descriptor is Included in a File Descriptor Set
Syntax void FD_ISSET( int fd, fd_set *pFdSet );
Parameter(s) fd File descriptor to check

Return Value Returns an int value which should be treated as a TRUE/FALSE condition.
Description This function returns TRUE if the supplied file descriptor is contained in the in-
dicated file descriptor set. This function is typically called after a call to fdSe-
lect() to determine on what file descriptors select has detected activity.
FD_COPY Copy a File Descriptor Set
Syntax void FD_COPY( fd_set *pFdSetSRC, fd_set *pFdSetDST );
Parameter(s) pFdSetSRC Pointer to fd_set to copy

pFdSetDST Pointer to fd_set to write copied data
Description This function is called to make a copy of a file descriptor set. This is typically
done is a set needs to be modified, but this original information needs to be
maintained.
FD_ZERO Clear (Initialize) a File Descriptor Set
Syntax void FD_ZERO( fd_set *pFdSet );
Parameter(s) pFdSet Pointer to fd_set to initialize
Description This function is called clear all bits in a file descriptor set. This should be the
first call made on a newly declared fd_set variable.

Sockets Programming Interfaces
3.3 Sockets Programming Interfaces

3.3.1 Synopsis
The socket function API supported by the stack library is consistent with the
standard Berkeley sockets API. No parameter adjustments are required.
In the interest of brevity, two new types are defined for the socket function dec-
larations:
typedef struct sockaddr SA;
typedef struct sockaddr *PSA;
3.3.2 Enhanced “No-Copy” Socket Operation

Any performance of any data stream operation suffers when data copies are
performed. Although the stack software is designed to use a minimum number
of data copies, memory efficiency and API compatibility sometimes require the
use of data copy operations.
By default, neither UDP nor RAW sockets use send or receive buffers. Howev-
er, the sockets API functions recv() and recvfrom() require a data buffer copy
because of how the calling parameters to the functions are defined. In the
stack library, two alternative functions (recvnc() and recvncfrom()) are pro-
vided to allow an application to get received data buffers directly without a copy
operation. When the application is finished with these buffers, it returns them
to the system via a call to recvncfree().
By default, TCP uses both a send and receive buffer. The send buffer is used
since the TCP protocol can require “reshaping” or retransmission of data due
to window sizes, lost packets, etc.. On receive, the standard TCP socket also
has a receive buffer. This is used to coalesce TCP data received from packet
buffers. Coalescing data is important for protocols that transmit data in very
small bursts (like a telnet session).
For TCP applications that get data in large bursts (and tend not to use flags
like MSG_WAITALL on receive), the receive buffer can be eliminated by speci-
fying an alternate TCP stream type of SOCK_STREAMNC (see page 2-8).
Without the receive buffer, there is at least one less data copy since TCP will
queue up the actual network packets containing receive data instead of copy-
ing it into a receive buffer.
Care needs to be taken when eliminating the TCP receive buffer. Here large
amounts of packet buffers can be tied up for a very small amount of data. Also,
since packet buffers come from the HAL, there may be a very limited supply
available. If the MSG_WAITALL flag is used on a recv() or recvfrom() call, it
is possible for all packet buffers to be consumed before the specified amount
of payload data is received. This would cause a deadlock situation if no socket
timeout is specified.
3-12
Although TCP sockets that use the SOCK_STREAMNC stream type are 100%
compatible with the standard TCP socket type, they can also be used with the
recvnc() and recvncfrom() functions that UDP and RAW sockets use to elimi-
nate the final data copy from the stack to the sockets application. Using the “no
copy” functions with SOCK_STREAMNC eliminates two data copies from the
standard TCP socket. Note however that when recvnc() and recvncfrom() are
used with TCP, out of band data is not supported. If the SO_OOBINLINE sock-
et option is set, the out of band data is retained, but the out of band data mark
is discarded. If not using the inline socket option, the out of band data is dis-
carded.

The standard socket access functions are as follows:
accept() Accept a connection on a socket
bind() Bind a name to a socket
connect() Initiate a connection on a socket
getpeername() Return name (address) of connected peer
getsockname() Return the local name (address) of the socket
getsockopt() Get the value of a socket option
listen() Listen for connection requests on a socket
recv() Receive data from a socket
recvfrom() Receive data from a socket with the senders name
(address)
send() Send data to a connected socket
sendto() Send data to a specified destination on an uncon-
nected socket
setsockopt() Set the value of a socket option
shutdown() Close one half of a socket connection
socket() Create a socket
socketpair() Create socket pair (redundant; see full duplex pipes
in section 3.4)
The enhanced socket functions are as follows:

recvnc() Receive “no-copy” data from a socket
recvncfree() Free buffer obtained from recvnc() or recvncfrom()
recvncfrom() Receive “no-copy” data from a socket with the send-
ers name (address)

3.3.4 Sockets API Functions
accept Accept a Connection on a Socket
Syntax int accept( int s, PSA pName, int *plen );

Parameter(s) s Socket
pName Name (address) of connected peer
plen Pointer to size of pName
Return Value If it succeeds, the function returns a non-negative integer that is a descriptor
for the accepted socket. Otherwise, a value of –1 is returned and the function
fdError() can be called to determine the error:
EBADF The file descriptor (socket) is invalid.
EMFILE The file descriptor table is full.
ENOMEM Memory allocation error.
ENOTSOCK The descriptor does not reference a socket.
EINVAL Listen has not been called on the socket or name
arguments are invalid.
EWOULDBLOCK Socket is marked non-blocking and no connec-
tions are ready.
Description The argument s is a socket that has been created with the socket() function,
bound to an address with bind(), and is listening for connections after a listen().
The accept() function extracts the first connection request on the queue of
pending connections, creates a new socket with the same properties of socket
‘s’ and allocates a new file descriptor for the socket. If no pending connections
are present on the queue, and the socket is not marked as non-blocking, ac-
cept blocks the caller until a connection is present. If the socket is marked non-
blocking and no pending connections are present on the queue, accept returns
an error as described above.
The accepted socket may not be used to accept more connections. The origi-
nal socket ‘s’ remains open.
The argument pName is a result parameter that is filled in with the address of
the connecting entity as known to the communications layer. The domain in
which the communication is occurring determines the exact format of the
pName parameter. The plen is a value-result parameter; it should initially con-
tain at least sizeof(struct sockaddr), the amount of space pointed to by pName;
on return it will contain the actual length (in bytes) of the address returned.
This call is used with connection-based socket types, currently with
SOCK_STREAM.
It is possible to select (fdSelect()) a socket for the purposes of doing an accept
by selecting it for read.
3-14
bind Bind a Name (address) to a Socket
Syntax int bind( int s, PSA pName, int len );
pName Name (address) of desired local address
len Size of pName
Return Value If it succeeds, the function returns 0. Otherwise, a value of –1 is returned and
the function fdError() can be called to determine the error:
ENOTSOCK The descriptor does not reference a socket.
EINVAL Listen has not been called on the socket or
name arguments are invalid.
EADDRNOTAVAIL The specified address is not available from the
local machine.
EADDRINUSE The specified address is already in use.
Description The bind() function assigns a name to an unnamed socket. When a socket is
created with socket() it exists in a name space (address family) but has no
name assigned. The bind() function requests that name be assigned to the
socket.
The argument s is a socket that has been created with the socket() function.
The argument pName is a structure of type sockaddr that contains the desired
local address. The len parameter contains the size of pName which is si-
zeof(struct sockaddr).
connect Initiate a Connection on a Socket
Syntax int connect( int s, PSA pName, int len );
pName Name (address) of desired peer
len Size of pName
ENOTSOCK The file descriptor does not reference a socket.
EINVAL Name arguments are invalid.
EADDRNOTAVAIL The specified address is not available from the
local machine.

EADDRINUSE The specified address is already in use.

EISCONN The socket is already connected.
ETIMEDOUT Connection establishment timed out without es-
tablishing a connection.
ECONNREFUSED The attempt to connect was forcefully rejected.
ENETUNREACH The network isn’t reachable from this host
Description The connect() function establishes a logical (and potentially physical) connec-
tion from the socket specified by s to the foreign name (address) specified by
pName.
If sock is of type SOCK_DGRAM, this call specifies the peer address with
which the socket is to be associated; this address is that to which datagrams
are to be sent, and the only address from which datagrams are to be received.
If the socket is of type SOCK_STREAM, the function attempts to make a con-
nection to another socket.
The argument s is a socket that has been created with the socket() function.
The argument pName is a structure of type sockaddr that contains the desired
foreign address. The len parameter contains the size of pName which is si-
zeof( struct sockaddr ).
Stream sockets may connect only once; while datagram sockets may re-con-
nect multiple times to change their association. The connection may be dis-
solved by attempting to connect to an illegal address (say NULL IP and Port).
Datagram sockets that require multiple connections may consider using the
recvfrom() and sendto() functions instead of connect().
It is possible to select (fdSelect()) a socket for the purposes of doing a connect

by selecting it for writing.
getpeername Get Name (address) of Connected Peer
Syntax int getpeername( int s, PSA pName, int *plen );
3-16

ENOTCONN The socket is not connected.
Description The getpeername() function returns the name (address) of the connected
peer.
tain at least sizeof( struct sockaddr ), the amount of space pointed to by
pName; on return it will contain the actual length (in bytes) of the address re-
turned.
getsockname Get the Local Name (address) of the Socket
Syntax int getsockname( int s, PSA pName, int *plen );
Description The getsockname() function returns the local name (address) of the socket.
tain at least sizeof(struct sockaddr), the amount of space pointed to by pName;
on return it will contain the actual length (in bytes) of the address returned.
getsockopt Get the Value of a Socket Option Parameter
Syntax int getsockopt( int s, int level, int op, void *pbuf, int *pbufsize );
level Option level (SOL_SOCKET, IPPROTO_IP, IPPROTO_TCP)

op Socket option to get

pbuf Pointer to memory buffer
pbufsize Pointer to size of memory buffer
EINVAL Buffer arguments are invalid.
Description The getsockopt() function returns the options associated with a socket. Op-
tions may exist at multiple protocol levels; they are always present at the up-
permost socket level.
When manipulating socket options, the level at which the option resides and
the name of the option must be specified. To manipulate options at the socket
level, level is specified as SOL_SOCKET. To manipulate options at any other
level the protocol number of the appropriate protocol controlling the option is
supplied. In this implementation, only SOL_SOCKET, IPPROTO_IP, and
IPROTO_TCP are supported.
The parameters pbuf and pbufsize identify a buffer in which the value for the
requested option(s) are to be returned. pbufsize is a value-result parameter,
initially containing the size of the buffer pointed to by pbuf, and modified on re-
turn to indicate the actual size of the value returned.
Most socket-level options utilize an int parameter for pbuf. SO_LINGER uses
a struct linger parameter, defined in INC\SOCKET.H, which specifies the de-
sired state of the option and the linger interval (see below). SO_SNDTIMEO
and SO_RCVTIMEO use a struct timeval parameter.
The following options are recognized at the socket level:
SO_REUSEADDR Specifies that the rules used in validating addresses
supplied in a bind call should allow reuse of local
addresses.
SO_REUSEPORT Allows completely duplicate bindings by multiple
processes if they all set SO_REUSEPORT before
binding the port. This option permits multiple
instances of a program to each receive UDP/IP mul-
ticast or broadcast datagrams destined for the
bound port.
SO_KEEPALIVE Enables the periodic transmission of messages on a
connected socket. Should the connected party fail
to respond to these messages, the connection is
considered broken and processes using the socket
are notified when attempting to send data.
3-18
SO_DONTROUTE Indicates that outgoing messages should bypass

the standard routing facilities. Instead, messages
are directed to the appropriate network interface
according to the network portion of the destination
address.
SO_LINGER Controls the action taken when unsent messages
are queued on socket and a close is performed. If
the socket promises reliable delivery of data and
SO_LINGER is set, the system will block the pro-
cess on the close attempt until it is able to transmit
the data or until it decides it is unable to deliver the
information (a timeout period, termed the linger in-
terval, is specified in seconds in the setsockopt call
when SO_LINGER is requested). If SO_LINGER is
disabled and a close is issued, the system will pro-
cess the close in a manner that allows the process
to continue as quickly as possible.
SO_BROADCAST Requests permission to send broadcast datagrams
on the socket. Broadcast was a privileged operation
in earlier versions of the system.
SO_OOBINLINE With protocols that support out-of-band data, this
option requests that out-of-band data be placed in
the normal data input queue as received; it will then
be accessible with recv or read calls without the
MSG_OOB flag. Some protocols always behave as
if this option is set.
SO_SNDBUF Buffer size for output
SO_RCVBUF Buffer size for input
SO_SNDLOWAT Is an option to set the minimum count for output op-
erations. Most output operations process all of the
data supplied by the call, delivering data to the pro-
tocol for transmission and blocking as necessary for
flow control. Non-blocking output operations will
process as much data as permitted subject to flow
control without blocking, but will process no data if
flow control does not allow the smaller of the low
water mark value or the entire request to be pro-
cessed. A select operation testing the ability to write
to a socket will return true only if the low water mark
amount could be processed. The default value for
SO_SNDLOWAT is set to a convenient size for net-
work efficiency, often 1024.

SO_RCVLOWAT Is an option to set the minimum count for input op-

erations. In general, receive calls will block until any
(non-zero) amount of data is received, then return
with the smaller of the amount specified by
SO_RCVLOWAT or the amount requested. The de-
fault value for SO_RCVLOWAT is 1. Receive calls
may still return less than the amount specified by
SO_RCVLOWAT or the amount requested if an er-
ror occurs, or the type of data next in the receive
queue is different from that which was returned.
SO_SNDTIMEO Is an option to set a timeout value for output opera-
tions. It accepts a struct timeval parameter with the
number of seconds and microseconds used to limit
waits for output operations to complete. If a send
operation has blocked for this much time, it returns
with a partial count or with the error EWOULD-
BLOCK if no data were sent. In the current imple-
mentation, this timer is restarted each time addition-
al data are delivered to the protocol, implying that
the limit applies to output portions ranging in size
from the low water mark to the high water mark for
output.
SO_RCVTIMEO Is an option to set a timeout value for input opera-
tions. It accepts a struct timeval parameter with the
number of seconds and microseconds used to limit
waits for input operations to complete. This timer is
restarted each time additional data are received by
the protocol, and thus the limit is in effect an inactiv-
ity timer. If a receive operation has been blocked for
this much time without receiving additional data, it
returns with a short count or with the error
EWOULDBLOCK if no data were received.
SO_TYPE SO_TYPE returns the type of the socket, such as
SOCK_STREAM.
SO_ERROR Returns any pending error on the socket and clears
the error status. It may be used to check for asyn-
chronous errors on connected datagram sockets or
for other asynchronous errors.
3-20
Options that are not Berkeley standard:
SO_IFDEVICE Specifies a uint index (1 to n) of the designated in-

terface for sending and receiving IP broadcast pack-
ets. When set, this interface is selected on a IP
broadcast send operation if the socket’s local
(bound) IP address is NULL (INADDR_ANY). Also,
when set, the socket will only accept incoming
broadcast packets if they have been received on
this interface.
SO_BLOCKING Specifies a int flag (1 or 0) indicating if the socking
is in blocking or non-blocking mode. Sockets default
to blocking mode when created, but can be set to
non-blocking by using setsockopt(). This option pro-
vides the same functionality as calling the Unix
function Fcntl() with the O_NONBLOCK flag.
The following options are recognized at the IPPROTO_IP level:
IP_OPTIONS Specifies the IP options to be including in any out-

going IP packet sent via this socket (maximum
length is 20 bytes)
IP_HDRINCL Indicates to IP that the socket application is supply-
ing the IP header as well as the rest of the packet
payload. This is for use with RAW sockets only.
IP_TOS Specifies the TOS value to place in the IP header.
IP_TTL Specifies the TTL value to plate in the IP header.
The following options are recognized at the IPPROTO_TCP level:
TCP_NODELAY Don’t delay sends in an attempt to combine future

data packets.
TCP_MAXSEG Set the maximum TCP segment size.
TCP_NOPUSH Don’t send just to finish a data block.
TCP_NOOPT Don’t use TCP options.

listen Listen for Connection Requests on Socket
Syntax int listen( int s, int maxcon );
maxcon Maximum number of connects to queue

EOPNOTSUPP The socket is not of a type that supports the
operation listen.
EISCONN The socket is already connected.
Description The listen() function listens for connection requests on a socket.
To accept connections, a socket is first created with socket(), The listen() func-
tion is called to specify a willingness to accept incoming connections and a
queue limit for incoming. New connections are accepted by calling the accept()
function. The listen() function applies only to sockets of type SOCK_STREAM.
The maxcon parameter defines the maximum length the queue of pending
connections may grow to. If a connection request arrives with the queue full,
the client receives an error with an indication of ECONNREFUSED.
recv Receive Data from a Socket
Syntax int recv( int s, void *pbuf, int size, int flags );
pbuf Data buffer to place received data
size Size of desired data
flags Option flags
Return Value If it succeeds, the function returns the number of bytes received. Otherwise,
a value of –1 is returned and the function fdError() can be called to determine
the error:

3-22
ENOTCONN The socket is connection oriented and not con-

nected.
EWOULDBLOCK The socket is specified as non-blocking, or the
timeout has expired.
Description The recv() function attempts to receive data from a socket. It is normally used
on a connected socket (see connect()). The data is placed into the buffer spe-
cified by pbuf, up to a maximum length specified by size. The options in flags
can be used to change the default behavior of the operation.
The functions returns the length of the message on successful completion.
For a datagram type socket, the receive operation always copies one packet’s
worth of data. If the buffer is too short to hold the entire packet, the data is trun-
cated and lost.
If no messages are available at the socket, it waits for a message to arrive, un-
less the socket is non-blocking. The function normally returns any data avail-
able, up to the requested amount, rather than waiting for receipt of the full
amount requested; this behavior is affected by the options specified in flags
as well as the socket-level options SO_RCVLOWAT and SO_RCVTIMEO de-
scribed in getsockopt().
The select call (fdSelect()) may be used to determine when more data arrives.
The flags argument to a recv() call is formed by combining one or more of the
following flags:
MSG_DONTWAIT requests that the operation not block when no data

is available.
MSG_OOB requests receipt of out-of-band data that would not
be received in the normal data stream. Some proto-
cols place expedited data at the head of the normal
data queue, and thus this flag cannot be used with
such protocols.
MSG_PEEK causes the receive operation to return data from the
beginning of the receive queue without removing
that data from the queue. Thus, a subsequent re-
ceive call will return the same data.
MSG_WAITALL requests that the operation block until the full re-
quest is satisfied. However, the call may still return
less data than requested if an error or disconnect
occurs, or the next data to be received is of a differ-
ent type than that returned.

recvfrom Receive Data from a Socket with the Sender’s Name (address)
Syntax int recvfrom( int s, void *pbuf, int size, int flags, PSA pName, int *plen );
pbuf Data buffer to place received data
size Size of desired data
flags Option flags
pName Pointer to place name (address) of sender
the error:
nected.
Description The recvfrom() function attempts to receive data from a socket. It is normally
called with unconnected, non-connection oriented sockets. The data is placed
into the buffer specified by pbuf, up to a maximum length specified by size. The
options in flags can be used to change the default behavior of the operation.
The name (address) of the sender is written to pName.
the sending entity as known to the communications layer. The domain in which
the communication is occurring determines the exact format of the pName pa-
rameter. The plen is a value-result parameter; it should initially contain at least
sizeof( struct sockaddr ), the amount of space pointed to by pName; on return
it will contain the actual length (in bytes) of the address returned.
For a datagram type socket, the receive operation always copies one packet’s
worth of data. If the buffer is too short to hold the entire packet, the data is trun-
cated and lost.
If no messages are available at the socket, it waits for a message to arrive, un-
less the socket is non-blocking. The function normally returns any data avail-
able, up to the requested amount, rather than waiting for receipt of the full
amount requested; this behavior is affected by the options specified in flags
3-24
as well as the socket-level options SO_RCVLOWAT and SO_RCVTIMEO de-

scribed in getsockopt().
The select call (fdSelect()) may be used to determine when more data arrive.
The flags argument to a recv() call is formed by combining one or more of the
following flags:

is available.
MSG_OOB requests receipt of out-of-band data that would not
be received in the normal data stream. Some proto-
cols place expedited data at the head of the normal
data queue, and thus this flag cannot be used with
such protocols.
MSG_PEEK causes the receive operation to return data from the
beginning of the receive queue without removing
that data from the queue. Thus, a subsequent re-
ceive call will return the same data.
MSG_WAITALL requests that the operation block until the full re-
quest is satisfied. However, the call may still return
less data than requested if an error or disconnect
occurs, or the next data to be received is of a differ-
ent type than that returned.
recvnc Receive Data from a Socket without Buffer Copy
Syntax int recvnc( int s, void **ppbuf, int flags, HANDLE *phBuffer );
ppbuf Pointer to receive data buffer pointer
flags Option flags
phBuffer Pointer to receive buffer handle
the error:



nected.
Description The recvnc() function attempts to receive a data buffer from a socket. It is nor-
mally used on a connected socket (see connect()). A pointer to the data buffer
is returned in ppbuf. A system handle used to free the buffer is returned in
phBuffer. Both of these pointers must be valid. The options in flags can be used
to change the default behavior of the operation.
The receive operation always returns one packet buffer. The caller has no con-
trol over the size of the data returned in this buffer.
If no messages are available at the socket, this call waits for a message to ar-
rive, unless the socket is non-blocking. The function returns the data buffer
available.
When the caller no longer needs the data buffer, it is returned to the system
by calling recvncfree(). Repeated failure to free buffers will eventually cause
the stack to stop receiving data.
This function can not be used with sockets of type SOCK_STREAM. When
used with sockets of type SOCK_STREAMNC, out of band data marks are
cleared.
The flags argument to a recv() call can be one of the following flags:
is available.
MSG_WAITALL requests that the operation block until data is avail-
able. Since blocking is the default behavior of a
standard socket, this flag only alters the behavior of
a “non-blocking” socket for this call.
recvncfree Return a Data Buffer Obtained from a No-Copy Receive Operation
Syntax void recvncfree( HANDLE hBuffer );

Parameter(s) hBuffer Handle to receive buffer to free
Description The recvncfree() function is used to free a data buffer obtained from calling ei-
ther recvnc() or recvncfrom(). The calling parameter hBuffer is the handle of
the buffer to free (not the pointer to the buffer).
3-26
recvncfrom Receive Data and Sender’s Name from Socket without Buffer Copy
Syntax int recvncfrom( int s, void **ppbuf, int flags, HANDLE *phBuffer, PSA pName,
int *plen );
ppbuf Pointer to receive data buffer pointer
flags Option flags
phBuffer Pointer to receive buffer handle
pName Pointer to place name (address) of sender
the error:
nected.
Description The recvfrom() function attempts to receive a data buffer from a socket. It is
normally called with unconnected, non-connection oriented sockets. A pointer
to the data buffer is returned in ppbuf. A system handle used to free the buffer
is returned in phBuffer. Both of these pointers must be valid. The options in
flags can be used to change the default behavior of the operation. The name
(address) of the sender is written to pName.
the sending entity as known to the communications layer. The domain in which
the communication is occurring determines the exact format of the pName pa-
rameter. The plen is a value-result parameter; it should initially contain at least
sizeof( struct sockaddr ), the amount of space pointed to by pName; on return
it will contain the actual length (in bytes) of the address returned.
The receive operation always returns one packet buffer. The caller has no con-
trol over the size of the data returned in this buffer.
If no messages are available at the socket, this call waits for a message to ar-
rive, unless the socket is non-blocking. The function returns the data buffer
available.
When the caller no longer needs the data buffer, it is returned to the system
by calling recvncfree(). Repeated failure to free buffers will eventually cause
the stack to stop receiving data.

This function can not be used with sockets of type SOCK_STREAM. When
used with sockets of type SOCK_STREAMNC, out of band data marks are
cleared.
The flags argument to a recv() call can be one of the following flags:

is available.
MSG_WAITALL requests that the operation block until data is avail-
able. Since blocking is the default behavior of a
standard socket, this flag only alters the behavior of
a “non-blocking” socket for this call.
send Transmit Data to a Socket
Syntax int send( int s, void *pbuf, int size, int flags );
pbuf Data buffer holding data to transmit
size Size of data
flags Option flags
Return Value If it succeeds, the function returns the number of bytes sent. Otherwise, a value
of –1 is returned and the function fdError() can be called to determine the error:
nected.
EMSGSIZE The specified size exceeds the limit of the un-
derlying protocol.
ENOBUFS Memory allocation failure while attempting to
send data.
EHOSTUNREACH The remote host was unreachable.
Description The send() function attempts to send data on a socket. It is used on a con-
nected sockets only (see connect()). The data to send is contained in the buffer
specified by pbuf, with a length specified by size. The options in flags can be
used to change the default behavior of the operation.
The functions returns the length of the data transmitted on successful comple-
tion.
3-28
For a datagram type socket, the send operation always copies one packet’s
worth of data. If the buffer is too long to hold the entire packet an error code
of EMSGSIZE is returned.
If there is not transmit buffer space available on a stream type socket, the func-
tion waits for space to become available, unless the socket is non-blocking.
The function normally transmits all the specified data.
The select call (fdSelect()) may be used to determine when the socket is “able
to write”.
The flags argument to a send() call is formed by combining one or more of the
following flags:
MSG_OOB used to send out-of-band data on sockets that

support this notion (e.g., SOCK_STREAM); the
underlying protocol must also support out-of-band
data.
MSG_EOR used to indicate a record mark for protocols that
support the concept.
MSG_EOF requests that the sender side of a socket be shut
down, and that an appropriate indication be sent at
the end of the specified data; this flag is only im-
plemented for SOCK_STREAM sockets in the
PF_INET protocol family, and is used to implement
Transaction TCP.
MSG_DONTROUTE specifies that the packet should not be routed, but
sent only using the ARP table entries.
sendto Transmit Data on a Socket to Designated Destination
Syntax int sendto( int s, void *pbuf, int size, int flags, PSA pName, int len );
pbuf Data buffer holding data to transmit
size Size of data
flags Option flags
pName Pointer to name (address) of destination
len Size of data pointed to by pName
Return Value If it succeeds, the function returns the number of bytes sent. Otherwise, a value
of –1 is returned and the function fdError() can be called to determine the error:


EMSGSIZE The specified size exceeds the limit of the un-
derlying protocol.
ENOBUFS Memory allocation failure while attempting to
send data.
EHOSTUNREACH The remote host was unreachable.
Description The sendto() function attempts to send data on a socket to a specified destina-
tion. It is used on a unconnected, non-connection oriented sockets only (see
connect()). The data to send is contained in the buffer specified by pbuf, with
a length specified by size. The options in flags can be used to change the de-
fault behavior of the operation.
The argument pName is pointer to the address of the destination entity as

known to the communications layer. The domain in which the communication
is occurring determines the exact format of the pName parameter. The len pa-
rameter it should contain the size of name which is sizeof( struct sockaddr ).
The functions returns the length of the data transmitted on successful comple-
tion.
For a datagram type socket, the send operation always copies one packet’s
worth of data. If the buffer is too long to hold the entire packet an error code
of EMSGSIZE is returned.
The select call (fdSelect()) may be used to determine when the socket is “able
to write”.
The flags argument to a send() call is formed by combining one or more of the
following flags:
MSG_OOB used to send out-of-band data on sockets that

support this notion (e.g. SOCK_STREAM); the
underlying protocol must also support out-of-band
data.
MSG_EOR used to indicate a record mark for protocols that
support the concept.
MSG_EOF requests that the sender side of a socket be shut
down, and that an appropriate indication be sent at
the end of the specified data; this flag is only im-
plemented for SOCK_STREAM sockets in the
PF_INET protocol family, and is used to implement
Transaction TCP.
MSG_DONTROUTE specifies that the packet should not be routed, but
sent only using the ARP table entries.
3-30
setsockopt Get the Value of a Socket Option Parameter
Syntax int setsockopt( int s, int level, int op, void *pbuf, int bufsize );
level Option level (SOL_SOCKET, IPPROTO_IP, IPPROTO_TCP)
op Socket option to get
pbuf Pointer to memory buffer
bufsize Size of memory buffer pointed to by pbuf
EINVAL Buffer arguments are invalid.
Description The setsockopt() function sets option values associated with a socket. Options
may exist at multiple protocol levels; they are always present at the uppermost
socket level.
When manipulating socket options, the level at which the option resides and
the name of the option must be specified. To manipulate options at the socket
level, level is specified as SOL_SOCKET. To manipulate options at any other
level the protocol number of the appropriate protocol controlling the option is
supplied. In this implementation, only SOL_SOCKET, IPPROTO_IP, and
IPROTO_TCP are supported.
The parameters pbuf and bufsize identify a buffer which holds the value for the
specified option.
Most socket-level options utilize an int parameter for pbuf. SO_LINGER uses
a struct linger parameter, defined in INC\SOCKET.H, which specifies the de-
sired state of the option and the linger interval (see below). SO_SNDTIMEO
and SO_RCVTIMEO use a struct timeval parameter.
The socket options supported for setsockopt() are the same as defined for get-
sockopt() with the exception of SO_TYPE and SO_ERROR, which can not be
set.
Please see the description of getsockopt() for a list of socket options.

shutdown Close One Half of a Connected Socket
Syntax int shutdown( int s, int how );

how Manner of shutdown
ENOTCONN The specified socket is not connected.
Description The shutdown() function causes all or part of a full-duplex connection on the
socket associated with a socket to be shut down. If how is SHUT_RD (0), fur-
ther receives will be disallowed. If how is SHUT_WR (1), further sends will be
disallowed. If how is SHUT_RDWR (2), further sends and receives will be dis-
allowed.
socket Creates a Socket
Syntax int socket( int domain, int type, int protocol );

Parameter(s) domain Socket domain (PF_INET)
type Socket type (SOCK_DGRAM, SOCK_STREAM,
SOCK_RAW)
protocol Socket protocol (Normally IPPROTO_TCP or
IPPROTO_UDP, but can be anything when type is set to
SOCK_RAW)
Return Value If it succeeds, the function returns a file descriptor representing the socket.
Otherwise, a value of –1 is returned and the function fdError() can be called
to determine the error:
EPFNOSUPPORT The specified domain was not PF_INET.
EPROTOTYPE The type parameter does not support the
protocol parameter.
ESOCKTNOSUPPORT The specified socket type is not supported.
ENOMEM Memory allocation error allocating socket
buffers.
EMFILE The descriptor table is full.
Description The socket() function creates a socket, an endpoint for communication and re-
turns the socket in the form of a file descriptor.
The domain parameter specifies a communications domain within which com-
munication will take place; this selects the protocol/address family that should
3-32
be used. These families are defined in the include file INC\SOCKET.H. This
will always be PF_INET (AF_INET) in this implementation.
The socket type parameter specifies the semantics of communication. Cur-

rently defined types are:
SOCK_STREAM provides sequenced, reliable, two-way connection

based byte streams. An out-of-band data trans-
mission mechanism is supported.
SOCK_STREAMNC identical to SOCK_STREAM except that received
data is not coalesced into a receive holding buffer.
This eliminates one or two receive data copies
(depending on which recv() socket function is
used), but has the potential of tying up multiple
data packets. It should only be used when the
socket is to receive data in large bursts. Out-of-
band data is supported, but only when the tradi-
tional recv() socket calls are used.
SOCK_DGRAM supports datagrams – connectionless, unreliable
messages of a fixed (typically small) maximum
length.
SOCK_RAW similar to SOCK_DGRAM, only allows the use of
any protocol which must be manually constructed
in each datagram by the programmer.
The protocol parameter specifies a particular protocol to be used with the

socket. In this implementation of the stack, SOCK_STREAM must use IPPRO-
TO_TCP, SOCK_DGRAM must use IPPROTO_UDP, and SOCK_RAW is un-
restricted. To remain compatible with the industry, this parameter can be set
to NULL on SOCK_STREAM or SOCK_DGRAM.

Full Duplex Pipes Programming Interface
3.4 Full Duplex Pipes Programming Interface
3.4.1 Synopsis
Although sockets can be used for inter-task communications, it is not the most
efficient method. The stack provides a second data communications model
called pipes, which allow for local connection oriented communications.
A pipe is a full duplex connection oriented file descriptor. When a pipe is

created, both ends of the pipe are returned to the caller as file descriptors. One
end of the pipe can then be passed to another task by first converting it to a
file handle with the fdGetFileHandle() function.
Communications is performed using the standard file and sockets API func-
tions. All the file descriptor functions are supported with pipes: fdSelect(),
fdClose(), fdError(), and fdGetFileHandle().
Also, socket functions send() and recv() are used to write and read data
through the pipe. Both functions also support the following standard sockets
message flags when using pipes:
MSG_PEEK Examine data but don’t consume it.

MSG_DONTWAIT Don’t block on send/recv operation (by default, pipe
operations always block).
Pipes are connection oriented, thus when one end closes the other end is al-
tered by an error return from send() or recv(). It is therefore possible to make
a blocking call on recv() without concern that the function will be deadlocked
if the other end terminates the connection.
3-34
Full Duplex Pipes Programming Interface
3.4.2 Pipe API Functions

Since pipes share file descriptor and IO functions with sockets, the only pipe
oriented function is the creation of the connected pair.
pipe Create a Full Duplex Pipe
Syntax int pipe( int *fd1, int *fd2 );
Parameter(s) fd1 File descriptor to first end of pipe

fd2 File descriptor to second end of pipe
Return Value File descriptor or –1 on error. A more detailed error code can be found by call-
ing fdError().
Description Creates a pre-connected full duplex pipe. The returned file descriptors can be
used with all the “fd” file descriptor functions, as well as the send() and recv()
socket functions.
Pipes are connection oriented, so like TCP, a read or write call can return EN-
OTCONN when the connection is broken by one side or the other.
Note that BOTH file descriptors must be closed to correctly close down
(and free) a pipe.

Chapter 4
Initialization and Configuration
The first step in launching a network application is the initialization and configu-
ration of the network stack. This section covers Configuration Manager API
used to maintain system configurations, the Network Control module that uses
the configuration to initialize the network, and the specification of the individual
configuration components available.
Topic Page
4.1 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

4.2 Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.3 Network Control Initialization Procedure (NETCTRL) . . . . . . . . . . . . 4-19
4.4 Configuration Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4-1
Configuration Overview
4.1 Configuration Overview

One of the more tedious aspects of using the stack system is the initialization
process. Normally applications programmers need not worry about configura-
tion since it is part of the underlying OS. The target platform for this software
however is the embedded processor space where there is little or no configu-
ration done for the programmer, and the programmer must usually develop
custom boot code as well.
The TCP/IP stack is supplied with three things that make the configuration and
boot process a little easier for the programmer. First, there is a programming
API for creating, walking, and editing a system configurations Secondly, initiali-
zation software is provided (with source code) that boots the system using a
configuration created with the configuration API, and completely initializes the
stack environment. Lastly, a user-expandable standard configuration specifi-
cation is defined.
4-2
Configuration Manager
4.2 Configuration Manager
4.2.1 Synopsis
The configuration manager is a collection of API functions that allow a user to
create and manipulate a configuration. The manager API is independent of the
configuration specification.
The configuration is arranged as a database with a master key (called Tag)

which defines the class of configuration item. A second key (called Item) deter-
mines the sub-item type in the tag class. For each tag and item, there can be
multiple instances. Items can be further distinguished by their instance value.
The configuration is based on an active database. That is, any change to the
database can cause an immediate reaction in the system. For example, if a
route is added to the configuration, it is added to the system route table. If the
route is then removed from the configuration, it is removed from the system
route table.
In order to facilitate the active procession of configuration changes in a generic

fashion, the configuration API allows a programmer to install service provider
callback functions that are called to handle specific tag values in the configura-
tion.
Configurations can be set active or inactive. When a configuration is active,

any change to the configuration results in a change in the system. When a con-
figuration is inactive, it behaves like a standard database. Part of the main init-
ialization sequence is the make the system configuration active, and then inac-
tive when shutting down.
Both the configurations and configuration entries are referenced by a generic

handle. Configuration functions (named as CfgXxx()) take a configuration han-
dle parameter, while configuration entry functions (name as CfgEntryXxx())
take a configuration entry handle parameter. These handles are not inter-
changeable.
Configuration entry handles are referenced. This means that each handle con-
tains an internal reference count. This is used so that the handle is not de-
stroyed by one task while another task expects it to stay valid. Functions that
return a configuration entry handle supply a “referenced” handle in that its ref-
erence count had already been incremented for the caller. The caller can hold
this handle indefinitely, but should dereference it when it is through. There are
three calls that dereference a configuration entry handle. These are: CfgRe-
moveEntry(), CfgGetNextEntry(), and most simply CfgEntryDeRef(). See indi-
vidual function descriptions for more information.
Initialization and Configuration 4-3

The PPP module in the stack library and several modules in the NETTOOLS
library make use of a default configuration to store and search for data. The
default configuration is accessed by passing in a NULL configuration handle
to any function that takes the hCfg parameter (except CfgFree()). The default
configuration is specified by calling CfgSetDefault().
The configuration access functions (in functional order) are as follows:
Configuration Functions:
CfgNew() Create a new configuration
CfgFree() Destroy a configuration
CfgSetDefault() Set Default Configuration
CfgGetDefault() Get Default Configuration
CfgLoad() Load configuration from a linear memory
buffer
CfgSave() Save configuration to a linear memory buffer
CfgSetExecuteOrder() Set the Tag Initialization and Shutdown Order
on Execute
CfgExecute() Make the configuration active or inactive
CfgSetService() Sets service callback function for a particular
tag
CfgAddEntry() Add a configuration entry to a configuration
CfgRemoveEntry() Remove entry from configuration
CfgGetEntryCnt() Get the number of item instances for a tag/
item pair
CfgGetEntry() Get a referenced handle to a configuration
entry
CfgGetNextEntry() Return supplied entry handle and get next
entry handle
CfgGetImmediate() Get configuration entry data w/o getting entry
handle
Configuration Entry Functions:

CfgEntryRef() Add a reference to a configuration entry handle
CfgEntryDeRef() Remove a reference to a configuration entry
handle
CfgEntryGetData() Get configuration entry data from entry handle
CfgEntrySetData() Replace data block of entry data using entry
handle
CfgEntryInfo() Get information on a configuration entry handle
4-4
4.2.3 Configuration API Functions
CfgAddEntry Add Configuration Entry to Configuration
Syntax int CfgAddEntry( HANDLE hCfg, uint Tag, uint Item, uint Mode, uint Size,
UINT8 *pData, HANDLE *phCfgEntry );
Parameter(s) hCfg Handle to configuration

Tag Tag value of new entry
Item Item value of new entry
Mode Mode flags for how to add entry
Size Size of entry data pointed to by pData
pData Pointer to entry data
phCfgEntry Pointer to where to write handle of new configuration entry
Return Value Returns 1 on success with successful processing by a service callback func-
tion (see CfgSetService()).
Returns 0 on success with no processing performed by a service callback

function.
Returns less than 0 but greater than CFGERROR_SERVICE on a configura-

tion error.
The possible configuration errors are:

CFGERROR_BADHANDLE Invalid hCfg handle
CFGERROR_BADPARAM Invalid function parameter
CFGERROR_RESOURCES Memory allocation error while adding
entry
Returns less than or equal to CFGERROR_SERVICE when the service call-

back function returns an error. Service errors are specific to the service call-
back functions installed and are thus implementation dependent. The original
error return from the service callback can be retrieved by using the
CFG_GET_SERVICE_ERROR() macro:
ServiceErrorCode = CFG_GET_SERVICE_ERROR( CfgAddEntryRe-
turnValue );
Note: On a service error, the configuration entry is still added to the con-
figuration. And an entry handle is written to phCfgEntry when the pointer
is supplied.
Description This function creates a new configuration entry and adds it to the configuration.
The phCfgEntry parameter is an optional pointer which can return a handle to

the newly added configuration entry. When the phCfgEntry parameter is valid,

the function writes the referenced handle of the new configuration entry to the
location specified by this parameter. It is then the caller’s responsibility to der-
eference this handle when it is finished with it. When the parameter phCfgEntry
is NULL, no entry handle is returned, but the function return value is still valid.
Configuration entry handles are dereferenced by the calling one of the follow-
ing:
CfgEntryDeRef() Stop using the entry
CfgRemoveEntry() Stop using entry and remove it from the configuration
CfgGetNextEntry() Stop using entry and get next entry
If the execution state of the configuration is active (see CfgExecute()), then the
addition of the configuration entry is immediately reflected in the operating
state of the system.
Multiple configuration entries can exist with the same Tag and Item key values.
The system creates a third key (Instance) to track these duplicate keyed en-
tries. However, by default, the configuration system does not allow for fully du-
plicate entries. Entries are full duplicates if there exists another entry with the
same Tag and Item key values and an exact duplicate data section (size and
content). When a full duplicate entry is detected, the new (duplicate) entry is
not created.
The user has some options in how the entry is added to the configuration. This
is done with flags that can be set in the Mode parameter. The default behavior
when adding an object is as follows:
- Multiple instances with the same Tag and Item values are allowed,
however
- Duplicate instances with the same Tag, Item, Size, and pData contents are
ignored.
- New entries are saved to the linear buffer if/when CfgSave() is used.
To modify the default behavior, one, or more of the following flags can be set:
CFG_ADDMODE_UNIQUE Replace all previous entry instances
with this single entry.
CFG_ADDMODE_DUPLICATE Allow full duplicate entry (duplicate Tag,
Item, and entry data). Requests to add
duplicates are normally ignored.
CFG_ADDMODE_NOSAVE Don’t include this entry in the linear
buffer in CfgSave().
Note: Setting both the CFG_ADDMODE_UNIQUE and CFG_ADD-

MODE_DUPLICATE flags is the same as just setting CFG_ADD-
MODE_UNIQUE.
4-6
CfgExecute Set the Execution State (Active/Inactive) of the Configuration
Syntax int CfgExecute( HANDLE hCfg, int fExecute );

fExecute Desired execute state (1=active)
Return Value Returns 0 on success, or less than 0 on an operation error. The possible errors
are:
CFGERROR_ALREADY Configuration is already in desired
state
Description When a configuration is first created, it is in an inactive state. This means that
changes to the configuration are not reflected by changes to the system.
Executing the configuration (setting fExecute to 1) causes all current entries

in the configuration to be loaded, and any further changes in the configuration
to be immediately reflecting in the system.
Disabling execution of the configuration (setting fExecute to 0) causes all con-

figuration entries to be unloaded from the system (note: they are not removed
from the configuration). Any further changes to the configuration are not re-
flected by changes to the system.
CfgFree Destroy a Configuration Handle
Syntax void CfgFree( HANDLE hCfg );
Description Destroys a configuration. Unloads and frees all configuration entries and frees
the configuration handle. After this call, the configuration handle hCfg is inval-
id.

CfgGetDefault Get Default Configuration Handle
Syntax HANDLE CfgGetDefault();
Parameter(s) none
Return Value Returns a handle to the current default configuration, or NULL if none.
Description This function returns the current default configuration handle. The default han-
dle is used in any function that takes a hCfg parameter, when the specified pa-
rameter is NULL. At initialization, there is no default configuration. It must be
allocated by CfgNew() and then specified via CfgSetDefault(). Normally, the
default configuration is reserved for system use.
CfgGetEntry Get Configuration Entry from Configuration
Syntax int CfgGetEntry( HANDLE hCfg, uint Tag, uint Item, uint Index, HANDLE
*phCfgEntry );

Tag Tag value of entry
Item Item value of entry
Index Instance index to get (1 to n )
phCfgEntry Pointer to where to write configuration entry handle
Return Value Returns 1 if a matching entry was found

Returns 0 if a matching entry was not found
Returns less than 0 on error

Description This function searches the configuration for entries matching the supplied Tag
and Item parameters and returns the item matching the supplied Index param-
eter. For example if Index is 1, the first instance is returned, if Index is 2, the
second instance is returned. The total number of instances can be found by
calling CfgGetEntryCnt().
The phCfgEntry parameter is an optional pointer which can return the handle
to the configuration entry found by this function. When the phCfgEntry param-
eter is valid, the function writes the referenced handle of the configuration
entry found to the location specified by this parameter. It is then the caller’s re-
4-8
sponsibility to dereference this handle when it is finished with it. When the pa-
rameter phCfgEntry is NULL, no entry handle is returned, but the function re-
turn value is still valid (“found” or “not found”).
ing:
Note: Do not attempt to use the Index value to enumerate all entry instances
in the configuration. The index of an entry handle is valid only at the time of the
call as an item can move up and down in the list as configuration changes are
made. To enumerate every entry for a Tag/Item pair, start with index 1, and then
use CfgGetNextEntry() to get additional entries.
CfgGetEntryCnt Get the Number of Entry Instances for the Supplied Tag/Item Pair
Syntax int CfgGetEntryCnt( HANDLE hCfg, uint Tag, uint Item );

Tag Tag value of query
Item Item value of query
Return Value Returns 0 or greater on success (number if instances found) or less than 0 on
error. The possible errors are:
Description This function searches the configuration for all instances matching the sup-
plied Tag and Item parameters and returns the number of instances found.
CfgGetImmediate Get Configuration Entry Data Directly from Configuration
Syntax int CfgGetImmediate( HANDLE hCfg, uint Tag, uint Item, uint Index, int Size,
UINT8 *pData );

Tag Tag value of entry
Item Item value of entry

Index Instance index to get (1 to n)

Size Size of buffer to receive data
pData Pointer to data buffer to receive data
Return Value Number of bytes copied
Description This function is a useful shortcut when searching the configuration for well
known entries. It searches the configuration for entries matching the supplied
Tag and Item parameters and uses the item matching the supplied Index pa-
rameter. For example if Index is 1, the first instance is used, if Index is 2, the
second instance is used. The total number of instances can be found by calling
CfgGetEntryCnt().
Instead of returning a referenced handle to the configuration entry (as with the
more generic CfgGetEntry() function), this function immediately gets the entry
data for this entry and copies it to the data buffer pointed to by pData.
With simplicity comes some cost in flexibility. This function simply returns the
number of bytes copied, so it will return 0 for any of the following reasons:
- a supplied parameter is incorrect
- the item was not found
- the supplied buffer size (specified by Size) was not large enough to hold
the data
CfgGetNextEntry Get the Next Entry Instance Matching the Supplied Entry Handle
Syntax int CfgGetNextEntry( HANDLE hCfg, HANDLE hCfgEntry, HANDLE

*phCfgEntryNext );
Parameter(s) hCfg Handle to configurationh
CfgEntry Handle to last configuration entry
phCfgEntryNext Pointer to receive handle of next configuration entry
Return Value Returns 1 if a next entry was found
Returns 0 if a next entry was not found
Returns less than 0 on error
Note: The handle hCfgEntry is not dereferenced on the event of an error.
Description This function serves two purposes. First, it dereferences the configuration
entry handle supplied in hCfgEntry. So after this call, the handle is invalid (un-
less there was more than 1 reference to it). Secondly, this function returns a
referenced configuration entry handle to the next instance (if any) of an entry
that matches the Tag and Item values of the supplied entry.
4-10
When the parameter phCfgEntryNext is NULL, no entry handle is returned, but

the function always returns 1 if such an entry was found and 0 when not.
When the phCfgEntryNext parameter is not NULL, the function writes a refer-
enced handle to the configuration entry to the location specified by this param-
eter. It is then the caller’s responsibility to dereference this handle when it is
finished with it.
ing:

CfgLoad Load a Configuration from a Linear Memory Block
Syntax int CfgLoad( HANDLE hCfg, int Size, UINT8 *pData );

Size Size of memory block to load
pData Pointer to memory block to load
Return Value Returns the number of bytes loaded, or less than 0 on an error. The possible
errors are:
Description One of the features of the configuration system is the ability for the manager
to convert a configuration database to a linear block of memory for storage in
non-volatile memory. The configuration can then be converted back on reboot.
This function converts a linear block of memory to a configuration. This is done

by loading each configuration entry it finds in the coded data block. Note that
CfgLoad() can be used to load entries into a configuration that already has pre-
existing entries, but the method of entry is not preserved (see Mode parameter
of CfgAddEntry()). In order to ensure that the resulting configuration exactly
matches the one converted with CfgSave(), this function should only be called
on an empty configuration handle.

CfgNew Create a New Configuration
Syntax HANDLE CfgNew();
Parameter(s) none
Return Value Returns handle to new configuration or NULL on memory allocation error.
Description Creates a configuration handle that can be used with other configuration func-
tions. The new handle defaults to the inactive state (see CfgExecute()).
CfgRemoveEntry Remove Configuration Entry from Configuration by Handle
Syntax int CfgRemoveEntry( HANDLE hCfg, HANDLE hCfgEntry );

hCfgEntry Configuration entry to remove
Return Value Returns 0 on success or less than 0 on error. The possible errors are:
Note: The handle hCfgEntry is not dereferenced on the event of an error.
Description This function removes a configuration entry from a configuration.
If the execution state of the configuration is active (see CfgExecute()), then the
removal of the configuration entry is immediately reflected in the operating
state of the system.
This function also performs a single dereference operation on the configura-

tion entry handle, so the handle is invalid after the call (unless there was more
than 1 reference made). Although the entry handle is not freed until all handle
references have been removed, it is always removed from the configuration
immediately.
4-12
CfgSave Save a Configuration to a Linear Memory Block
Syntax int CfgSave( HANDLE hCfg, int *pSize, UINT8 *pData );

pSize Pointer to size of memory block
pData Pointer to memory block to load
Return Value Returns the number of bytes written, 0 on a “size error” (value at pSize set to
required size), or less than 0 on an operation error. The possible errors are:
Description One of the features of the configuration system is the ability for the manager
to convert a configuration database to a linear block of memory for storage in
non-volatile memory. The configuration can then be converted back on reboot.
This function saves the contents of the configuration specified by hCfg into the
linear block of memory pointed to by pData.
The size of the data buffer is initially pointed to by the pSize parameter. If this
size value pointed to by this pointer is zero (pSize can not itself be NULL), the
function does not attempt to save the configuration but rather calculates the
size required and writes this value to the location specified by pSize. In fact,
any time the value at pSize is less than the size required to store the configura-
tion, the function returns 0 and the value at pSize is set to the size required to
store the data.
The pData parameter points to the data buffer to receive the configuration in-
formation. This pointer can be null if *pSize is zero. Note that the pointer pSize
must always be valid.
CfgSetDefault Set Default Configuration Handle
Syntax HANDLE CfgGetDefault();

Parameter(s) hCfg Handle to configuration to set as default, or NULL to clear
default
Description This function sets the current default configuration handle to that specified in
hCfg. The default handle is used in any function that takes a hCfg parameter,
when the specified parameter is NULL. At initialization, there is no default con-
figuration. It must be allocated by CfgNew() and then specified via CfgSetDe-
fault(). Normally, the default configuration is reserved for system use. The de-
fault configuration handle should not be freed until it is cleared by calling
CfgSetDefault(0).

CfgSetService Set Service Callback Function for Configuration Tag
Syntax int CfgSetService( HANDLE hCfg, uint Tag, int (*pCb) (HANDLE, uint, uint,
uint, HANDLE) );

Tag Tag value to change
pCb Pointer to service callback function
Return Value Returns 0 on success, or less than 0 on error. The possible errors are:
Description In order to give the configuration the ability to be “active” – i.e., to make real-
time changes to the system as the configuration changes, the configuration
manager must have the ability to make changes to the system. To enable this
in a generic fashion, the configuration manager allows for the installation of
service callback functions for each configuration tag value.
This function sets the service function for a particular configuration tag. Ser-
vice function pointers default to NULL, and when they are NULL, no service
is performed for the configuration entry (it becomes information data only).
When invoked, the service callback function is passed back information about
the affected entry. The callback function is defined as:
int CbSrv( HANDLE hCfg, uint Tag, uint Item, uint Op,
HANDLE hCfgEntry );
hCfg HANDLE to Config
Tag Tag value of entry changed
Item Item value of entry changed
Op Operation (CFGOP_ADD or CFGOP_REMOVE)
hCfgEntry Non-Referenced HANDLE to entry added or removed
The callback should return 1 on success, 0 on “pass”, and <0 on error.
Note: The configuration entry handle passed to the callback function is NOT
referenced in that its scope expires when the callback function returns.
CfgSetExecuteOrder Set the Tag Initialization and Shutdown Order on Execute
Syntax int CfgSetExecuteOrder( HANDLE hCfg, uint Tags, uint *pOpenOrder, uint
*pCloseOrder );

Tags Number of tag values in pOpenOrder and pCloseOrder
4-14
pOpenOrder Pointer to array of tag values in initialization order

pCloseOrder Pointer to array of tag values in shutdown order
Return Value Returns zero on success, or less than 0 on an operation error. The possible
errors are:
Description The configuration API has no knowledge of the configuration database specifi-
cation. Thus, it has no concept of a priority in loading and unloading configura-
tion entries. The default order for both loading and unloading is by ascending
tag value.
An application may wish to specify the exact order in which entries should be
initialized ( specified in pOpenOrder) and shutdown (specified in pCloseOder).
Both arrays must be provided – even if they are identical pointers. The number
of elements in each array is specified by the Tags parameter. This must exactly
match the max number of tags in the system defined by CFGTAG_MAX. An
entry of 0 in either order array is used as a placeholder for tags that have not
yet been defined.
4.2.4 Configuration Entry API Functions
CfgEntryDeRef Remove a Reference to a Configuration Entry Handle
Syntax int CfgEntryDeRef( HANDLE hCfgEntry );
Parameter(s) hCfgEntry Handle to configuration entry
are:
CFGERROR_BADHANDLE Invalid hCfgEntry handle
Description This function removes a reference to the configuration entry handle supplied
in hCfgEntry. It is called by an application when it wishes to discard a refer-
enced configuration entry handle. Once this function is called, the handle
should no longer be used.

CfgEntryGetData Get Configuration Entry Data
Syntax int CfgEntryGetData( HANDLE hCfgEntry, int *pSize, UINT8 *pData );

pSize Pointer to size of data buffer
pData Pointer to data buffer
Return Value Returns the number of bytes written, 0 on a “size error” (value at pSize set to
required size), or less than 0 on an operation error. The possible errors are:
Description This function is used to get the entry data of the configuration entry specified
by the entry handle in hCfgEntry.
The value pointed to by pSize is set to the size of the supplied buffer, or zero
to get the required size (the pointer pSize must be valid, but the value at the
pointer can be zero). If the value at pSize is zero, or less than the number of
bytes required to hold the entry data, this function returns 0, and the number
of bytes required to hold the data is stored at pSize.
The pData parameter points to the data buffer to receive the configuration
entry data. This pointer can be null if *pSize is zero.
CfgEntryInfo Get Information on a Configuration Entry
Syntax int CfgEntryInfo( HANDLE hCfgEntry, int *pSize, UINT8 **ppData );

pSize Location to receive the size of the configuration entry data
buffer
ppData Location to receive the pointer to the configuration entry data
buffer
are:
Description This function is used to get the size and pointer to a configuration entry’s data
buffer.
The entry handle is supplied hCfgEntry. A pointer to receive the size of the
entry’s data buffer is supplied in pSize, and a pointer to receive a pointer to the
entry’s data buffer is supplied in ppData. Either pointer parameter can be left
NULL if the information is not required.
4-16
This function should be used with great care. Direct manipulation of the config-
uration entry data should only be attempted on informational tags, and only
when the caller holds a referenced handle to the configuration entry. This func-
tion is used in configuration service callback functions, which are called only
when the configuration is in a protected state.
CfgEntryRef Add a Reference to a Configuration Entry Handle
Syntax int CfgEntryRef( HANDLE hCfgEntry );
are:
Description This function adds a reference to the configuration entry handle supplied in
hCfgEntry. It is called by an application when it intends to use an configuration
entry handle beyond the scope of the function which obtained it from the con-
figuration. This normally occurs when one user function calls another and
passes it a handle.
The handle should be dereferenced when no longer needed. Configuration

entry handles are dereferenced by the calling one of the following:
- CfgEntryDeRef() – Stop using the entry

- CfgRemoveEntry() – Stop using entry and remove it from the configuration
- CfgGetNextEntry() – Stop using entry and get next entry
CfgEntrySetData (Re)Set Configuration Entry Data
Syntax int CfgEntrySetData( HANDLE hCfgEntry, int Size, UINT8 *pData );

Size Size of data buffer
pData Pointer to data buffer
Return Value Returns the number of bytes written, 0 on a “size error” (new size does not
match old size), or less than 0 on an operation error. The possible errors are:
Description This function is used to replace the entry data of the configuration entry speci-
fied by the entry handle in hCfgEntry.

The new entry data is pointed to by the pData parameter with a size indicated
by Size. Note that the new data must be an exact replacement for the old. The
size of the new buffer must exactly match the old size.
This function should be used for configuration entries that are for information
purposes only. Note that if a service provider callback is associated with the
Tag value of this entry, the processing function is not called as a result of this
data update. This function only updates the data stored for this configuration
entry.
4-18
Network Control Initialization Procedure (NETCTRL)
4.3 Network Control Initialization Procedure (NETCTRL)
4.3.1 Synopsis
As previously mentioned, the configuration and initialization of the stack is per-

haps the most tedious part of its operation. For this reason, the stack library
includes code to perform system initialization based on a configuration
constructed by the programmer. This configuration can be manually built
through the configuration API, or can be built by the end user with a configura-
tion utility (not included in the stack).
The basic initialization the scheduling routines are performed by a network

control layer called NETCTRL. The source code to this layer is user service-
able. See the NDK User’s Guide and the NDK Porting Guide for more details.
4.3.2 Basics
The basic process of stack initialization is as follows:
1) Initialize the operating system environment with the initialization function

NC_SystemOpen(). This function must always be called first – before any
other TCP/IP stack related function.
2) Create a new configuration via CfgNew().
3) Build the new configuration via configuration API calls, or load a previous
configuration from non-volatile memory using CfgLoad().
4) Boot the stack with the configuration by calling NC_NetStart( hCfg,

pfnStart, pfnStop, pfnNetIP ) with a handle to the configuration, plus point-
ers to three user supplied callback functions for “start”, “stop”, and IP ad-
dress change operations. The NC_NetStart() function does not return until
the stack session has terminated. The configuration handle hCfg be-
comes the default configuration for the system.
5) After some preliminary initialization, the NC_NetStart() function creates a

new thread that calls the user supplied callback function for the “start” op-
eration. At this point, the callback function creates task threads for its net-
working requirements. This “start” function does not need to return imme-
diately, but should return at some point – i.e., the callback function should
not take permanent control of the calling thread. If system shutdown is initi-
ated before the “start” function returns, some resources may not be freed.

6) Under normal operation, the network does not shutdown until the
NC_NetStop() function is called. At some point after a call to
NC_NetStop(), the original NC_NetStart() thread calls the user supplied
callback function for the “stop” operation. In this callback function, the
application shuts down any operation it initiated in the “start” callback
function and frees any allocated resources. After the “stop” callback
function returns, TCP/IP stack functionality is no longer available.
7) The original call to NC_NetStart() returns with the return value as set by
the return parameter passed in the call to NC_NetStop(). The application
can immediately reboot the TCP/IP stack by calling NC_NetStart() again
with or without reloading a new configuration. This is useful for a reboot”
command.
When the system is ready for a final shutdown, the following actions are per-
formed:
8) When NC_NetStart() returns and the session is over, call the CfgFree()
function to free the configuration handle created with CfgNew().
9) After all resources have been freed, call the NC_SystemClose() function
to complete the system shutdown.

The system initialization access functions (in functional order) are as follows:
NC_SytemOpen() Initiate a system session
NC_SystemClose() Full system shutdown
NC_NetStart() Start the network with a supplied configuration
NC_NetStop() Halt the network, and pass a return code the
caller of the NC_NetStart() function.
4.3.4 Network Control (NC) API Functions
NC_NetStart Start Network
Syntax int NC_NetStart( HANDLE hCfg,

void (*NetStartCb)(), void (*NetStopCb)(),
void (*NetIPCb)(IPN,uint,uint) );
Parameter(s) hCfg Handle to network configuration

NetStartCb Pointer to callback function called when network is started
NetStopCb Pointer to callback function called when network is stopped
4-20
NetIPCb Pointer to callback function called when an IP address is

added or removed from the system
Return Value Returns the integer value passed to NC_NetStop().
Description This function is called to boot up the network using the network configuration
supplied in hCfg. Along with the network configuration, three callback function
pointers are provided. These callback functions are called at distinct times.
NetStartCb() is called when the system is first ready for the creation of applica-
tion supplied network tasks, and NetStopCb() is called when the network is
about to shutdown, and NetIPCb() is call when an IP address is added or re-
moved from the system. If any of these callback functions are not required, the
function pointers can be set to NULL.
The NC_NetStart() function will not return until the entire network session has
completed. Thus all user supplied network code (creation of user tasks) should
be included in the NetStartCb() function.
When NetStartCb() is called, the configuration handle supplied in hCfg is the

default configuration handle for the system. The execution thread on which
NetStartCb() is called is not critical to event scheduling, but it should return
eventually. I.e.: the application should not take control of the thread. If system
shutdown is initiated before this callback function returns, some resources
may not be freed.
Excluding critical errors, NC_NetStart() will return only if an application calls

the NC_NetStop() function. The parameter passed to NC_NetStop() becomes
the return value returned by NC_NetStart().
Sometime after NC_NetStop() is called, but before NC_NetStart() returns, the

NC_NetStart() thread will make a call to the application’s NetStopCb() callback
function. In this callback function, the application should shutdown any task
initiated in its NetStartCb() callback.
When an IP addressing change is made to the system, the NetIPCb() function

is called. The callback function is declared as:
void NetIPCb( IPN IPAddr, uint IfIndex, uint fAdd );
IPAddr – IP Address being added or removed

IfIndex – Index of physical interface gaining or losing the IP address
fAdd – Set to 1 when adding an address, or 0 when removing an address.
The NetIPCb() callback is purely informational, and no processing need be

done on the information provided.

The user has the option of immediately calling NC_NetStart() again upon re-
turn. This makes for a good stack reboot function. Optionally, the configuration
can also be reloaded. This allows the stack to be restarted after a major config-
uration change.
The callback functions return void, and take no calling parameters.
NC_NetStop Stop Network
Syntax void NC_NetStop( int StopCode );
Parameter(s) StopCode Return code to be returned by NC_NetStart()
Description This function is called to shutdown a network initiated with NC_NetStart(). The
return value supplied in the StopCode parameter becomes the return value for
NC_NetStart(). See the description of NC_NetStart() for more detail.
NC_SystemOpen Initiate a System Session
Syntax void NC_SystemOpen();
Parameter(s) none
Description This is the first function that should be called when using the stack. It initializes
the stack’s memory manager, and the OS (or OS translation layer).
NC_SystemClose Shutdown the System
Syntax void NC_SystemClose();
Parameter(s) none
Description This is the last function that should be called when using the stack. It shuts
down the memory manager and performs a final memory analysis.
4-22
Configuration Specification
4.4 Configuration Specification
4.4.1 Synopsis
The specification of all the various configuration options for the stack would
require a separate document. This section details that part of the configuration
that is relied upon by the Network Control (NC) initialization functions, or the
services contained in the NETTOOLS library. The stack itself does not refer-
ence the configuration system. It has its own (vastly simpler) method that is
detailed in the appendix, but it is redundant when using the configuration API
(in fact they conflict as the Net Control functions assume full control of it).
4.4.2 Organization
As already mentioned, the configuration is arranged as a database with the
value “Tag” as a major key, and the value “Item” as a minor key. Every major
stack configuration component has a major key (“Tag”) value, including: net-
work services (protocol servers), connected IP networks, gateway routes,
connected client entities, global system information, and low-level stack con-
figuration.
Most of these tags require service callback functions to implement the system
functionality. For example, when a user adds an IP network using the
CFGTAG_IPNET tag, there must be a function that makes the corresponding
system calls that actually adds the network to the system route table. All these
server callback functions are contained in the NETCTRL directory. Although
source code to these functions is provided, many of the system calls they make
can only be understood by reading the attached appendices.
The tag values currently defined are:
CFGTAG_SERVICE Network Service
CFGTAG_IPNET IP Network (Address, subnet mask, etc.)
CFGTAG_ROUTE IP Gateway Route
CFGTAG_CLIENT IP Client (Client IP, Hostname, etc.)
CFGTAG_ACCT Client user account (name, password, etc.)
CFGTAG_SYSINFO Global System Information
CFGTAG_STACK Low-level Stack Configuration
CFGTAG_OS Operating System Configuration Entry
CFGTAG_IP IP Stack Configuration Entry
4.4.3 Network Service Specification (CFGTAG_SERVICE)

The network services tag is perhaps the most time saving feature of the config-
uration. It allows the application programmer to instruct the system of what
tasks to execute, and how they should be executed. It is also the most compli-
cated configuration entry.

Network services are identified by a configuration Tag parameter value of

CFGTAG_SERVICE.
Note that all these services are obtained directly from the NETTOOLS services
API. The configuration system adds a level of abstraction so that a list of ser-
vices can be added to a configuration, and then the service provider callback
functions contained in the Net Control initialization routines can automatically
load the services at runtime without the user calling the NETTOOLS API direct-
ly.
4.4.3.1 Service Types
The type of service is indicated by the value of the Item parameter supplied
to the CfgAddEntry() function. The defined service types include (by Item):
CFGITEM_SERVICE_TELNET Telnet Server
CFGITEM_SERVICE_HTTP HTTP Server
CFGITEM_SERVICE_NAT Network Address Translation
System
CFGITEM_SERVICE_DHCPSERVER DHCP Server
CFGITEM_SERVICE_DHCPCLIENT DHCP Client
CFGITEM_SERVICE_DNSSERVER DNS Server
4.4.3.2 Common Argument Structure
Each individual service has its own specific configuration instance structure,
but they all share a generic argument structure. This is defined as follows:
// Common Service Arguments
typedef struct _ci_srvargs {
uint Item; // Copy of Item value (init to NULL)
HANDLE hService; // Handle to service (init to NULL)
uint Mode; // Flags
uint Status; // Service Status (init to NULL)
uint ReportCode; // Standard NETTOOLS Report Code
uint IfIdx; // If physical index
IPN IPAddr; // Host IP Address
void(*pCbSrv)(uint, uint, uint, HANDLE); // CbFun for status change
} CISARGS;
The individual fields are defined as follows:
- uint Item;
This is a copy of the Item value used when the entry is added to the config-
uration. Its initial value should be NULL, but it is overwritten by the service
provider callback. It is used so that the status callback function can be pro-
vided with the original Item value.
4-24
- HANDLE hService;
This is the handle to the service as returned by the NETTOOLS function

corresponding to the type of service requested. Its initial value should be
NULL, and it is initialized by the service callback function when the service
is started. The value is needed to shutdown the service when the configu-
ration is unloaded.
- uint Mode;
The mode parameter is a collection of flags representing the desired exe-

cution behavior of the service. One or more of the following flags can be
set:
J CIS_FLG_IFIDXVALID – Specifies the IfIdx field is valid.
J CIS_FLG_RESOLVEIP – Requests that IfIdx be resolved to an IP ad-
dress before service execution is initiated.
J CIS_FLG_CALLBYIP – Specifies that the service should be invoked
by IP address. (This is the default behavior when IFIDXVALID is not
set, but this flag can be set with IFIDXVALID when RESOLVEIP is also
set. If IFIDXVALID is set and this bit is not set, the service is invoked by
physical device index.)
J CIS_FLG_RESTARTIPTERM – A service that is dependent on a valid
IP address (as determined by the RESOLVEIP flag) is shutdown if the
IP address becomes invalid. When this flag is set, the service will be
restarted when a new address becomes available. Otherwise; the ser-
vice will not be restarted.
- uint Status;
The status parameter contains the service status as detected by the Net
Control service callback function that initiates the service with NET-
TOOLS. The value of status should be initialized to NULL. Its defined val-
ues are:
J CIS_SRV_STATUS_DISABLED – Service not active (NULL state)
J CIS_SRV_STATUS_WAIT – Net Control is waiting on IP resolution to
start service
J CIS_SRV_STATUS_IPTERM – Service was terminated because it
lost its IP address
J CIS_SRV_STATUS_FAILED – Service failed to initialize via its NET-
TOOLS open function
J CIS_SRV_STATUS_ENABLED – Service enabled and initialized
properly

- uint ReportCode;
All the services available via the configuration can also be launched direct-
ly via a NETTOOLS API. The NETTOOLS service API has a standard ser-
vice reporting callback function that is mirrored by the configuration sys-
tem via the Net Control service provider callback. This variable holds the
last report code reported by the NETTOOLS service invoked by this con-
figuration entry.
- uint IfIdx;
This is the physical device index (1 to n) on which the service is to be exe-

cuted. For example, when launching a DHCP server service, the physical
interface is that connected to the home network. For more generic ser-
vices (like Telnet), the service can be launched by a pre-defined IP ad-
dress (or INADDR_ANY as a wildcard). When launching by IP address
only, this field is left NULL. If the field is valid, the CIS_FLG_IFIDXVALID
flag should be set in Mode.
- IPN IPAddr;
This is the IP address (in network format) on which to initiate the service.
This IP address can specify the wildcard INADDR_ANY, in which case the
service will accept connections to any valid IP address on any device. Note
that some services (like DHCP sever) do not support being launched by IP
address and require a device index (supplied in IfIdx) on which to execute.
void(*pCbSrv)(uint, uint, uint, HANDLE);
The pCbSrv parameter contains a callback function that is called when the
status of the service changes. It can be set to NULL if a callback is not re-
quired. The specification of the callback function is as follows:
void StatusCallback( uint Item, uint Status, uint
Code, HANDLE hCfgEntry )
Item – Item value of entry changed

Status – New status
Code – Report code (if any)
hCfgEntry – Non-Referenced HANDLE to entry with status change
Note that the Status parameter is the same as the Status field described in
this structure. The Code parameter is that returned by the NETTOOLS
service callback, which is a lower-level status callback function used by
Net Control.
4-26
4.4.3.3 Individual Configuration Entry Instance Structures

The following is the definition of the instance structures used for each of the
defined configuration entries using the configuration service tag. Note that all
structures contain the previously mentioned CISARGS structure. Some ser-
vices require more information and their configuration entry structure contains
an additional parameter structure as defined in the service’s NETTOOLS API.
Others do not require a parameter structure.
// Telnet Entry Data
typedef struct _ci_service_telnet {
CISARGS cisargs; // Common arguments
NTPARAM_TELNET param; // Telnet parameters
} CI_SERVICE_TELNET;
// HTTP Server Entry Data
typedef struct _ci_service_http {
} CI_SERVICE_HTTP;
// NAT Service Entry Data
typedef struct _ci_service_nat {
NTPARAM_NAT param; // NAT parameters
} CI_SERVICE_NAT;
// DHCP Server Entry Data
typedef struct _ci_service_dhcps {
NTPARAM_DHCPS param; // DHCPS parameters
} CI_SERVICE_DHCPS;
// DHCP Client Service
typedef struct _ci_service_dhcpc {
NTPARAM_DHCP param; // DHCP parameters
} CI_SERVICE_DHCPC;
// DNS Server Service
typedef struct _ci_service_dnss {
} CI_SERVICE_DNSSERVER;
4.4.3.4 Specifying Network Services

For examples of adding specific network services to the configuration, please
reference the service description in the “Network Tools Library – Services”
section.
4.4.4 IP Network Specification (CFGTAG_IPNET)

The IPNET entry specifies what IP networks are to appear on which physical
interfaces. When specifying an IPNET entry to the configuration, the Tag pa-
rameter is set to CFGTAG_IPNET, and the Item parameter is set to the index
(1 to n) of the physical interface on which the network is to appear.

The IPNET entry instance structure is defined as follows:

// IPNet Instance
typedef struct _ci_ipnet {
uint NetType; // Network address type flags
IPN IPAddr; // IP Address
IPN IPMask; // Subnet Mask
HANDLE hBind; // Binding handle (initially NULL)
char Domain[CFG_DOMAIN_MAX]; // IPNet Domain Name
} CI_IPNET;
- uint NetType;
This is type of network that appears on the interface. The network type de-
termines how the network is treated by some services like NAT, DHCP, and
DNS. The value is a collection of one or more of the following flags:
J CFG_NETTYPE_DYNAMIC – Address created by DHCP CLIENT
J CFG_NETTYPE_VIRTUAL – Virtual Network used by DNS resolver
J CFG_NETTYPE_DHCPS – Virtual Net Server reported by DHCP
SERVER
Most of the flags deal with the virtual network (or home network). If none of
these flags are set, the network is a normal physical network. Note that
virtual and non-virtual networks should not appear on the same interface.
Also, only one network entry on each interface can have any of these flags
set, although more than one of these flags can be set in that one entry.
- IPN IPAddr;
This is the IP address of the stack on the designated interface. When the
NetType flag “DHCPS” is set, this address is also the “gateway” address
reported to DHCP clients served by the DHCP server service.
- IPN IPMask;
This is the IP network subnet mask.
- HANDLE hBind;
This is the stack’s internal binding handle for the network. Each connected
network is represented as a binding internally to the stack. This is dis-
cussed further in the appendices at the end of this document. The value
should be initialized to NULL.
- char Domain[CFG_DOMAIN_MAX];
This is the domain name of the network. It should be a full domain like
“home1.net”, not just “home1”.
4-28
4.4.5 IP Gateway Route Specification (CFGTAG_ROUTE)
The ROUTE entry specifies a route from one network to another via a specified
IP gateway. When specifying a ROUTE entry to the configuration, the Tag pa-
rameter is set to CFGTAG_ROUTE, and the Item parameter is not used (set
to zero).
The ROUTE entry instance structure is defined as follows:
// Route Instance
typedef struct _ci_route {
IPN IPDestAddr; // Destination Network Address
IPN IPDestMask; // Subnet Mask of Destination
IPN IPGateAddr; // Gateway IP Address
HANDLE hRoute; // Route handle (initially NULL)
} CI_ROUTE;
- IPN IPDestAddr;
This is the IP base address of the IP network of the network that is made
accessible via the IP gateway. This value should be pre-masked with the
IPDestMask so that:
(IPDestAddr & IPDestMask) = IPDestMask
This is used as a sanity check by the system. For a default route, the value
is zero.
- IPN IPDestMask;
This is mask of the IP network accessible by the IP gateway. For a host

route the value is 0xFFFFFFFF, while for a default route, the value is zero.
- IPN IPGateAddr;
This the IP address of the gateway through which the specified IP network
is accessible. It must be an IP address that is available on a locally con-
nected network, i.e., one gateway can not point to another.
- HANDLE hRoute;
This is a handle to the route created by this configuration entry. All routes
are represented as route handles internally to the stack. This is discussed
further in the appendices at the end of this document. The value should be
initialized to NULL.

4.4.6 Client Record Specification (CFGTAG_CLIENT)

The CLIENT entry specifies a record of a client that appears on the indicated
physical interface. When specifying a CLIENT entry to the configuration, the
Tag parameter is set to CFGTAG_CLIENT, and the Item parameter is set to
the index (1 to n) of the physical interface on which the client appears.
Client records exist for two purposes:
1) They are used to resolve DNS queries on virtual networks
2) They are used by the DHCP server service to track DHCP clients on the
serviced virtual network.
Client records are created automatically in some DHCP server configurations

(when using an address pool), but they can also be added manually. This al-
lows an application to build a pre-defined fixed list of clients and their desig-
nated IP addresses on a virtual (home) network.
The CLIENT entry instance structure is defined as follows:

typedef struct _ci_client {
uint ClientType; // Entry Status
uint Status; // DHCPS Status (init to ZERO)
IPN IPAddr; // Client IP Address
char MacAddr[6]; // Client Physical Address
char Hostname[CFG_HOSTNAME_MAX]; // Client Hostname
UINT32 TimeStatus; // Time of last status change
UINT32 TimeExpire; // Expiration Time from TimeStatus
} CI_CLIENT;
- uint ClientType;
This is type of client record. There are only two types – those created by
DHCP server from an address pool, and those created manually by an ap-
plication.
J CFG_CLIENTTYPE_DYNAMIC – Entry created via DHCPS
J CFG_CLIENTTYPE_STATIC – Entry created manually
- uint Status;
This is status of the client record. It is used by the DHCP server to track the
state of the client and its lease to its IP address. The status can also be
NULL for STATIC entries.
J CFG_CLIENTSTATUS_PENDING – Supplied via DHCP OFFER
J CFG_CLIENTSTATUS_VALID – Validated by DHCP REQUEST
4-30
J CFG_CLIENTSTATUS_STATIC – Reported via DHCP INFORM or

non-DHCP application
J CFG_CLIENTSTATUS_INVALID – Invalidated by DHCP DECLINE
- IPN IPAddr;
This is IP address of the client.
- char MacAddr[6];
This is physical Ethernet address of the client.
- char Hostname[CFG_HOSTNAME_MAX];
This is the hostname of the client. It is recorded by the DHCP server ser-
vice, even if the record is STATIC. Thus, when running DHCP server, even
with a fixed client list, DHCP clients can specify their own host names, and
this names will be available to the DNS resolver – i.e., DNS server and
DNS client.
- UINT32 TimeStatus;
This is the last time that the Status parameter was validated. It is thus the
start time of a DHCP client lease.
- UINT32 TimeExpire;
This is the total time in seconds of a DHCP client lease reported by the
DHCP server to its clients. When using an address pool for the DHCP
server, the server chooses this value.
4.4.7 Client User Account (CFGTAG_ACCT)

The ACCT entry specifies an account record of a client that has access to the
system. It is used by the PPP server to validate clients with PAP or CHAP.
When specifying a ACCT entry to the configuration, the Tag parameter is set
to CFGTAG_ACCT, and the Item parameter is set to the account type. Current-
ly, the only valid type is for PPP, so valid type are:
CFGITEM_ACCT_PPP PPP user account
The ACCT entry instance structure is defined as follows:

typedef struct _ci_acct {
uint Flags; // Account Flags
char Username[CFG_ACCTSTR_MAX]; // Username
char Password[CFG_ACCTSTR_MAX]; // Password
} CI_ACCT;

- uint Flags;
The flags determine the access granted by channel or group. The chan-
nels or groups that any given PPP server will allow is determined when the
PPP server is invoked. A singe client account can be a member of one or
more groups, thus one or more of the following flags can be set:
J CFG_ACCTFLG_CH1 – Allow access to channel/group 1
- char Username[CFG_ACCTSTR_MAX];
This is the username of the client.
- char Password[CFG_ACCTSTR_MAX];
This is the password corresponding to the supplied client username.
4.4.8 System Information Specification (CFGTAG_SYSINFO)

The SYSINFO entry contains various types of global system information.
There is no service callback function associated with these entries, as they are
static information only. When specifying a SYSINFO entry to the configuration,
the Tag parameter is set to CFGTAG_SYSINFO, and the Item parameter is set
the system information item in question.
Note that the first 256 values for Item are reserved for items that exactly match
the corresponding DHCP protocol information tag value. For example:
#define CFGITEM_DHCP_DOMAINNAMESERVER 6 // Stack’s DNS servers
#define CFGITEM_DHCP_HOSTNAME 12 // Stack’s host name
These values are read by various network services, and are written in one of
two ways.
First, when the standard DHCP client is executing, it will take full control over
the first 256 Item values. It fills in the entries when it obtains its address lease,
and purges them when the lease expires. There is a set of default entries that
the DHCP client will always request. Additional information requests can be
made by configuring the DHCP client, and the resulting replies will be added
to the configuration.
Second, when there is no DHCP client service, the network application must
manually write values to the configuration for the Item values it views as impor-
tant. A minimum configuration would include hostname, domain name, and a
list of domain name servers. Note that multiple IP addresses should be stored
as multiple instances of the same Item, not concatenated together with a lon-
ger byte length.
4-32
4.4.9 OS / IP Stack Configuration Item Specification (CFGTAG_OS, CFGTAG_IP)

The OS and IP tags specify entries that alter various configuration options that
can be adjusted in the operating system and low-level stack operation. When
specifying an entry to the configuration, the Tag parameter is set to
CFGTAG_OS or CFGTAG_IP, and the Item parameter is set to the configura-
tion item to set (these are listed below).
Creating a configuration entry results in an alteration of the system’s internal
configuration structures, but since these entries are also part of the configura-
tion object (hCfg), they can be stored off and recorded as part of the CfgSave()
functionality. Thus using the configuration API has a significant advantage
over modifying the internal structures manually.
Removing an entry restores the default value to the internal stack configura-
tion. Entries that are not present can not be read, and an error return on read
implies the entry is in its default state.
The following is the list of configuration items. All items are of type “int” or “uint”.
They correspond exactly to the internal system configuration structures. For
more information on these fields, see the internal configuration discussion in
both the OS Abstraction section earlier in this document, and the IP stack sec-
tion in the attached appendices.
When creating a configuration entry for one of these tags, the entry should be
specified to be “unique”. For example, to enable routing in the IP stack that
code would be as follows:
// Enable IP routing
uint tmp = 1;
CfgAddEntry( hCfg, CFGTAG_IP, CFGITEM_IP_IPFORWARDING,
CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&tmp, 0 );
The following item values correspond directly to the OS and Stack configura-
tion structures _oscfg and _ipcfg. For more information on these structures,
see sections 2.1.2 and A.13.2.
When Tag is CFGTAG_OS, the value of Item can be one of the following:
CFGITEM_OS_DBGPRINTLEVEL Debug message print threshold
CFGITEM_OS_DBGABORTLEVEL Debug message abort thresh-
old
CFGITEM_OS_TASKPRILOW Lowest priority for stack task
CFGITEM_OS_TASKPRINORM Normal priority for stack task
CFGITEM_OS_TASKPRIHIGH Highest priority for stack task
CFGITEM_OS_TASKPRIKERN Kernel-level priority (highest)
CFGITEM_OS_TASKSTKLOW Minimum stack size
CFGITEM_OS_TASKSTKNORM Normal stack size
CFGITEM_OS_TASKSTKHIGH Stack size for high volume
tasks

When Tag is CFGTAG_IP, the value of Item can be one of the following:
CFGITEM_IP_ICMPDOREDIRECT Add route on ICMP redirect

(1=Yes)
CFGITEM_IP_ICMPTTL TTL for ICMP messages
(RFC1700 says 64)
CFGITEM_IP_ICMPTTLECHO TTL for ICMP echo
(RFC1700 says 64)
CFGITEM_IP_IPINDEXSTART IP Protocol Start Index
CFGITEM_IP_IPFORWARDING IP Forwarding Enable
(1=Yes)
CFGITEM_IP_IPNATENABLE IP NAT Translation Enable
(1=Yes)
CFGITEM_IP_IPREASMMAXTIME Max IP reassembly time in
seconds
CFGITEM_IP_IPREASMMAXSIZE Max IP reassembly packet
size
CFGITEM_IP_RTCENABLEDEBUG Enable route control dbg
messages (1=Yes)
CFGITEM_IP_RTCADVTIME Time in sec to send Router
Adv. (0=don’t)
CFGITEM_IP_RTCADVLIFE Lifetime of route in RtAdv if
active
CFGITEM_IP_RTCADVPREF Preference of route in RtAdv
if active
CFGITEM_IP_RTARPDOWNTIME Time 5 failed ARPs keeps
route down
CFGITEM_IP_RTKEEPALIVETIME Timeout of validated route in
seconds
CFGITEM_IP_RTCLONETIMEOUT Timeout of newly cloned
route in seconds
CFGITEM_IP_RTDEFAULTMTU MTU for internal routes
CFGITEM_IP_SOCKTTLDEFAULT Default IP TTL for Sockets
CFGITEM_IP_SOCKTOSDEFAULT Default IP TOS for Sockets
CFGITEM_IP_SOCKMAXCONNECT Max connections on listening
socket
CFGITEM_IP_SOCKTIMECONNECT Max time for connect socket
CFGITEM_IP_SOCKTIMEIO Default Max time for socket
send/rcv
CFGITEM_IP_SOCKBUFMAX Absolute max socket buffer
size
CFGITEM_IP_SOCKMINTX Default min tx space for
“able to write”
CFGITEM_IP_SOCKMINRX Default min rx data for “able
to read”
4-34
CFGITEM_IP_PIPETIMEIO Max time for pipe send/rcv

call
CFGITEM_IP_PIPEBUFMAX Pipe internal buffer size
CFGITEM_IP_PIPEMINTX Pipe min tx space for “able to
write”
CFGITEM_IP_PIPEMINRX Pipe min rx data for “able to
read”
CFGITEM_IP_STACKMAX Max CFGTAG_STACK item

Chapter 5
Network Tools Library Support Functions
Included with the stack package is a library of network tools. It provides auxilia-
ry functionality to the stack library and contains source written to the socket
layer that would normally be considered application level code. The library file
is called NETTOOLS.LIB, and can be accessed by an application that includes
the file NETTOOLS.H.
The support supplied by NETTOOLS can be categorized into two classes:

support functions and services. The support functions consist of a program-
ming API that can aid the programmer in developing network applications,
while services are servers that execute on the stack platform.
This section describes the NETTOOLS support functions.
Topic Page
5.1 Generic Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.2 DNS Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
5.3 TFTP Support Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5-1
Generic Support Calls
5.1 Generic Support Calls
5.1.1 Synopsis
This section contains a selection of functions that can be very useful when pro-
gramming network applications. Some are standard Berkeley while others are
custom to the stack – designed to save the programmer the time and trouble
of programming directly to the stack API.

The following is a summary of the support functions described in this section:
inet_addr() Convert a string to a 32 bit IP address
in network format
inet_aton() Convert a string to an in_addr structure
record
NtAddNetwork() Add a host network to a logical interface
handle
NtRemoveNetwork() Remove a network added with NtAdd-
Network()
NtAddStaticGateway() Add a static gateway route to the route
table
NtRemoveStaticGateway() Remove a static gateway route
NtIfIdx2Ip() Get the IP host address assigned to a
physical interface index
NtGetPublicHost() Get the system public IP address and
domain name
NtIPN2Str() Convert 32 bit IP address in network
format to string
5.1.3 Network Tools Support API Functions
inet_addr Return 32-bit binary Network Ordered IPv4 Address
Syntax IPN inet_addr( char *strptr );
Parameter(s) strptr Pointer character string
Return Value IP address or NULL
Description This function converts an IP address printed in a character string to a 32bit net-
work ordered IP address value. Note that leading 0’s in the address string are
interpreted as octal. The function returns NULL on failure.
5-2
This function actually calls inet_aton(), which is the better form of the function.
inet_aton Convert IP Address from String and Return in in_addr Structure
Syntax int inet_aton( char *strptr, struct in_addr *pa );

Parameter(s) strptr Pointer character string
pa Pointer to address structure
Return Value 1 on success or 0 on failure
Description This function converts an IP address printed in a character string to a 32bit net-
work ordered IP address value. Note that leading 0’s in the address string are
interpreted as octal. The function returns write the IP address into the in_addr
structure pointed to by the pa parameter. The function returns 1 on success
and 0 on failure.
NtAddNetwork Add Host Network to Interface by IF Handle
Syntax HANDLE NtAddNetwork( HANDLE hIF, IPN IPHost, IPN IPMask );

Parameter(s) hIF Handle to target interface
IPHost IP Host Address (in network format)
IPMask IP Host Subnet Mask (in network format)
Return Value Handle to network binding on success or NULL on failure.
Description This function attempts to add the specified IP host address (and mask) to the
specified logical interface handle. The function returns a handle to the binding
that binds the IP address to the interface. On an error, the function returns
NULL. The most common error would be that adding the host address caused
a “duplicate IP” indication from another host.
Note: In place of this function, the caller should consider using the con-
figuration system with the CFGTAG_IPNET configuration entry (see sec-
tion 4.4.4).
NtRemoveNetwork Remove Host Network from Interface
Syntax void NtRemoveNetwork( HANDLE hBind );

Parameter(s) hBind Handle to network binding returned by NtAddNetwork()
Description This function removes a network that was previously added with NtAddNet-
work().
Network Tools Library Support Functions 5-3

NtAddStaticGateway Add Static Gateway Route to the Route Table
Syntax HANDLE NtAddStaticGateway( IPN IPDestAddr, IPN IPDestMask, IPN IPGa-

teAddr );
Parameter(s) IPDestAddr IP address of destination (in network format)

IPDestMask IP subnet mask of destination (in network format)
IPGateAddr IP address of next hop gateway (in network format)
Return Value Handle to newly created route or NULL on error.
Description This function adds a static gateway route to the system route table.
IPDestAddr is the IP base address of the IP network of the network that is

made accessible via the IP gateway. This value should be pre-masked with the
IPDestMask so that:
(IPDestAddr & IPDestMask) = IPDestMask
This is used as a sanity check by the system. For a default route, the value is
zero.
IPDestMask is the mask of the IP network accessible by the IP gateway. For

a host route the value is 0xFFFFFFFF, while for a default route, the value is
zero.
IPGateAddr is the IP address of the gateway though which the specified IP net-
work is accessible. It must be an IP address that is available on a locally con-
nected network. I.e.: one gateway can not point to another.
The function returns a handle to the route created by this configuration entry.
All routes are represented as route handles internally to the stack. This is dis-
cussed further in the appendices at the end of this document. Note that the
handle returned here is not referenced (see the appendix for more details). All
it means the purposes of this function is that the handle can be discarded by
the caller. It will remain valid until the route is removed via NtRemoveStatic-
Gateway().
Note: In place of this function, the caller should consider using the con-
figuration system with the CFGTAG_ROUTE configuration entry (see
section 4.4.5).
5-4
NtRemoveStaticGateway Remove Static Gateway Route from the Route Table
Syntax int NtRemoveStaticGateway( IPN IPTarget );
Parameter(s) IPTarget IP address of destination to remove (in network format)
Return Value Returns 1 if the route was removed or 0 if it was not found.
Description This function removes a static gateway route from the system route table. It
searches for the route by destination IP address and will remove the first
matching static route it finds. Note that only routes with both the GATEWAY
and STATIC flags set are considered for removal.
NtIfIdx2Ip Get 32-bit Representation of IP Address of Interface Index
Syntax int NtIfIdx2Ip( uint IfIdx, IPN *pIPAddr );
Parameter(s) IfIdx Index of physical interface

pIPAddr Pointer to receive IP address
Return Value Returns 1 if an address was found, or 0 if it was not found.
Description This function obtains the first IP host address found that is assigned to the sup-
plied interface index. The host address (in network format) is written to the
pointer pIPAddr.
NtGetPublicHost Get the System Public IP Address and Domain Name
Syntax int NtGetPublicHost( IPN *pIPAddr, uint MaxSize, UINT8 *pDomain );
Parameter(s) pIPAddr Pointer to receive IP address

MaxSize Size of string buffer pointed to by pDomain
pDomain Pointer to string buffer to receive domain name
Return Value Returns 1 if information was found, or 0 if it was not found.
Description This function gets the “best” IP address and domain name to use for access
to the external network. For determining the “best” address and domain name,
public addresses and domain names are preferred over IP addresses and do-
main names of virtual networks. The IP address (in network format) is written
to pIPAddr, and the domain name is copied to pDomain.

NtIPN2Str Convert 32-bit IP Address in Network Format to String
Syntax void NtIPN2Str( IPN IPAddr, char *pStrBuffer );
Parameter(s) IPAddr IP address in network format

pStrBuffer Pointer to receive IP address string
Description This function performs an sprintf() of the IP address supplied in IPAddr to the
buffer supplied in pStrBuffer. Note, no buffer size is provided. This is because
the size is deterministic, and won’t exceed 16 characters (including the NULL
terminator).
5-6
DNS Support Calls
5.2 DNS Support Calls
5.2.1 Synopsis
The concepts and code behind the Unix gethostbyname() and gethostby-
addr() functions is extensive. And there are public domain versions available,
can be easily run on the IP stack library.
Although the code to support the whole name, address and server database
is quite large, the basic name resolution functions are quite useful. For this rea-
son, the stack provides a basic form of these function calls, without incurring
the overhead associated with a full implementation. The DNS ”resolver” used
by these client functions is the same as accessed by the DNS server. When
the configuration contains ”client” machine records (i.e.: controls local domain
names), these entries are checked when the matching domain is encountered.
Otherwise (and for all other queries); the query is resolved via external DNS
servers.
In addition to providing a more compact implementation, the calls provided

here are reentrant, which is not true of the standard Unix counterparts.

The following is a summary of the support functions described in this section:
DNSGetHostname() Return the hostname of the current host
DNSGetHostByAddr() Resolve a hostname from an IP address
DNSGetHostByName() Resolve a hostname and IP address from
a hostname
5.2.3 Standard Types and Definitions
5.2.3.1 Host Entry Structure
The DNS client functions all take a pointer to a buffer. They treat this buffer as
a pointer to a host entry structure. In the case where the function takes a point-
er to a “scrap” buffer, a host entry structure is allocated from the start of this
scrap buffer. Thus on successful return from one of these calls, the pointer to
the scrap buffer may be treated as a pointer to a host entry structure.

DNS Support Calls
The structure differs slightly from the conventional definition. It is defined as

follows:
//
// Host Entry Structure
//
struct _hostent {
char *h_name; // Official name of host
int h_addrtype; // Address Type (AF_INET)
int h_length; // Address Length (4)
int h_addrcnt; // Number of IP addresses found
IPN h_addr[4]; // List of up to 4 IP addrs (network format)
};
typedef struct _hostent HOSTENT;
5.2.3.2 Function Return Codes

DNS functions that return an error code use the following definitions. Those
that are obtained directly from a DNS response packet are so noted:
NOERROR 0 (DNS Reply Code) no error
FORMERR 1 (DNS Reply Code) format error
SERVFAIL 2 (DNS Reply Code) server failure
NXDOMAIN 3 (DNS Reply Code) non existent domain
NOTIMP 4 (DNS Reply Code) not implemented
REFUSED 5 (DNS Reply Code) query refused
OVERFLOW 16 Scrap Buffer Overflow
MEMERROR 17 Memory Allocation Error (used for packets and
temp storage)
SOCKETERROR 18 Socket Error (call fdError() for socket error num-
ber)
NODNSREPLY 19 No DNS server response
5.2.4 DNS Support API Functions
DNSGetHostname Return the Hostname of the Current Host
Syntax int DNSGetHostname( char *pNameBuf, int size );
Parameter(s) pNameBuf Pointer to a buffer to accept the hostname

size Size of the supplied buffer in bytes
Return Value Error code as defined above
Description This function is quite similar to BSD’s gethostname(). It requests the hostname
of the system’s public IP address (as obtained from NtGetPublicHost()). The
hostname is copied into the buffer pointed to by ‘pNameBuf’ with a max size
of ‘size’. The name is NULL terminated when space allows.
5-8
DNS Support Calls
DNSGetHostByAddr Resolve a Hostname from an IP Address
Syntax int DNSGetHostByAddr( IPN IPAddr, void *pScrapBuf, int size );
Parameter(s) IPAddr IP address to resolve, in network format

pScrapBuf Pointer to a scrap buffer from which a HOSTENT structure will
be allocated
size Size of the supplied scrap buffer in bytes
Description This function is quite similar to BSD’s gethostbyaddr(). It uses DNS to resolve
a hostname from the supplied IP address. On a successful return, ‘pScrapBuf’
can be treated as a HOSTENT structure. The size of the scrap buffer (‘size’)
must be greater than the size of the structure as the structure will contain point-
ers into the scrap buffer, and the scrap buffer is also used for temporary name
storage. 512 bytes should be sufficient for most requests.
DNSGetHostByName Resolve a Hostname/Address from a Hostname
Syntax int DNSGetHostByName( char *Name, void *pScrapBuf, int size );
Parameter(s) Name Null termination Hostname to resolve (with or without trailing

‘.’)
pScrapBuf Pointer to a scrap buffer from which a HOSTENT structure will
be allocated
size Size of the supplied scrap buffer in bytes
Description This function is quite similar to BSD’s gethostbyname(). It uses DNS to resolve
an official hostname and address from the supplied hostname. On a success-
ful return, ‘pScrapBuf’ can be treated as a HOSTENT structure. The size of the
scrap buffer (’size’) must be greater than the size of the structure as the struc-
ture will contain pointers into the scrap buffer, and the scrap buffer is also used
for temporary name storage. 512 bytes should be sufficient for most requests.
If the hostname Name is terminated with a dot (‘.’), the dot is removed prior to
lookup. If a dot appears anywhere in Name, an initial lookup on the unaltered
name is attempted. If Name does not contain a dot, or if the initial lookup fails,
the default domain name (from NtGetPublicHost()) is appended to the end of
the supplied name. For example, if the domain name obtained from NtGetPu-
blicHost() was “ti.com”, then a request for “host.sc” would attempt to resolve
“host.sc” first, and then “host.sc.ti.com”, while a request for “host” would at-
tempt to resolve “host.sc.ti.com” on the initial attempt.

TFTP Support Calls
5.3 TFTP Support Calls
5.3.1 Synopsis
TFTP is supported via the received function. More information on TFTP can
be found in rfc783.
5.3.2 TFTP Support API Functions

TFTP is accessed through this API. The network tools, include file NET-
TOOLS.H, is required.
NtTftpRecv Retrieve Data from a TFTP Server
Syntax int NtTftpRecv( UINT32 TftpIp, char *szFileName, char *pFileBuffer, UINT32
*pFileSize, UINT16 *pErrorCode );
Parameter(s) TftpIp IP Address in network format

szFileName Pointer to null terminated filename string
pFileBuffer Pointer to buffer to receive file data
pFileSize Pointer to size of buffer on input, returns as size needed or
used
pErrorCode Pointer to where to write TFTP server error code (if any)
Return Value This function returns an error code indicating the results of the operation. Neg-
ative codes are error conditions.
In the following cases, pFileSize is set to the actual file size:
- 1 – Successful transfer and copy

- 0 – Successful transfer, with partial copy (file size too large)
In the following cases, pFileSize is set to the actual number of bytes copied:
TFTPERROR_ERRORREPLY Error returned by TFTP server (see
below)
TFTPERROR_BADPARAM Invalid calling parameters
TFTPERROR_RESOURCES Memory allocation error during trans-
fer
TFTPERROR_SOCKET Internal socket error during transfer
TFTPERROR_FAILED TFTP failed (e.g., server didn’t reply)
In the case of TFTPERROR_ERRORREPLY, the server error code written to

*pErrorCode should be one of the following standard TFTP codes, and the er-
ror message is copied to *pFileBuffer:
5-10
TFTP Support Calls
- 0 – Not defined, see error message (if any).

- 1 – File not found.
- 2 – Access violation.
- 3 – Disk full or allocation exceeded.
- 4 – Illegal TFTP operation.
- 5 – Unknown transfer ID.
- 6 – File already exists.
- 7 – No such user.
Description TFTP (Trivial File Transfer Protocol), allows files to be transferred from a re-
mote machine.
This function attempts to receive the file with the filename designated by szFi-
leName from the TFTP server with the IP address in TftpIp, any copy the data
into the memory buffer pointed to by pFileBuffer. Note that when specifying the
name of the file in szFileName, certain operating systems have case sensitive
naming conventions.
On entry, the parameter pFileSize must point the size of the buffer pointed to
by pFileBuffer. If the value at *pFileSize is null, the pFileBuffer parameter can
be NULL.
This function attempts to receive the entire file, even if the buffer space is insuf-
ficient. The return value indicates if the file was received.
A return value of 1 indicates that the file was received and copied into the buff-
er. A return value of 0 indicates that the file was received, but was too large
for the specified buffer. In both these cases, the actual size of the file in bytes
is written back to *pFileSize.
A negative return value indicates that an error has occurred during transfer.
In this case, the number of bytes actually consumed in the buffer is written back
to *pFileSize. An error return of TFTPERROR_ERRORREPLY is a special re-
turn value that indicates that an error code was returned from the TFTP server.
In this case, the server’s TFTP error code is written to *pErrorCode, and the
server’s TFTP error message string is copied to the data buffer pointer to by
pFileBuffer.

Chapter 6
Network Tools Library Services
Included with the stack package is a library of network tools. It provides auxilia-
ry functionality to the stack library and contains source written to the socket
layer that would normally be considered application level code. The library file
is called NETTOOLS.LIB, and can be accessed by an application that includes
the file NETTOOLS.H.
The support supplied by NETTOOLS can be categorized into two classes:

support functions and services. The support functions consist of a program-
ming API that can aid the programmer in developing network applications,
while services are servers that execute on the stack platform.
This section describes the NETTOOLS services.
Topic Page
6.1 Service Calling Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

6.2 Telnet Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
6.3 DHCP Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
6.4 DHCP Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
6.5 HTTP Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.6 DNS Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
6.7 Network Address Translation (NAT) Service . . . . . . . . . . . . . . . . . . . . 6-18
6-1
Service Calling Conventions
6.1 Service Calling Conventions
6.1.1 Specifying Network Services Using the Configuration

Although each service has it own specific API, it is usually more convenient to
add services by specifying the service in the system configuration as opposed
to calling their individual Open and Close API functions. Included the descrip-
tion of each network service is a description of its direct API as well as an exam-
ple of specifying the service in the system configuration.
6.1.1.1 Service Report Function

All the configuration examples in this section use a common service report call-
back function. The following is a very simple implementation of a service report
function that calls printf() to print service status.
Note that this function relies on the physical value of items in the configuration
specification found in the file: src\nettools\netcfg.h
static char *TaskName[]={”Telnet”,”HTTP”,”NAT”,”DHCPS”,”DHCPC”,”DNS”,”SNMP”};

static char *ReportStr[]={””,”Running”,”Updated”,”Complete”,”Fault”};
static char *StatusStr[]={”Disabled”,”Waiting”,”IPTerm”,”Failed”,”Enabled”};
static void ServiceReport( uint Item, uint Status, uint Report, HANDLE h )
{
printf( ”Service Status: %–9s: %–9s: %–9s: %03d\n”,
TaskName[Item–1], StatusStr[Status],
ReportStr[Report/256], Report&0xFF );
}
6.1.2 Invoking Network Services by NETTOOLS API

Each service API uses a common calling format. This allows the services to
be invoked by the configuration system using callback functions provided in
the Network Control software (which also performs system initialization). In
fact, it is preferable to launch services via the configuration system over manu-
ally calling each Open and Close function described in the following sections.
However, since the source to the Network Control software uses these calls,
they are documented here.
The common calling interface consists of a simple Open and Close concept.
The Open function initiates the service and returns a service handle, while the
Close function shuts down the service using the service handle returned from
the Open call.
Each service Open call takes at least one parameter. This parameter is a point-
er to a common argument structure called NTARGS. The specification of this
structure is as follows:
6-2
typedef struct _ntargs {

int CallMode; // Determines desired calling mode
#define NT_MODE_IFIDX 1 // Call by specifying IfIdx
#define NT_MODE_IPADDR 2 // Call by specifying IPAddr
int IfIdx; // Physical interface index (0–n)
IPN IPAddr; // IP Address
HANDLE hCallback; // Handle to pass to callback function
void(*pCb)( HANDLE, uint ); // Callback for status change
} NTARGS;
Note that this structure is a simplified version of that provided by the configura-
tion system. This structure also contains a callback function. The callback
function is a subset of that in the configuration system, and codes returned by
this callback are passed through the configuration callback to the application.
- int CallMode;
This parameter determines how the service is launched, either by IP ad-
dress or by interface index (1 to n).
Some services can be launched either on a specific interface (1 to n) or on
a specific IP address (which can also be the wildcard INADDR_ANY).
Generally, any service that accepts an IP address can also accept an inter-
face. The service will simply lookup the IP address for the specified inter-
face.
Other services can only be executed by interface and are independent of
IP address. These are said to be compatible with NT_MODE_IFIDX only.
The value of CallMode can be one of the following:
J NT_MODE_IFIDX – Call by specifying the interface index (1 to n)
J NT_MODE_IPADDR – Call by specifying IP address in network for-
mat
- int IfIdx;
This is the physical interface index (1 to n) on which the service is to be
executed. For example, when launching a DHCP server service, the
physical interface is that connected to the home network. For more gener-
ic services (like Telnet), the service can be launched by a pre–defined IP
address (or INADDR_ANY as a wildcard). When launching by IP address
only, this field is left NULL. When this field is used, CallMode should be set
to NT_MODE_IFIDX.
- IPN IPAddr;
This is the IP address (in network format) on which to initiate the service.
This IP address can specify the wildcard INADDR_ANY, in which case the
Network Tools Library Services 6-3

service will accept connections to any valid IP address on any device. Note
that some services (like DHCP sever) do not support being launched by IP
address. When this field is used, CallMode should be set to
NT_MODE_IPADDR.
- HANDLE hCallback;
This is the caller supplied handle that is passed back to the caller when the
status callback function is invoked (see below).
- void (*pCb)( HANDLE, uint );
This is a pointer to a caller supplied callback function by which the service

reports status.
The specification of this callback is:
void cbFun( HANDLE hCallback, uint NtStatus );
hCallback – Handle supplied to the service by the caller
NtStatus – NetTools Service Status code
The NtStatus parameter consists of an upper byte which is predefined,
and a lower byte that is specific to the service. When masked with ”~0xFF”
(NOT 0xFF), the value will be one of the following:
J NETTOOLS_STAT_NONE – Nothing reported
J NETTOOLS_STAT_RUNNING – Service is initialized (running)
J NETTOOLS_STAT_PARAMUPDATE – The service parameter struc-
ture has changed (the configuration containing this structure should
be saved)
J NETTOOLS_STAT_COMPLETED – The service has run to comple-
tion
J NETTOOLS_STAT_FAULT – The service has halted to due a fault
Note that this callback function does not go directly to the application when
using the configuration system. These codes are supplied to the configu-
ration service callback in the Code parameter.
An optional second parameter to each service Open function is a pointer to
a private service parameter structure. In the configuration section of this
document, the individual service parameter structures were included in
the specification of the configuration entry instance structure for each ser-
vice.
6-4
Telnet Server Service
6.2 Telnet Server Service
6.2.1 Synopsis
The Telnet Server service provides a mechanism for exposing a stream IO

connection to any remote telnet client console.
A telnet connection is basically just a TCP connection to the “well-known” port

designated for telnet. However, there is some data translation that occurs on
the stream. Telnet has a set of commands that can change the behavior of the
terminal, and can perform some character translation. The telnet server sup-
plied here is designed to convert a normal TTY stream to a telnet stream and
back. This allows any application to treat a telnet session as any other TTY
session (like a serial port).
Connection to an application is achieved by use of an application supplied call-

back function that telnet calls when a new connection is established. This call-
back function returns the file descriptor of one end of a full duplex communica-
tions pipe. By allowing multiple calls to the callback function, console applica-
tions can be written to work with multiple IO streams.
6.2.2 Telnet Parameter Structure
The following structure defines the unique parameters of the Telnet service.
It is located in the file: src\nettools\inc\telnetif.h.
//
// Telnet Parameter Structure
//
typedef struct _ntparam_telnet {
int MaxCon; // Max number of telnet connections
int (*Callback)(PSA); // Connect function returns local pipe
} NTPARAM_TELNET;
- MaxCon – Maximum number of simultaneous telnet sessions (1 to 24)
- Callback – Pointer to a callback function which takes a pointer to a sock-

addr structure, and returns a local file descriptor to one end of a full duplex
communications pipe.
This structure is used both when specifying the service to the configuration
system or when bypassing the configuration and invoking the service API di-
rectly.

6.2.3 Specifying Service Using the Configuration
The service can be specified as public in that it can connect using any IP ad-
dress, or an IP address of a specific interface. When accepting connections
to any system IP address, the service is specified with the “CALLBYIP” flag
and an IP address of INADDR_ANY. When a private connection is desired, the
service is specified by the physical interface on which connections are allowed
to occur. Since an IP address is required to initialize the service, the ”RESOL-
VEIP” flag should also be set in the latter case.
For example, the following code specifies that the telnet server should run us-
ing the IP address INADDR_ANY.
telnet_example()
{
CI_SERVICE_TELNET telnet;
bzero( &telnet, sizeof(telnet) );

telnet.cisargs.IPAddr = INADDR_ANY;
telnet.cisargs.pCbSrv = &ServiceReport;
telnet.param.MaxCon = 2;
telnet.param.Callback = &ConsoleOpen;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_TELNET, 0,
sizeof(telnet), (UINT8 *)&telnet, 0 );
}
The above code is all that is required when using the configuration system to
invoke this service.
6.2.4 Invoking the Service via NETTOOLS API
In addition to the configuration option, this service can also be created and de-
stroyed directly through this NETTOOLS API. If an application wishes to by-
pass the configuration system and launch the service directly, these calls can
be used.
TelnetOpen Create an Instance of the Telnet Server
Syntax HANDLE TelnetOpen( NTARGS *pNTA, NTPARM_TELNET *pNTP );
Parameter(s) pNTA Pointer to common argument structure used by all services

pNTP Pointer to Telnet parameter structure
6-6
Return Value Returns a handle to the new telnet server instance, or NULL if the service could
not be created. This handle is used with TelnetClose() to shutdown the server
when its no longer needed.
Description When a telnet session is established, a telnet child task is spawned which will
call the supplied callback function. This callback function should return a local
file descriptor of one end of a full duplex pipe. If the callback function returns
–1, the connection is aborted. When either the terminal or telnet connection
end of the pipe is broken, the other connection is closed and the session is en-
ded.
TelnetClose Destroy an Instance of the Telnet Server
Syntax void TelnetClose( HANDLE hTelnet );
Parameter(s) hTelnet Handle to telnet server instance obtained from TelnetOpen()
Description Destroys the instance of the telnet sever indicated by the supplied handle.
Once called, the server is shutdown and no more telnet sessions can be estab-
lished. Also, all spawned connections are immediately terminated.

DHCP Server Service
6.3 DHCP Server Service
6.3.1 Synopsis
When acting as a router, the TCP/IP stack may also need to maintain the net-
work configuration on one of its network devices. A DHCP server allows the
stack to maintain the IP address of multiple Ethernet client devices. When
combined with Network Address Translation (NAT), the DHCP server can be
used to establish client membership in a private virtual network.
6.3.2 Operation
The DHCP server can be optionally configured to allocate IP addresses out
of a pool that is specified by an IP base address and the number of addresses
in the pool. If no pool is specified, the server will use static client entries in the
configuration system to resolve client address requests.
The sever will respond to DHCP requests from a single Ethernet device. This
allows for isolation of clients for a given interface, and allows multiple instances
of the DHCP server to manage different IP address pools for different inter-
faces.
6.3.3 DHCP Server Parameter Structure

The following structure defines the unique parameters of the DHCP server ser-
vice. It is located in the file: src\nettools\inc\dhcpsif.h.
//
// DHCPS Parameter Structure
//
typedef struct _ntparam_dhcps {
uint Flags; // DHCPS Execution Control Flags
IPN PoolBase; // First IP address in optional pool
uint PoolCount; // Number of addresses in optional pool
} NTPARAM_DHCPS;
- Flags – Execution control flags. Can be any combination of the following:
J DHCPS_FLG_LOCALDNS – Causes DHCPS to report its own IP ad-

dress as the local DNS server to clients. If this flag is not set, DHCPS
reports the DNS servers as contained in the “SYSINFO” portion of the
configuration.
J DHCPS_FLG_LOCALDOMAIN – Causes DHCPS to report the local
domain name assigned to the virtual network to clients. If this flag is
not set, DHCPS reports the public domain name to clients.
- PoolBase – The first IP address (in network format) of the address pool
6-8
DHCP Server Service
- PoolCount – The number of addresses in the address pool.
rectly.

Since the DHCP server service executes on a specific interface, it is never
executed based on an IP address. Thus, it can not be used with the
“CALLBYIP” flag in the standard configuration service structure. However,
since an IP host address is required to initialize the service on a specific
interface, the “RESOLVEIP” flag should be set in cases where the IP address
is not pre-assigned.
For example, the following code specifies that the DHCP server should run on
the interface specified by the physical index dhcpsIdx. Here, our home net-
works have already been written to the configuration, so the “RESOLVEIP” flag
is not necessary. The address pool we’re using is already stored in IPPoolBase
and PoolSize. We also request that DHCPS should report the local server ad-
dress as a DNS server to DHCP clients.
dhcp_server_example()
{
CI_SERVICE_DHCPS dhcps;
bzero( &dhcps, sizeof(dhcps) );
dhcps.cisargs.Mode = CIS_FLG_IFIDXVALID;
dhcps.cisargs.IfIdx = dhcpsIdx;
dhcps.cisargs.pCbSrv = &ServiceReport;
// Report our address as a DNS server to clients, and use the
// network’s local domain name.
dhcps.param.Flags = DHCPS_FLG_LOCALDNS | DHCPS_FLG_LOCALDOMAIN;
// Assign the IP address pool
dhcps.param.PoolBase = IPPoolBase;
dhcps.param.PoolCount = PoolSize;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPSERVER, 0,
sizeof(dhcps), (UINT8 *)&dhcps, 0 );
}

be used.

DHCP Server Service
DHCPSOpen Open a DHCP Server
Syntax HANDLE DHCPSOpen( NTARGS *pNTA, NTPARAM_DHCPS *pNTP );

pNTP Pointer to DHCP server parameter structure
Return Value Returns a HANDLE to a DHCPS instance structure which is used in calls to
other DHCPS functions like DHCPSClose().
Description This function is called to initiate DHCPS control of an IP address pool on a giv-
en interface. The base address of the address pool does not have to be the
first IP address in the subnet.
The DHCP Server executes on a specific interface. Thus, it is compatible

with NT_MODE_IFIDX only.
DHCPSClose Closes an Instance of the DHCP Server
Syntax void DHCPSClose( HANDLE hDHCPS );
Parameter(s) hDHCPS Handle to a DHCP server instance obtained from DHCPSO-

pen()
Description This function is called to terminate DHCPS control of the previously supplied
interface. This call also destroys the supplied DHCP server instance handle
hDHCPS.
6-10
DHCP Client Support
6.4 DHCP Client Support
6.4.1 Synopsis
At system startup the DHCP client will try and acquire an IP address from the
DHCP servers available on the network.
Note that the client will accept the first IP address offered and that the INIT-RE-
BOOT State (which requests a previously assigned IP address) is not currently
implemented.
More information on DHCP can be found in rfc2131 and rfc2132.
6.4.2 Operation
The DHCP client is a special service in that it always executes immediately in
a system. If is usually after DHCP client obtains a public IP address that most
of the other services in the system can initialize.
The DHCP client code makes additional use of the service status report call-
back function than most of the other services. Recall from the beginning of this
section that the least significant byte of the report code is reserved for service
specific information.
The following report codes are returned in the LSB of the report code sent by
the DHCP service:
DHCPCODE_IPADD An IP client address had been added to
the system
DHCPCODE_IPREMOVE An IP client address has been removed
from the system
DHCPCODE_IPRENEW An IP client address has been renewed
Note that in each of the above cases, the DHCP portion of the system
information configuration (the first 256 entries of CFGTAG_SYSINFO) has
been erased and potentially reprogrammed. If an application needs to share
the DHCP portion of the system information configuration, these DHCP report
codes can be used to signal when to add additional application specific tags.
For more information on DHCP and the CFGTAG_SYSINFO tag, see
section 4.4.8.
Note: The DHCP client will never erase nor attempt to modify the value of the
DHCP tag, CFGITEM_DHCP_HOSTNAME. As an exception to the behavior
stated above, the system hostname is treated as read-only, and can only be
set by the application programmer.

DHCP Client Support
6.4.3 DHCP Client Parameter Structure

The following structure defines the unique parameters of the DHCP client ser-
vice. It is located in the file: inc\nettools\inc\dhcpif.h.
//
// DCHP Parameter Structure
//
#define DHCP_MAX_OPTIONS 64 // Max number allowed options
typedef struct _ntparam_dhcp {
UINT8 *pOptions; // options to request
int len; // length of options list
} NTPARAM_DHCP;
- pOptions – Pointer to additional DHCP option tags to request. The list is

used when additional information must be obtained from the DHCP server.
Up to DHCP_MAX_OPTIONS tags can be specified. This pointer can be
NULL when len is set to 0.
- len – Specifies the length in bytes of the list pointed to by pOptions.
rectly.

Since the DHCP client service executes on a specific interface, it is never exe-
cuted based on an IP address. Thus, it cannot be used with the “CALLBYIP”
flag in the standard configuration service structure. Also, since the service
runs without an IP host address the “RESOLVEIP” flag should never be set.
For example, the following code specifies that the DHCP client should run on
the interface specified by the physical index dhcpIdx.
dhcp_client_example()
{
CI_SERVICE_DHCPC dhcpc;
bzero( &dhcpc, sizeof(dhcpc) );

dhcpc.cisargs.Mode = CIS_FLG_IFIDXVALID;
dhcpc.cisargs.IfIdx = dhcpIdx;
dhcpc.cisargs.pCbSrv = &ServiceReport;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPCLIENT, 0,
sizeof(dhcpc), (UINT8 *)&dhcpc, 0 );
}
6-12
DHCP Client Support

be used.
DHCPOpen Open a DHCP Server
Syntax HANDLE DHCPOpen( NTARGS *pNTA , NTPARAM_DHCP *pNTP );

Parameter(s) pNTA Pointer to common argument structure used by all services.
pNTP Pointer to DHCP client parameter structure.
Return Value Returns a HANDLE to a DHCP instance structure which is used in calls to other
DHCP functions like DHCPClose().
Description This function is called to initiate DHCP control of a given device.
DHCPOpen() starts the DHCP process. This process will discover if there are
any DHCP servers on the network and request an IP address. The result of
the search for an IP address will be passed to the application via the standard
network tools status callback.
The Client will remain running so it can renew the IP address when necessary.
For any addition option tags entered into the DHCP client parameter structure,
the resulting information from the DHCP server is written to the system config-
uration under the CFGTAG_SYSINFO entry. See section 4.4.8 for more infor-
mation.
The DHCP Client executes on a specific interface. Thus, it is compatible with
NT_MODE_IFIDX only.
DHCPClose Closes an Instance of the DHCP Client
Syntax void DHCPClose( HANDLE hDHCP );

Parameter(s) hDHCP Handle to a DHCP client instance obtained from
DHCPOpen()
Description This function is called to terminate DHCP control of the previously supplied in-
terface and frees the supplied DHCP server instance handle hDHCP.
Note this function will also remove any IP address it has added to the system.
In the case of a service shutdown there will be no status callback indicating the
address removal.

HTTP Server Support
6.5 HTTP Server Support
6.5.1 Synopsis
An HTTP (Hypertext Transfer Protocol) server allows a remote browser to view
content on the server file system. Files can be stored for viewing and forms can
also be stored to allow remote interaction with the system. Form POST func-
tions become calls to application defined C functions that allow the embedded
system to be remotely controlled via a HTTP browser.
6.5.2 Operation
The HTTP Server service provides a mechanism for serving HTTP content to
remote HTTP client applications. It uses the “embedded file system” contained
in the OS adaptation layer. These functions in the EFS programming API in-
clude a prefix of “efs_”. Modifying the EFS functions in the OS adaptation layer
allows the system programmer to support a variety of file storage options, in-
cluding memory, flash cards and hard drives.
6.5.3 Using the HTTP Server and Adding WEB Content

This section includes information on how to invoke and monitor the status of
the HTTP server. WEB application developers will be more interested in how
to add WEB content including HTML pages and CGI functions. These topics
are discussed in a special appendix to this document.
6.5.4 HTTP Server Parameter Structure

The HTTP server service does not require a parameter structure.

The service can be specified as public in that it can connect using any IP
address, or an IP address of a specific interface. When accepting connections
to occur. Since an IP address is required to initialize the service, the
“RESOLVEIP” flag should also be set in the latter case.
For example, the following code specifies that the HTTP server should run us-
ing the IP address INADDR_ANY.
6-14
HTTP Server Support
http_example()
{
CI_SERVICE_HTTP http;
bzero( &http, sizeof(http) );
http.cisargs.IPAddr = INADDR_ANY;
http.cisargs.pCbSrv = &ServiceReport;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_HTTP, 0,
sizeof(http), (UINT8 *)&http, 0 );
}

be used.
HTTPOpen Start the HTTP Server
Syntax HANDLE HTTPOpen( NTARGS *pNTA );
Return Value Returns a handle to the HTTP Server instance, or NULL if the HTTP Server
task could not be created. This handle is used with HTTPClose() to shutdown
the client when its no longer needed.
Description HTTPOpen() starts the HTTP server process. This process will create a con-
nection to the HTTP Port and listen. When a connection is made, another task
will be created to service the request.
HTTPClose Destroy an Instance of the HTTP Server
Syntax void HTTPClose( HANDLE hHTTP );
Parameter(s) hHTTP Handle to a HTTP server instance obtained from

HTTPOpen()
Description Destroys the instance of the HTTP Server indicated by the supplied handle.
Once called, the Server is shutdown.

DNS Server Service
6.6 DNS Server Service
6.6.1 Synopsis
The DNS server service allows clients on a home network to resolve host
names and addresses for clients on both the home and public networks.
6.6.2 Operation
The TCP/IP stack contains a small DNS resolver which can resolve host-
names and addresses that are local to the system via the configuration, or
those outside the system by using an external DNS server.
The DNS server service described here allows the same internal DNS resolver
to be accessed by clients on a virtual (home) network. This allows clients on
a home network to lookup peers on the home network using the same DNS
server that is used for external lookups. Thus, DNS service for the home net-
work is transparent to these clients.
Since the DNS server service uses the same internal DNS resolver as the cli-
ent services discussed earlier, the server adds very little overhead to the sys-
tem.
6.6.3 DNS Server Parameter Structure

The DNS server service does not require a parameter structure.

The service can be specified as public in that it can connect using any IP ad-
dress, or an IP address of a specific interface. When accepting connections
to occur. Since an IP address is required to initialize the service, the “RESOL-
VEIP” flag should also be set in the latter case.
For example, the following code specifies that the server should run using the
IP address INADDR_ANY.
6-16
DNS Server Service
dns_server_example()
{
CI_SERVICE_DNSSERVER dnss;
bzero( &dnss, sizeof(dnss) );
dnss.cisargs.IPAddr = INADDR_ANY;
dnss.cisargs.pCbSrv = &ServiceReport;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_DNSSERVER, 0,
sizeof(dnss), (UINT8 *)&dnss, 0 );
}

be used.
DNSServerOpen Create an Instance of the DNS Server
Syntax HANDLE DNSServerOpen( NTARGS *pNTA );
Return Value Returns a handle to the new server instance, or NULL if the service could not
be created. This handle is used with DNSServerClose() to shutdown the serv-
er when its no longer needed.
Description Creates a DNS server task which can service external DNS requests using
UDP.
DNSServerClose Destroy an Instance of the DNS Server
Syntax void DNSServerClose( HANDLE hDNSS );
Parameter(s) hDNSS Handle to DNS server instance obtained from DNSServerO-

pen()
Description Destroys the instance of the DNS server indicated by the supplied handle.
Once called, the server is shutdown. It waits for all spawned sessions to com-
plete.

Network Address Translation (NAT) Service
6.7 Network Address Translation (NAT) Service
6.7.1 Synopsis
The NAT service allows for the establishment of a home virtual network that
is isolated from and protected from the external public network. It provides a
port based address translation function that allows all the clients on the home
network to share a single public IP address. Thus, multiple clients can share
the same ISP account.
6.7.2 Operation
The TCP/IP stack contains both a network address translation module as well
as an IP filtering model. When the translation service is enabled, any packet
received from a client on a virtual network that is destined for the external pub-
lic network is adjusted to use the stack’s public IP client address.
The translation is performed by allocating a translation record and holding it

for a period of time. The translation records are timed out based on their proto-
col. In TCP, records are timed out based on the state of their TCP connection.
UDP and ICMP translations timeout based on when they were last used.
In addition to translation, the stack contains an additional IP filter option (al-

ways enabled by this service) that filters packets from the public network from
being seen by the private network. For example, if someone on a public net-
work knew the IP address and the subnet mask of the router’s (stack in route
mode) private network, it could set a gateway route to the router’s public IP
host address and the router would route packets from the public to the private
network and back (internally its does not distinguish between public and pri-
vate while routing). The IP filter prevents this. It also prevents an entity on a
public network from accessing protocol servers (like HTTP or Telnet) that are
running on the private network. This allows the router to present different
HTTP or Telnet interfaces to the public than it does to clients in the home.
The NAT service is executed on the public interface – i.e., the interface which
is assigned valid public IP host address (used to carry traffic for the virtual cli-
ent addresses). There can only be one instance and Thus, only one public IP
address, but the service will can serve multiple the virtual (home) networks in
the system so long as they can be combined and still exclude the public IP. If
the combination of these networks results in an overlap with the public net-
work, the service fails.
For example, assume interface “If–1” is connected to the physical network

128.32.12.x/255.255.255.0, and there are two home networks
6-18
(192.168.0.x/255.255.255.0) on “If–2” and (192.168.1 .x/255.255.255.0) on

“If–3”. In order to run NAT on both home networks, the NAT interface would be
“If–1” (the public interface), and the NAT group (virtual) network would be
192.168.0.0/255.255.254.0, which covers both home networks.
For more information on NAT operation, including how to program proxy filters,
see the Network Address Translation appendix at the end of this document.
6.7.3 NAT Server Parameter Structure

The following structure defines the unique parameters of the DHCP server ser-
vice. It is located in the file: src\nettools\inc\dhcpsif.h.
//
// NAT Parameter Structure
//
typedef struct _ntparam_nat {
IPN IPVirt; // Virtual IP address
IPN IPMask; // Mask of virtual subnet
} NTPARAM_NAT;
- IPVirt – NAT Group virtual network address
- IPMask – Subnet mask of NAT Group virtual network
rectly.

Since the NAT service executes on a specified public interface, it is never exe-
cuted based on an IP address. Thus, it can not be used with the ”CALLBYIP”
flag in the standard configuration service structure. In addition, since the public
IP host address is required to initialize the service, the “RESOLVEIP” flag
should be set in cases where the IP address is not pre-assigned.
For example, the following code specifies that the NAT service should run on
the interface specficied by the physical index natIdx. Here, we use the DHCP
client service to obtain our public IP address (the address assigned to natIdx),
so at this point we don’t know what our IP address is going to be. We thus set
the “RESOLVEIP” flag in the execution mode parameter. This informs the con-
figuration service manager not to invoke NAT until it has resolved an IP ad-
dress for the target interface. We also set the “RESTART” flag to tell the service
to restart NAT if we lose and then regain a public IP address. In this example,
we assume all networks in the 192.168.x.x/255.255.0.0 subnet are part of the
NAT group to be translated.

nat_service_example()
{
CI_SERVICE_NAT nat;
bzero( &nat, sizeof(nat) );
// Don’t start NAT until we resolve an IP address on its IF
nat.cisargs.Mode = CIS_FLG_IFIDXVALID |
CIS_FLG_RESOLVEIP | CIS_FLG_RESTARTIPTERM;
nat.cisargs.IfIdx = natIdx;
nat.cisargs.pCbSrv = &ServiceReport;
// Include all 192.168.x.x addresses in NAT group
nat.param.IPVirt = htonl(0xc0a80000);
nat.param.IPMask = htonl(0xffff0000);
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_NAT, 0,
sizeof(nat), (UINT8 *)&nat, 0 );
}

be used.
NATOpen Enable the NAT Service
Syntax HANDLE NATOpen( NTARGS *pNTA, NTPARAM_NAT *pNTP );

pNTP Pointer to NAT parameter structure
Return Value Returns a handle to the NAT instance (1), or NULL if the service could not be
created. This handle is used with NATClose() to disable the service when its
no longer needed.
Description Enables the Network Address Translation Service. Although the function re-
turns a handle for compatibility with the standard NETTOOLS API, only one
instance of the NAT service is allowed.
This service utilizes the virtual and external network information using the con-
figuration system. If the configuration system was not used to create the net-
work records, this function will fail.
The NAT service executes on a specific public interface. Thus, it is compat-
ible with NT_MODE_IFIDX only.
6-20
NATClose Disable the NAT Service
Syntax void NATClose( HANDLE hNAT );
Parameter(s) hNAT Handle to NAT service obtained from NATOpen()
Description Disables the NAT service.

Appendix
AppendixAA
Internal Stack Functions
In the source code to the network control functions there are several calls to
internal stack functions. This is similar to calling the kernel in other operating
environments. This section contains a partial list of internal stack functions
provided to aid in the comprehension of kernel oriented calls.
There are two points the reader should keep in mind while browsing this sec-
tion:
1) This section is required only for system programmers who need low level
access to the stack for configuration and monitoring. This API does not
apply to general sockets application programming.
2) In addition to the internal functions described here, there are scheduling
and configurations tools available that make any direct coding to these
functions unnecessary.
Topic Page
A.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
A.2 Stack Executive (Exec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
A.3 Packet (Pkt) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
A.4 Packet Fragment (Frag) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14
A.5 Link Layer Address (LLA) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20
A.6 Link Layer Information (LLI) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22
A.7 Interface (IF) Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24
A.8 Ether Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28
A.9 Binding Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-32
A.10 Timer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34
A.11 Route Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-36
A.12 Route Control Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-46
A.13 Configuring the Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-50
A.14 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-57
A.15 Obtaining Stack Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-59
A-1
Overview
A.1 Overview
The control API is the collection of functions supplied in the stack library. The
entire API is exposed, although the vast majority of functions and objects will
only be used internally to the stack.
A.1.1 Interrupts and Preemption
It should be noted that no part of the stack is interrupt driven. Neither can any
stack function be called at interrupt time. All interrupt processing is performed
in the HAL or OS, and is thus externally-defined code. This allows the system
programmer to develop a HAL/OS architecture that is best suited for a given
operating environment, without affecting the operation of the stack.
The stack may or may not be pre-empted, depending on the operating environ-
ment in use. A non-preemptive architecture is possible since the stack code
does not uses polling loops nor make any blocking type calls, but preemption
is also supported.
A.1.2 Proper Use of the llEnter() and llExit() Functions
The internal stack functions are not designed to be reentrant. This allows the
stack to operate freely without the concept of a “critical section”, which is imple-
mentation dependent. Thus access to stack functions must be strictly con-
trolled. The form of this control is dependant on the system environment, and
is embodied as two low level OS functions; llEnter() and llExit(). These func-
tions are called before and after a section of code where any stack functions
are called. For example:
llEnter();
StackFunction1();
StackFunction2();
llExit();
These functions can be thought of as “entering” and “exiting” kernel mode.
To make normal user functions appear to be re-entrant, some user functions

(like the sockets API) make internal calls to llEnter() and llExit() when calling
into the stack. If an application needs to call both user functions and internal
stack functions, care must be taken so that standard user functions are not be
called between an llEnter() / llExit() pair (this would cause an error if they in turn
called llEnter()). Since applications generally don’t mix kernel type operations
with network sockets programming, this should not be an issue, but it is some-
thing to keep in mind.
A-2
Overview
With a little care, use these functions should be of no concern. The following
are good general guidelines:
- Always call llEnter() before calling a stack function, and llExit() when done
calling stack functions.
- Try and keep all code that requires llEnter() and llExit() in a single module.
They are only required for system maintenance.
- Don’t call a normal user function (like a socket function) between an llEnt-
er() / llExit() pair.
- Never call llEnter() or llExit() from an ISR.
A.1.3 Events
Communicating what action needs to be performed by the stack is done by
sending event messages to the stack. Event messages are tracked by a
scheduling task implemented in the HAL. This task then alerts the stack to new
pending events. There are currently two event types defined:
- LL_EVENT_TIMER – One half second has elapsed since the last TIMER
event.
- LL_EVENT_PACKET – A packet reception has occurred and is ready to

be passed to the stack.
The HAL scheduler uses the stack’s “Exec” API to communicate to the stack.
A.1.4 Objects
Many of the control API functions deal with object handles. These handles are
created by a variety of class functions contained in the stack. When using an
object handle, it is important to realize how the object handle will be treated
by the function being called.
Associated with every object is the concept of who owns it, who is using it, and
who will eventually free it. In general, when an application creates an object,
the app owns it, the app is the only one using it, and the app must eventually
free it. Unfortunately, the matter becomes somewhat confused when object
handles are shared between applications – especially when the scope of the
handle creator may be shorter than the handle itself.
In this system, there are two basic object types:
- Static Objects – The static object is one that is created by a designated

task, and destroyed by that task or a task where the object has been
passed. In most cases the task that created the object also destroys it.
Internal Stack Functions A-3

Overview
- Referenced Objects – A referenced object is one that may be used by oth-

er tasks long after the original creator is through with it. This type of handle
is useful when an object is needed for a task of indeterminate length,
where the creator of the handle does not wish to track it – or may not be
around to track it.
Under the referenced handle scheme, all tasks that access the object han-
dle make a specific “RefXxx()” call so that references may be tracked.
Whenever a task is finished with the handle, it calls the object’s de-refer-
ence function. The object is not freed until the reference count reaches
ZERO.
A-4
Stack Executive (Exec)
A.2 Stack Executive (Exec)
A.2.1 Synopsis
At the heart of the stack is the Executive API (Exec). The Executive acts as a
message dispatcher for the internal stack components. This action is mostly
hidden from the application, but there are some public functions.
A.2.2 API Functions
ExecOpen Prepare the System for Execution
Syntax void ExecOpen();
Description Prepares the stack for execution by initializing the individual components. Until
ExecOpen() is called, the system can not actually do any work, but after calling
this function, objects like routes and bindings can be created.
ExecClose Shutdown Stack and Cleanup
Syntax void ExecClose();
Description Completes stack execution. This function is called to perform final cleanup on
the system after all user objects (like devices and bindings) have been de-
stroyed.
ExecLowResource Signal Low Resource Condition
Syntax void ExecLowResource();
Description Informs the stack that memory resources are getting dangerously low. As a re-
sult of this call, the stack will abandon certain operations that hold excessive
resources. (Pending ARP packets are thrown away, IP packet fragments
pending reassembly are abandoned, etc.)

Packet (Pkt) Object
A.3 Packet (Pkt) Object
A.3.1 Synopsis
In order to fit nicely into an object oriented environment, network packets are
abstracted into two data objects, packets and packet fragments.
The packet object (PKT) is comprised of information about the packet charac-
teristics, like the ingress and egress device, the route associated with the
packet, the size and state of various protocol headers, etc. The packet frag-
ment object (FRAG) abstracts the actual packet data and information about
data buffer containing the packet.
The figure below illustrates the relationship between packets, fragments, and
the various buffer pools from which fragment data buffers can be allocated.
This section deals with the packet object, and the following section describes
the frag object and buffer pools.
Figure A–1. Packet and Packet Fragment Objects

PACKET OBJECT FRAG OBJECT Buffer Pool
Flags Buffer Pool ID Frag Object Free Buffers

TX / RX Device Buffer
Ether Type Buffer Pointer
L2 Mac Header
Destination Address Buffer Size
Route Valid Size IP Header
Size L2 Mac Header Offset to Valid
Size Protocol Header Transport
Size Transport Header Header
Frag Object Handle Payload
The packet object is the container used for all packet data. The entire Ethernet
packet (MAC header, IP header and Options, Transport header, and payload)
is contained in the packet object. As each successive network layer builds or
decodes that packet, the information contained in the packet object becomes
more and more specific. The packet object flags is the best place to start when
determining packet status.
// Packet Flags
#define FLG_PKT_LLC_VALID 0x0001 // LLC Packet Header is present
#define FLG_PKT_IP_VALID 0x0002 // IP Pkt Header is present
#define FLG_PKT_NET_VALID 0x0004 // Network/Transport Header present
#define FLG_PKT_MACBCAST 0x0008 // Pkt Received as a LL BCast
#define FLG_PKT_MACMCAST 0x0010 // Pkt Received as a LL MCast
When a particular layer header is marked as valid or “present”, it means that
the header is incorporated into the “valid” portion of the packet fragment (see
A-6
Packet (Pkt) Object
the section on the FRAG object). The size of the individual layers can be ob-
tained from the size properties SizeLLCHdr, SizeNetHdr, and SizeTPHdr.
When a packet is created with the generic interface (IF) API (discussed later),
these properties are initialized with the standard header sizes for their respec-
tive types. So even when the headers are not “valid”, an appropriate header
size can usually be found in the header size property. This allows higher level
protocols to leave sufficient room in the packet data area to place the lower
level headers. In the event that a header is larger than the default size, the
packet data will have to be moved.
Building and decoding packet data is discussed further in the following Frag-
ment object section.
A.3.2 Object Type

Static – Packet (PKT) objects are owned and destroyed by a single entity.
Passing a packet handle to a function is considered transfer of ownership.
A.3.3 API Function Overview

The PKT API is extensive, and most programmers will never need to call it, but
as it is so central to the design of the stack, the entire API is presented here
for completeness.
Create/Destroy Functions:
PktNew() Create New Packet Handle
PktFree() Destroy Packet Handle
Get Property Functions:

PktGetEthType() Get the Packet Ethertype
PktGetFlags() Get Packet Flags
PktGetFrag() Attach a Packet Fragment Handle to a Packet
PktGetIFRx() Get the Receive (Ingress) Interface Handle
PktGetIFTx() Get the Transmit (Egress) Interface Handle
PktGetLLADst() Get Destination Link Level Address Handle
PktGetRoute() Get Packet Route
PktGetSizeLLC() Get the Packet Link Layer Control Header Size
PktGetSizeNet() Get the Packet Network Header Size
PktGetSizeTP() Get the Packet Transport Header Size
Set Property Functions:

PktSetEthType() Set the Packet Ethertype
PktSetFlagsClear() Clear Packet Flags
PktSetFlagsSet() Set Packet Flags

Packet (Pkt) Object
PktSetFrag() Attach a Packet Fragment Handle to a Packet

PktSetIFRx() Set Receive (Ingress) Interface Handle
PktSetIFTx() Set Transmit (Egress) Interface Handle
PktSetLLADst() Set Destination Link Level Address Handle
PktSetRoute() Set Packet Route
PktSetSizeLLC() Set the Packet Link Layer Control Header Size
PktSetSizeNet() Set the Packet Network Header Size
PktSetSizeTP() Set the Packet Transport Header Size
A.3.4 API Function Description
PktNew Create New Packet Handle
Syntax HANDLE PktNew();
Return Value Handle to packet or NULL on memory allocation error.
Description This function is called to create a new packet handle. When first created, the
packet is entirely uninitialized.
PktFree Destroy Packet Handle
Syntax void PktFree( HANDLE hPkt );
Description This function is called to destroy a packet. When called, all objects associated
with the packet are dereferenced or destroyed.
PktGetEthType Get the Packet Ethertype
Syntax uint PktGetEthType( HANDLE hPkt );
Return Value Ethertype value or NULL on error.
Description This function is called to get the ethertype for the packet. The ethertype is a
two byte value that is contained in the Ethernet header along with the destina-
tion and source MAC addresses. For a packet being transmitted, this type is
used to construct the Ethernet header. For packets that have been received,
this value contains the ethertype found in the ingress header.
A-8
Packet (Pkt) Object
PktGetFlags Get Packet Flags
Syntax uint PktGetFlags( HANDLE hPkt );

Return Value Packet flags
Description This function is called to get the status flags in the packet object. Flags are
used to mark whether certain network headers are either included or not in-
cluded in the valid data of the packet. For more information, see the synopsis
of this section.
PktGetFrag Attach a Packet Fragment Handle to a Packet
Syntax HANDLE PktGetFrag( HANDLE hPkt );

Return Value Frag handle or NULL on error.
Description This function is called to get the packet fragment (FRAG) object handle associ-
ated with the packet. The FRAG is the object which abstracts the physical
memory buffer containing the packet data. For more information, see the syn-
opsis of this section and that of the following section on the FRAG object.
PktGetIFRx Get the Receive (Ingress) Interface Handle
Syntax HANDLE PktGetIFRx( HANDLE hPkt );

Return Value Handle to Rx device or NULL for local.
Description This function is called to get a handle to the interface which originally received
the packet. The receive handle is set by the Ether object to mark which Ether-
net device originally received the packet. For packets that were generated lo-
cally in the stack, this value is NULL.
PktGetIFTx Get the Transmit (Egress) Interface Handle
Syntax HANDLE PktGetIFTx( HANDLE hPkt );

Return Value Handle to Rx device or NULL for local.
Description This function is called to get a handle to the interface to which this packet is
destined to be sent. In order for a packet to be sent via Ethernet, both the trans-
mit interface and the destination link-layer address (LLA) must be known. As
an alternative, the link-level info (LLI) module can derive these values from a
route handle.

Packet (Pkt) Object
PktGetLLADst Get Destination Link Level Address Handle
Syntax HANDLE PktGetLLADst( HANDLE hPkt );

Return Value Handle to destination LLA (link-level address) or NULL.
Description This function is called to get a handle to the link-level destination address for
the packet. The link-level address is abstracted into an object of type LLA,
which is discussed later in this document. To send a packet to an Ethernet de-
vice, both the destination LLA and transmission interface handle must be set.
PktGetRoute Get Packet Route
Syntax HANDLE PktGetRoute( HANDLE hPkt );

Return Value Handle to packet route or NULL.
Description This function is called to get a handle to the destination route for the packet.
The route can be used by the LLI (link-level info) module to resolve both a
transmission interface and destination link-level address (LLA). If these are al-
ready known, a route is not necessary.
PktGetSizeLLC Get the Packet Link Layer Control Header Size
Syntax uint PktGetSizeLLC( HANDLE hPkt );

Return Value LLC header length or max default if unknown.
Description This function is called to get the length of the link layer control header. For an
Ethernet packet, this value is usually 14 (some devices may imbed additional
tags). For PPP, the value is 2 (contains only the protocol type). The LLC header
size is used for constructing and deconstructing packets in such a manner that
is independent of the physical packet transport mechanism. When building a
packet for an unknown device, the largest value of all device headers is used.
PktGetSizeNet Get the Packet Network Header Size
Syntax uint PktGetSizeNet( HANDLE hPkt );

Return Value IP header length or NULL is unknown.
Description This function is called to get the length of the network header. For an IP packet,
this value is usually 20, but can be larger if IP options are present. The network
header size is used for constructing and deconstructing packets in such a
manner that is independent of the IP header and it options.
A-10
Packet (Pkt) Object
PktGetSizeTP Get the Packet Transport Header Size
Syntax uint PktGetSizeTP( HANDLE hPkt );

Return Value Transport header length or NULL if unknown.
Description This function is called to get the length of the transport header. For a TCP pack-
et, this value is usually 20, but can be larger if options are present. For UDP,
the size is 8. The transport header size is used for constructing and decon-
structing packets in such a manner that is independent of header and it op-
tions.
PktSetEthType Set the Packet Ethertype
Syntax void PktSetEthType( HANDLE hPkt, uint EtherType );

Description This function is called to set the ethertype for the packet. The ethertype is a
two byte value that is contained in the Ethernet header along with the destina-
tion and source MAC addresses. For a packet being transmitted, this type is
used to construct the Ethernet header. For packets that have been received,
this value contains the ethertype found in the ingress header.
PktSetFlagsClear Clear Packet Flags
Syntax void PktSetFlagsClear( HANDLE hPkt, uint Flags );

Description This function is called to clear the indicated flags in the packet object. Flags
are used to mark whether certain network headers are either included or not
included in the valid data of the packet. For more information, see the synopsis
of this section.
PktSetFlagsSet Set Packet Flags
Syntax void PktSetFlagsSet( HANDLE hPkt, uint Flags );

Description This function is called to set the indicated flags in the packet object. Flags are
used to mark whether certain network headers are either included or not in-
cluded in the valid data of the packet. For more information, see the synopsis
of this section.

Packet (Pkt) Object
PktSetFrag Attach a Packet Fragment Handle to a Packet
Syntax void PktSetFrag( HANDLE hPkt, HANDLE hFrag );
Description This function is called to attach a packet fragment (FRAG) handle to a packet.
The FRAG is the object which abstracts the physical memory buffer containing
the packet data. For more information, see the synopsis of this section and that
of the following section on the FRAG object.
PktSetIFRx Set Receive (Ingress) Interface Handle
Syntax void PktSetIFRx( HANDLE hPkt, HANDLE hIF );
Description This function is called to set the ingress or receive interface handle for the
packet. This function is typically called by the Ether object to mark which Ether-
net device originally received the packet. For packets that are generated local-
ly, this value is left NULL.
PktSetIFTx Set Transmit (Egress) Interface Handle
Syntax void PktSetIFTx( HANDLE hPkt, HANDLE hIF );
Description This function is called to set the egress or transmit interface handle for the
packet. In order for a packet to be sent via Ethernet, both the transmit interface
and the destination link-layer address (LLA) must be known. As an alternative,
the link-level info (LLI) module can derive these values from a route handle.
PktSetLLADst Set Destination Link Level Address Handle
Syntax void PktSetLLADst( HANDLE hPkt, HANDLE hLLADst );
Description This function is called to set a link-level destination address for the packet. The
link-level address is abstracted into an object of type LLA, which is discussed
later in this document. To send a packet to an Ethernet device, both the des-
tination LLA and transmission interface handle must be set.
A-12
Packet (Pkt) Object
PktSetRoute Set Packet Route
Syntax void PktSetRoute( HANDLE hPkt, HANDLE hRoute );

Description This function is called to set a destination route for the packet. The route can
be used by the LLI (link-level info) module to resolve both a transmission inter-
face and destination link-level address (LLA). If these are already known, a
route is not necessary.
PktSetSizeLLC Set the Packet Link Layer Control Header Size
Syntax void PktSetSizeLLC( HANDLE hPkt, uint SizeLLCHdr );

Description This function is called to set the length of the link layer control header. For an
Ethernet packet, this value is usually 14 (some devices may imbed additional
tags). For PPP, the value is 2 (contains only the protocol type). The LLC header
size is used for constructing and deconstructing packets in such a manner that
is independent of the physical packet transport mechanism.
PktSetSizeNet Set the Packet Network Header Size
Syntax void PktSetSizeNet( HANDLE hPkt, uint SizeNetHdr );

Description This function is called to set the length of the network header. For an IP packet,
this value is usually 20, but can be larger if IP options are present. The network
header size is used for constructing and deconstructing packets in such a
manner that is independent of the IP header and it options.
PktSetSizeTP Set the Packet Transport Header Size
Syntax void PktSetSizeTP( HANDLE hPkt, uint SizeTPHdr );

Description This function is called to set the length of the transport header. For a TCP pack-
et, this value is usually 20, but can be larger if options are present. For UDP,
the size is 8. The transport header size is used for constructing and decon-
structing packets in such a manner that is independent of header and it op-
tions.

Packet Fragment (Frag) Object
A.4 Packet Fragment (Frag) Object
A.4.1 Synopsis
A Fragment object is a container for packet data. The concept behind the frag
is that a packet data buffer can be represented by the following properties:
- A pool from which the packet buffer was allocated
- A pointer to the packet data buffer
- The size (total byte capacity) of the buffer
- The size (in bytes) of the data which is currently valid in the buffer
- The offset from the start of the buffer to the current valid data
- An “invisible” amount of padding at the end of the buffer (only used when
buffer is allocated)
When a packet buffer is properly created, sufficient room is left at the head of
the buffer to insert network protocol headers. In most cases, only the minimum
header size will be allocated. Applications building packets that will use things
like IP options, must specify the size of the options in advance. When the buffer
is allocated, the offset parameter contains the cumulative size of all the re-
served space. The data payload is copied to this offset.
As network layers are added on the packet, the offset is decreased according
to the size requirements of the packet. A protocol can check to see if its header
has already been incorporated into the packet by checking the packet status
flags (as discussed in the previous section). IP is intended to deviate from strict
layering restrictions such that any code can build any portion of the packet
header it wishes.
The figure below illustrates this concept. The five parameters illustrated (buffer
pointer, buffer size, offset, valid size, and pad) along with the buffer pool indica-
tor make up a FRAG object.
A-14
Figure A–2. FRAG Object Properties

Buffer Pool
Buffer Pointer
Unused
Offset Buffer
Space
Length
Free
Valid Valid
Buffers Data Size
Unused
Space Pad
A.4.2 Object Type
Static – Packet fragment (FRAG) objects are owned and destroyed by a single
entity. Passing a packet handle to a function is considered transfer of owner-
ship.
The following is a complete list of the Frag object API.

FragNewAlloc() Create Frag by Allocating a New Buffer
FragNewWrap() Create Frag by Wrapping an Existing Buffer
FragCopy() Create Frag by Copying an Existing Frag
FragFree() Free a Frag and its Associated Buffer
FragGetAux1() Get Frag Auxiliary Data Value 1
FragGetAux2() Get Frag Auxiliary Data Value 2
FragGetBufParams() Get the Buffer Status Parameters
FragGetNext() Get the Next Frag in a Chain of Frag Objects
FragGetPrev() Get the Previous Frag in a Chain of Frag
Objects
FragSetAux1() Set Frag Auxiliary Data Value 1
FragSetAux2() Set Frag Auxiliary Data Value 2
FragSetBufParams() Set Frag Buffer Status Parameters
FragSetNext() Set the Next Frag in a Chain of Frag Objects
FragSetPrev() Set the Previous Frag in a Chain of Frag
Objects

FragNewAlloc Create Frag by Allocating a New Buffer
Syntax HANDLE FragNewAlloc( uint PoolID, uint BufferLen, uint PadLen,

uint ValidLen, uint DataOffset );
Return Value Handle to new FRAG, or NULL on memory allocation error.
Description This function is called to create a Frag object and allocate a Frag memory buff-
er. The argument PoolID is used to indicate the source of the buffer. The pool
id can be set to one of the following:
- FRAG_POOL_PACKET – Packet allocated from the Ethernet driver in the

HAL
- FRAG_POOL_MEMORY – Packet allocated from stack scratchpad
memory
The BufferLen parameter is the total size of the buffer. PadLen is invisible
space added to the end of the buffer that is used when the buffer is allocated.
The pad value is then discarded.
The parameters ValidLen and DataOffset indicate the portion of the buffer that
has valid data. Obviously a newly allocated buffer can not have valid data, but
these values can be specified if the valid region of the packet is known in ad-
vance (i.e.: to set the amount of reserved space at the head of the buffer).
FragNewWrap Create Frag by Wrapping an Existing Buffer
Syntax HANDLE FragNewWrap( uint PoolID, uint BufferLen, uint ValidLen,

uint DataOffset, UINT8 *pbData );
Description This function is called to create a Frag object to wrap an existing buffer. The
argument PoolID is used to indicate the original source of the buffer.
The BufferLen parameter is the total size of the buffer. The parameters Valid-
Len and DataOffset indicate the portion of the buffer that has valid data.
A-16
FragCopy Create Frag by Copying an Existing Frag
Syntax HANDLE FragCopy( HANDLE hFrag );
Description This function is called to create a Frag object by copying an existing Frag ob-
ject. The buffer pool id of the source Frag is not used to allocate the buffer for
the new Frag. The source of the new buffer is always
FRAG_POOL_MEMORY.
FragFree Free a Frag and its Associated Buffer
Syntax void FragFree( HANDLE hFrag );
Description Called to free a Frag object. The buffer associated with the Frag is also freed.
If one or more Frag objects are chained via the FragSetNext() function, they
are also freed.
FragGetAux1 Get Frag Auxiliary Data Value 1
Syntax UINT32 FragGetAux1( HANDLE hFrag );
Description Called to get auxiliary data associated with the Frag. This is used by TCP and
UDP to track buffer data and should not be used for other purposes.
FragGetAux2 Get Frag Auxiliary Data Value 2
Syntax UINT32 FragGetAux2( HANDLE hFrag );
Description Called to get auxiliary data associated with the Frag. This is used by TCP and

FragGetBufParams Get the Buffer Status Parameters
Syntax UINT8 *FragGetBufParams( HANDLE hFrag, uint *pBufferLen,

uint *pValidLen, uint *pDataOffset );
Return Value Pointer to memory buffer.
Description Called to get information about the buffer associated with the Frag. The func-
tion always returns a pointer to the buffer. The remaining parameters are re-
turned to the supplied pointers when supplied. See the synopsis section for
more detail.
FragGetNext Get the Next Frag in a Chain of Frag Objects
Syntax HANDLE FragGetNext( HANDLE hFrag );
Return Value Handle to next Frag or NULL if none.
Description Called to get a handle to the next Frag object in a chain of Frag objects. Frag
objects are kept in chains in several areas of the stack including IP reassembly,
TCP reassembly, and UDP/RAW socket buffering.
FragGetPrev Get the Previous Frag in a Chain of Frag Objects
Syntax HANDLE FragGetPrev( HANDLE hFrag );
Description Called to get a handle to the previous Frag object in a chain of Frag objects.
Frag objects are kept in chains in several areas of the stack including IP reas-
sembly, TCP reassembly, and UDP/RAW socket buffering.
FragSetAux1 Set Frag Auxiliary Data Value 1
Syntax void FragSetAux1( HANDLE hFrag, UINT32 Data );
Description Called to set auxiliary data associated with the Frag. This is used by TCP and
A-18
FragSetAux2 Set Frag Auxiliary Data Value 2
Syntax void FragSetAux2( HANDLE hFrag, UINT32 Data );
Description Called to set auxiliary data associated with the Frag. This is used by TCP and
FragSetBufParams Set Frag Buffer Status Parameters
Syntax void FragSetBufParams( HANDLE hFrag, uint ValidSize, uint DataOffset );
Description Called to set update the valid size and data offset properties of the data buffer
associated with a Frag. See the synopsis section for more information.
FragSetNext Set the Next Frag in a Chain of Frag Objects
Syntax void FragSetNext( HANDLE hFrag, HANDLE hFragNext );
Description Called to set a handle to the next Frag object in a chain of Frag objects. Frag
objects are kept in chains in several areas of the stack including IP reassembly,
TCP reassembly, and UDP/RAW socket buffering. When the Frag at the head
of a chain is freed, all Frag objects in the chain are freed.
FragSetPrev Set the Previous Frag in a Chain of Frag Objects
Syntax void FragSetPrev( HANDLE hFrag, HANDLE hFragPrev );
Description Called to set a handle to the previous Frag object in a chain of Frag objects.
Frag objects are kept in chains in several areas of the stack including IP reas-
sembly, TCP reassembly, and UDP/RAW socket buffering. When the Frag at
the head of a chain is freed, all Frag objects in the chain are freed.

Link Layer Address (LLA) Object
A.5 Link Layer Address (LLA) Object
A.5.1 Synopsis
In order to make full use of the stack objects described in this section, it is nec-
essary to understand some of the stack’s basic building block components.
One such component is the Link Layer Address Object, or LLA for short.
In essence, and LLA is an abstracted MAC address. It is used in places where
it is more convenient to treat such addresses generically instead of as fixed
length byte arrays.
A.5.2 Object Type

Referenced – LLA objects are referenced and dereferenced as needed. The
object is removed when the reference count reaches ZERO.
A.5.3 API Functions

The following is the complete LLI object API.
LLARef Reference an LLA Object
Syntax void LLARef( HANDLE hLLA );

Description Called to add one to the reference count of an LLA. An application that keeps
an LLA object it did not create itself should reference the route before it uses
it, and dereference it when it is through.
LLADeRef Dereference an LLA Object
Syntax void LLADeRef( HANDLE hLLA );

Description Called to remove one from the reference count of an LLA. An application deref-
erences an LLA when it is through with it. This is the same (to the application)
as destroying the object. The object is actually destroyed when its reference
count reaches zero.
LLANew Create New LLA Object
Syntax HANDLE LLANew();

Return Value Returns a referenced handle to the LLA object, or NULL on a memory alloca-
tion error.
Description Creates a new LLA object.
A-20
Link Layer Address (LLA) Object
LLASet Set LLA Object Properties
Syntax void LLASet( HANDLE hLLA, uint Type, uint Size, UINT8 *pData );
Description This function is called to set the properties of an LLA object. The object type
is the type of address the data represents. Valid values for the Type argument
are:
TYPE_LLA_UNICAST Object is a unicast MAC address
TYPE_LLA_BROADCAST Object is a broadcast MAC address
TYPE_LLA_MULTICAST Object is a multicast MAC address
The Size parameter is the length of the MAC address data (usually 6), and the
address data is pointed to by pData.
LLAGetData Get LLA Object MAC Address Data
Syntax void LLAGetData( HANDLE hLLA, uint Size, UINT8 *pData );
Description This function is called to get the LLA address data from the LLA object. The
number of bytes to copy is supplied in Size. The exact size of the address data
can be found by calling LLAGetLength().
LLAGetType Get LLA Object MAC Address Type
Syntax uint LLAGetType( HANDLE hLLA );
Description This function returns the MAC address type represented by the LLA object.
The return value will be one of the following:
TYPE_LLA_UNICAST Object is a unicast MAC address
TYPE_LLA_BROADCAST Object is a broadcast MAC address
TYPE_LLA_MULTICAST Object is a multicast MAC address
LLAGetLength Get the Length of the LLA Object’s MAC Address Data
Syntax uint LLAGetLength( HANDLE hLLA );
Description This function is returns the byte length of the MAC address data contained in
the object. For LLA objects representing Ethernet MAC addresses, this length
will be 6.

Link Layer Information (LLI) Object
A.6 Link Layer Information (LLI) Object
A.6.1 Synopsis
In order to make full use of the stack objects described in this section, it is nec-
essary to understand some of the stack’s basic building block components.
One such component is the Link Layer Information Object, or LLI for short.
In essence a LLI object is an ARP table entry. This implementation of the IP
stack combines the traditional route table and ARP table into a single table with
a single API. Routes that need use the ARP function include an ARP status
object, called LLI. In fact, the only reason a programmer need know about the
LLI object is to inspect the ARP status of the route table.
A.6.2 Object Type

Static – LLI objects are owned and destroyed by the entity that creates them.
A.6.3 API Functions

The LLI API is larger than that discussed here. It contains functions dealing
with the ARP protocol as well as LLI object member functions. This section the
API functions that are useful to a system application.
LLIGetLLA Get the LLA Associated with this LLI
Syntax HANDLE LLIGetLLA( HANDLE hLLI );

Return Value Handle to LLA or NULL if LLI is invalid.
Description This function is called to return the LLA associated with an LLI. It is used by
a system programmer to obtain the LLA from an LLI contained in a route entry.
LLIValidateRoute Validate an IP Address / MAC Address Pairing in the Route Table
Syntax HANDLE LLIValidateRoute( HANDLE hIF, IPN IPAddr, UINT8 *MacAddr );

Parameter(s) hIF Handle to interface on which the target IP/MAC address
appears
IPAddr IP address to validate
MacAddr Six byte MAC address corresponding to supplied IP address
Return Value Referenced handle to route or NULL if the was no room to create the entry.
Description This function is called to create or update an entry in the stack route table for
the supplied IP address. The entry for the given IP is marked as valid, and as-
signed the supplied MAC address. Packets sent to the IP address will be as-
signed the given MAC address, and no ARP request will be sent.
A-22
Link Layer Information (LLI) Object
This function also updates the route in the LLI (ARP) expiration list. It allows
an application to change the state of the ARP entry even if the stack has al-
ready created the route. It should be used when it is unclear if the route (really
ARP table entry) already exists or not.
Note that this function returns a referenced route handle. This handle must be
dereferenced using the RtDeRef() function when it is no longer required. Since
the route is treated as a standard ARP entry (with a standard expiration time
as supplied in the configuration structure), the route can be dereferenced im-
mediately.

Interface (IF) Object
A.7 Interface (IF) Object
A.7.1 Synopsis
The Interface (or IF) object is an abstraction of any physical interface in the
system capable of transmitting and receiving packet (PKT) objects. In the cur-
rent software, an interface object can represent either a PPP based device or
and Ethernet (Ether) based device. In actuality, there is no interface “object”,
but rather PPP device objects and Ether device objects can both be treated
as IF type objects for a small collection of functions. This section documents
these API functions.
The IF object API covers three general areas. First, is provides a couple of ge-
neric functions to obtain information about a device, like its type, MTU, etc. In
addition, the API is also charged with tracking physical device indices for de-
vice handles, and mapping from one to the other. This is useful for the applica-
tion programming environment and configuration system, which deals in de-
vice indices instead of device handles. The last function of the IF API is to pro-
vide a generic way of creating packets for the system, keeping track of all de-
vice’s header and padding requirements.
A.7.2 Object Type

Static – IF objects represent PPP or Ether objects, which are created and de-
stroyed by the same entity.

The following is a complete list of the IF object API. Some of these functions
are only called from physical device objects like Ether or PPP.
IFInit() Initialize Handle to Index Mapping Tables
IFIndexNew() Allocate a New Physical Index for a Device
Handle
IFIndexFree() Free a Previously Allocated Physical Index
IFMaxIndex() Get the Highest Device Index Currently in Use
IFIndexGetHandle() Get the Device Handle Corresponding to a
Physical Index
IFGetIndex() Get a Physical Index Corresponding to a
Device Handle
IFGetType() Get the Interface Handle Type
IFGetMTU() Get the MTU of a Device
IFSetPad() Set Device Header and Padding
Requirements
IFCreatePacket() Create a Packet Object for Transmission
A-24
IFInit Initialize Handle to Index Mapping Tables
Syntax void IFInit();
Description This function is called from ExecOpen(), before any physical devices are ini-
tialized. It will prepare the IF system to correctly process IFIndexNew() com-
mands which are called when Ether and PPP devices are created.
IFIndexNew Allocate a New Physical Index for a Device Handle
Syntax uint IFIndexNew( HANDLE hIF, uint Index );
Return Value Allocated device index, or NULL on error.
Description This function is called from PPP and Ether when new physical device handles
are created. IF allocates and returns a physical index for the supplied device
handle. If a specific index is required, it is passed in the Index parameter, else
Index is set to NULL.
IFIndexFree Free a Previously Allocated Physical Index
Syntax void IFIndexFree( uint Index );
Description This function is called from PPP and Ether when physical device handles are
destroyed. IF frees the supplied physical index, and can reallocate it in future
calls to IFIndexNew(). The index should not be used once freed.
IFMaxIndex Get the Highest Device Index Currently in Use
Syntax uint IFMaxIndex();
Return Value Max logic device index currently in use.
Description This function returns the highest device index that is currently in use in the sys-
tem. When there are no “holes” in the index map, this value is also the number
of devices currently active.

IFIndexGetHandle Get the Device Handle Corresponding to a Physical Index

Syntax HANDLE IFIndexGetHandle( uint Index );
Return Value Handle to device corresponding to supplied index, or NULL on error.
Description This function is called to convert a physical device index to a device handle.
IFGetIndex Get the Physical Index Corresponding to a Device Handle
Syntax uint IFGetIndex( HANDLE hIF );

Return Value Physical device index corresponding to supplied device handle, or NULL on
error.
Description This function is called to convert a device handle to a physical device index.
IFGetType Get the Interface Handle Type
Syntax uint IFGetType( HANDLE hIF );

Return Value Handle type of supplied handle.
Description This function is called to get the handle type of the supplied device handle.
When called correctly, the return value should be one of the following:
HTYPE_ETH Ether Device
HTYPE_PPP PPP Device
IFGetMTU Get the MTU of a Device
Syntax uint IFGetMTU( HANDLE hIF );

Return Value MTU of the device indicated by the supplied handle.
Description This function is called to get the MTU (maximum transmit unit) size of the indi-
cated device. The MTU value does not include the device’s layer 2 header.
Thus for Ethernet and serial PPP, the MTU will normally be 1500, however for
protocols like PPPoE, the MTU will be smaller.
IFSetPad Set Device Header and Padding Requirements
Syntax void IFSetPad( uint Header, uint Padding );

Description This function is called by a physical device object to set the layer 2 header and
padding requirements for a packet. For example, with Ethernet the header is
normally 14. Plus, if the Ethernet checksum appears in the packet body, the
value of padding is 4.
A-26
IFCreatePacket Create a Packet Object for Transmission
Syntax HANDLE IFCreatePacket( uint SizePayload, uint SizeNet, uint SizeTP );
Return Value Handle to new packet or NULL on allocation error.
Description This function is probably the most useful of the IF functions. It is called to create
a packet object to send packets out of the stack. It uses information collected
from the physical devices to create a packet that can be transmitted on any of
the physical devices in the system. It does this by applying worst case header
and padding sizes. A packet Frag object is also created and attached to the
packet.
The value of SizePayload is the size of the packet without the layer 2 header.
The value of SizeNet and SizeTP is the size of the network header and trans-
port to be associated with the packet (see the section of the Packet object for
more information). These latter two parameters are informational only, and
can be NULL. They don’t affect the size of the buffer (they are included in the
SizePayload parameter).

Ether Object
A.8 Ether Object
A.8.1 Synopsis
The Ether object is really just the “generic” portion of the packet driver. It knows
how to process an Ethernet MAC header, and handles incoming and outgoing
packets. It interfaces directly to the HAL packet driver. For each Ethernet
based packet device in the system, an Ether object is created to represent this
device to the stack.
A.8.2 Object Type

Static – Ether objects are generally created and destroyed by the same entity.

The following is a complete list of the Ether object API.
Create/Destroy Functions:
EtherNew() Create New Ether Object
EtherFree() Destroy Ether Object
EtherConfig() Configure Ether Object Header Parameters
Addressing Functions:
EtherGetLLADirect() Get the directed Link Level Address of the
Ether Object
EtherGetLLABCast() Get the broadcast Link Level Address of the
Ether Object
EtherAddMCast() Add Multicast Ethernet Address
EtherDelMCast() Delete Multicast Ethernet Address
EtherClearMCast() Clear All Multicast Ethernet Addresses
Filtering Functions:
EtherSetPktFilter() Set Receive Packet Filter Value
EtherGetPktFilter() Get Current Receive Packet Filter Value
Hardware Event Functions:

EtherRxPacket() Indicate a New Rx Packet to the Ether Object
A.8.4 API Functions

Although the Ether object API is larger than that discussed here, this section
covers the portion of the API that is useful to a system application.
A-28
Ether Object
EtherNew Create New Ether Object
Syntax HANDLE EtherNew( uint PhysIndex );
Return Value Returns a handle to the Ether object, or NULL on a memory allocation error.
Description Installs a new Ether object in the system. This call should be made for every
ethernet device installed. Once called, the stack will make calls to the HAL
packet driver interface to get more information about the device. The argument
is the physical device id used by the HAL to identify the device.
EtherFree Destroy Ether Object
Syntax void EtherFree( HANDLE hEther );
Description Destroys the indicated Ether object, and frees its associated memory. This
function should be called to remove devices after the stack has shut down.
Calling this function will not result in any calls to the HAL.
EtherConfig Configure Ether Object
Syntax void EtherConfig( HANDLE hEther, uint PhysMTU, uint EthHdrSize, uint
OffDstMac, uint OffSrcMac, uint OffEthType, uint PacketPad );
Description Describes to the Ether object how the Ethernet header is constructed on this
device. Although the MAC address is assumed to be 6 bytes long, various de-
vices have a small variety of packet variances. The Ether device object must
know this information to both process and construct packets in buffers that are
native to the physical device.
The arguments are defined as follows:

PhysMTU Physical MTU of the packet (usually 1514)
EthHdrSize Minimum (non-802.2 SNAP) header size (usually 14)
OffDstMac Byte offset from header start to Dst Mac Addr (usually 0)
OffSrcMax Byte offset from header start to Src Mac Addr (usually 6)
OffEthType Byte offset from header start to ether type (usually 12)
PacketPad Required byte pad at end of frame (usually 0 or 4)

Ether Object
EtherGetLLADirect Get the directed Link Level Address of the Ether Object
Syntax HANDLE EtherGetLLADirect( HANDLE hEther );
Return Value Handle to LLA or NULL on error.
Description Returns an LLA object handle containing the Ethernet MAC address of the
physical device represented by the indicated Ether object. The MAC address
is obtained from the physical interface when the Ether object is first created.
EtherGetLLABCast Get the broadcast Link Level Address of the Ether Object
Syntax HANDLE EtherGetLLABCast( HANDLE hEther );
Return Value Handle to LLA or NULL on error.
Description Returns an LLA object handle containing the Ethernet broadcast address of
the physical device represented by the indicated Ether object. This is normally
a string of 6 (0xFF)s.
EtherAddMCast Add Multicast Ethernet Address
Syntax uint EtherAddMCast( HANDLE hEther, HANDLE hLLAMCast );
Description Called to add an Ethernet multicast address to the list of addresses to be re-
ceived by the Ethernet hardware when the Rx filter is set to
ETH_PKTFLT_MULTICAST. The multicast address is specified as an LLA ob-
ject. The multicast address list can also be manipulated in its raw form at the
llPacket layer (see section D.3).
EtherDelMCast Delete Multicast Ethernet Address
Syntax uint EtherDelMCast( HANDLE hEther, HANDLE hLLAMCast );
Description Called to remove an Ethernet multicast address to the list of multicast address-
es previously added via a call to EtherAddMCast(). The multicast address to
remove is specified as an LLA object. The multicast address list can also be
manipulated in its raw form at the llPacket layer (see section D.3).
A-30
Ether Object
EtherClearMCast Clear All Multicast Ethernet Addresses
Syntax void EtherClearMCast( HANDLE hEther );

Description Called to remove all Ethernet multicast addresses from the list of multicast ad-
dresses previously added via a call to EtherAddMCast(). After calling this
function, the Ethernet adapter will not receive any multicast addresses when
the Rx filter is set to ETH_PKTFLT_MULTICAST or below. The multicast ad-
dress list can also be manipulated in its raw form at the llPacket layer (see sec-
tion D.3).
EtherSetPktFilter Set Receive Packet Filter Value
Syntax void EtherSetPktFilter( HANDLE hEther, uint PktFilter );

Description Called to indicate the level of filtering for Ethernet packets. By default, the driv-
er is opened with filter value: ETH_PKTFLT_MULTICAST. Valid filter values
are as follows:
ETH_PKTFLT_NOTHING No Packets
ETH_PKTFLT_DIRECT Only directed Ethernet
ETH_PKTFLT_BROADCAST Directed plus Ethernet Broadcast
ETH_PKTFLT_MULTICAST Directed, Broadcast, and selected
Ethernet Multicast
ETH_PKTFLT_ALLMULTICAST Directed, Broadcast, and all Multicast
ETH_PKTFLT_ALL All packets
For selecting multicast addresses as the ETH_PKTFLT_MULTICAST level,

see EtherAddMCast().
EtherGetPktFilter Get Current Receive Packet Filter Value
Syntax uint EtherGetPktFilter( HANDLE hEther );

Description Called to retrieve the current level of filtering for Ethernet packets. See the de-
scription of EtherSetPktFilter() for more information.
EtherRxPacket Indicate a New Rx Packet to the Ether Object
Syntax void EtherRxPacket( HANDLE hEther, uint wSize, UINT8 *pb );

Description Called to indicate the reception of a new packet to the corresponding Ether ob-
ject. The Ether object takes ownership of the indicated packet buffer, until it
is returned via a call to llPacketReturnBuffer(), which is discussed in the HAL
section of this document.

Binding Object
A.9 Binding Object
A.9.1 Synopsis
In order for a device object to live on the network, it must have an IP address
and knowledge of its IP subnet. The process of assigning an IP address and
subnet to a device is to create a binding to the device with the desired IP ad-
dressing.
A.9.2 Object Type

Static – Binding objects are generally created and destroyed by the same
entity.
A.9.3 Access Functions

Although the Bind object API is larger than that discussed here, this section
covers the portion of the API that is encountered by a system application.
BindNew Create New IP Binding
Syntax HANDLE BindNew( HANDLE hIF, IPN IPAddr, IPN IPMask );
Return Value Returns a handle to the Bind object, or NULL on error.
Description Binds the indicated IP address and mask to the supplied Ether device. The
handle to the Ether device object is specified as hIF – or an handle to an inter-
face, since the interface may or may not be an Ethernet device (but always is
in this version).
The IP address and mask arguments are given the type IPN which is an un-
signed 32 bit value. “IPN” stands for “IP Network format”, meaning that the IP
data must be supplied in network format. If unsure of the network format for
your hardware, use the htonl() macro function on the ”native” format (where
1.2.3.4 == 0x01020304 ).
BindFree Destroy IP Binding Object
Syntax void BindFree( HANDLE hBind );
Description Destroys the indicated Bind object, and frees its associated memory. This
function removes IP address and subnet association in the system route table.
It has no effect on the Ether object involved in the binding.
A-32
Binding Object
BindGetFirst Start Enumeration of Binding Objects
Syntax HANDLE BindGetFirst();
Description Returns a handle to the first binding installed in the system (or NULL if not bind-
ings exist).
BindGetNext Continue Enumeration of Binding Objects
Syntax HANDLE BindGetNext( HANDLE hBind );
Description Returns a handle to the binding in the installed binding list that follows the indi-
cated binding (or NULL if no more bindings exist). Note that bindings are not
internally kept in chronological order as to how they were installed.
BindGetIF Get the Ether Object that is Bound by this Binding Object
Syntax HANDLE BindGetIF( HANDLE hBind );
Description Returns a handle to the Ether object that is bound by this binding object. Recall
a binding is nothing more than an assignment of an Ether object to an IP ad-
dress/network.
BindGetIP Get the IP Address/Network that is Bound by this Binding Object
Syntax void BindGetIP( HANDLE hBind, IPN *pIPHost, IPN *pIPNet, IPN *pIPMask
);
Description Returns the IP addresses and mask as requested by the calling arguments.
Any of the pointer arguments can be NULL if the information is not required.
The arguments are defined as follows:

pIPHost Pointer to the local IP address assigned by this binding
pIPNet Pointer to the network assigned by this binding (IP
address AND IP Mask)
pIPMask Pointer to the subnet mask of the network assigned by
this binding

Timer Object
A.10 Timer Object
A.10.1 Synopsis
The timer object is used to time events in kernel layer by installing a kernel call-
back function which is called at set intervals. The resolution of the timer is 0.5
seconds, and the callback is not deterministic. The most common use of the
timer callback is to implement timeout conditions that are usually measured
in seconds.
A.10.2 Object Type

Static – Timer objects are generally created and destroyed by the same entity.

Although the Timer object API is a bit larger than that discussed here, this sec-
tion covers the portion of the API that is encountered by an application.
TimerNew Create New Timer Instance
Syntax HANDLE TimerNew( void (*pHandler)(uint), uint HSCount, uint Msg );
Return Value Returns a handle to the Timer instance, or NULL on error.
Description This function creates a new timer instance, with a timeout period in half second
units, specified by HSCount. When the timeout period has elapsed, the call-
back function pointed to by pHandler is called. The parameter to the callback
is a single uint, and the value passed to the callback is that passed in the pa-
rameter Msg.
The timer will continue to call the callback function until the timer handle is de-
stroyed via TimerFree().
TimerFree Destroy Timer Instance
Syntax void TimerFree( HANDLE hTimer );
Description Destroys the indicated timer object, and frees its associated memory. Once
called, the timer will no longer execute the callback function supplied to Timer-
New().
A-34
Timer Object
TimerHSTick Indicate Half Second Tick Event
Syntax void TimerHSTick ();
Description Called by the stack scheduler to notify the stack that a half second has elapsed
since the last call.

Route Object
A.11 Route Object
A.11.1 Synopsis
The route manager maintains IP routing information. It is called by various rou-
tines to get and set route information. A route object is a “destination” on the
network. Locally, it consists of an egress interface and a next hop IP address.
This section describes a subset of the route object. Flags, features, and API
calls have been omitted in an attempt to make this section a little less imposing.
Also, documenting the entire API would require to documentation of other
stack objects that are not covered in this document.
A.11.2 Object Type

Referenced – Route objects are referenced and dereferenced as needed. The
object is removed when the reference count reaches ZERO.
A.11.3 Route Entry Flags Definition

Associated with each route is a collection of entry/status flags. These flags in-
dicate the type of route and its status. Most system programmers will not be
concerned with the route entry flags. They are listed here for completeness.
The definition of the various flags is as follows:
- FLG_RTE_UP – Entry is “up”
When set, indicates that the route is valid. The only time this flag is cleared
is when the route is being initialized, or when an error condition is signaled
via RtSetFailure(). The flag is reset to TRUE by calling RtSetFailure() with
NULL failure code, or if the route is modified.
- FLG_RTE_EXPIRED – Entry is expired
When set, indicates that the route is expired. The flag can not be cleared. A
new route must be created. Expired routes are never “found”, but a route
cached by another entity may expire while it is being held.
- FLG_RTE_STATIC – Entry is static
This flag is set when a route should remain in the routing table even if it has
no references. Various routes can be static. Static routes are manually ref-
erenced by the system during create, and manually de-referenced by the
system during system shutdown.
- FLG_RTE_BLACKHOLE – Entry is a blackhole
When set, indicates that the route is a “black hole”. All packets destined for
this address are silently discarded.
A-36
Route Object
- FLG_RTE_REJECT – Entry is rejecting
When set, indicates that the route is to an invalid address. All packets des-
tined for this address are discarded with an error indication.
- FLG_RTE_MODIFIED – Route has been auto modified
When set, indicates that the route has been modified as a result of an
ICMP redirect message. This can occur only to GATEWAY routes, and
only if ICMP modifications are enabled in the stack configuration.
- FLG_RTE_DYNAMIC – Route has been auto created
When set, indicates that the route has been created as a result of an ICMP
redirect message. ICMP can only create GATEWAY routes, and may do so
only if ICMP modifications are enabled in the stack configuration.
- FLG_RTE_PROXYPUB – Reply to ARP with client’s MAC address
This flag indicates that the router is a proxy publisher of another entity’s
MAC address. When set, the ARP protocol will respond to ARP requests
for the route’s IP address with the supplied static MAC address when the
host is on the same IF device as the incoming ARP request. This allows
support of hosts that do not implement ARP but are on the same physical
Ethernet network (as if this is going to happen). PROXYPUB entries are
always created with an LLA (link-layer address), and contain a static LLI
(link-layer info, i.e., ARP entry). (Note: PROXY and PROXYPUB have
nothing in common other than the word PROXY in their name.)
Note: This flag will be very rarely specified (if at all).
- FLG_RTE_PROXY – Reply to ARP with router’s MAC address
This flag indicates that the router is acting as a proxy for this host or net-
work route. When set, the ARP protocol will respond to ARP requests for
the associated IP host or network when the network appears on a IF de-
vice which is different from that of the incoming ARP request. The MAC
address supplied in the reply is the MAC of the IF device on which the ARP
request was received. A PROXY entry has no LLI (link-layer info, i.e., ARP
entry). This technique is used to “trick” clients into sending packets to the
router when subnets are split across physical devices on a router. (Note:
PROXY and PROXYPUB have nothing in common other than the word
PROXY in their name.)
Note: This flag will be very rarely specified, and is only useful when the
stack is acting as a router. One potential use applies when the stack is act-
ing as a PPP server and a PPP client is made part of the same IP subnet as
an Ethernet based interface. Here, the stack acts as the PPP client’s proxy

Route Object
so that Ethernet peers can communicate via ARP. An alternative would be

to assign an alternate subnet to PPP clients.
- FLG_RTE_CLONING – “Cloning” route to a local IP subnet
When set, indicates that the network route is a cloning route. Cloning
routes clone (spawn to) host routes when a route search is performed on a
host address that is a member of the cloning route’s network (via address
and subnet mask). Cloned host routes take on most of the properties of
their parent network route, with the following alterations:
J Any MODIFIED or DYNAMIC flags are cleared.
J The STATIC flag is never set.
J The HOST flag is set and the netmask is set to 1s.
J The CLONING flag is cleared.
Note: Cloning routes are routes to a “network” (IP and subnet). These
routes are added automatically when an IP network is added to a device
via a Bind object. Take care when adding this type of route manually.
- FLG_RTE_HOST – Host route (no subnet mask)
When set, indicates that the route entry is a host route. A host route has no
subnet mask (or rather a subnet mask of all 1s). When searching for a
route, host routes always match before network routes (but this behavior
can be overridden).
- FLG_RTE_GATEWAY – Destination is available via a Gateway
When set, indicates that the host or network route is indirectly accessible
via an IP gateway. For a route with this flag set, the GateIP address is al-
ways valid. Most GATEWAY routes will also be network routes, however a
host redirect from ICMP can create a host route with a different gateway
than its parent route. When searching for a route, gateway routes always
match before host routes (but this behavior can be overridden).
- FLG_RTE_IFLOCAL – IP address is Local to the stack
When set, indicates that the host route does not have a valid LLI (ARP)
entry because the host is local to the stack. The MAC address of this local
IP host address can be obtained from the interface handle associated with
the route.
Note: Local routes are in the routing table to route packets that originate in
the stack’s upper layers. When handling ARP requests and routing of in-
coming packets from outside the stack, the IP address list published via
the Bind object is used. ARP will not respond to, nor IP accept packets ad-
dressed to an IP address which is not in the Bind list, even if an IFLOCAL
address entry exists in the route table. As with a cloning route, the Bind
object is the best way to create a local route.
A-38
Route Object
A.11.4 Route Entry Flags Guidelines
Without writing another chapter on the theory of routing, here are some gener-
al guidelines to use when creating new routes. Use the definitions listed above
with the following legal flag combinations:
- Setting FLG_RTE_BLACKHOLE
FLG_RTE_REJECT – must be OFF
- Setting FLG_RTE_REJECT
FLG_RTE_BLACKHOLE – must be OFF
- Setting FLG_RTE_CLONING
FLG_RTE_HOST – must be OFF

FLG_RTE_GATEWAY – must be OFF
FLG_RTE_IFLOCAL – must be OFF
- Setting FLG_RTE_HOST
FLG_RTE_CLONING – must be OFF
- Setting FLG_RTE_GATEWAY

FLG_RTE_IFLOCAL – must be OFF
- Setting FLG_RTE_IFLOCAL
FLG_RTE_HOST – must be ON
- Setting FLG_RTE_PROXYPUB
FLG_RTE_HOST – must be ON
- Setting FLG_RTE_PROXY


Route Object
A.11.5 API Functions

The Route API is no doubt the most extensive API that a system task will make
use of outside of the stack routines themselves. As with the other stack APIs
however, it is not the goal of this guide to document the entire API.
Calls that accept a CallFlags argument can be supplied with the

FLG_RTF_REPORT flag to indicate that the call should result in a route report
to the route control object. The route control object is described later in this
section.
RtRef Reference a Route
Syntax void RtRef( HANDLE hRt );
Description Called to add one to the reference count of a route. An application that keeps
a route it did not create itself should reference the route before it uses it, and
dereference it when it is through.
RtDeRef Dereference a Route
Syntax void RtDeRef( HANDLE hRt );
Description Called to remove one from the reference count of a route. An application deref-
erences a route when it is through with it. This is the same (to the application)
as destroying the route. The route is actually destroyed when its reference
count reaches zero.
RtCreate Create New Route
Syntax HANDLE RtCreate( uint CallFlags, uint RtFlags, IPN IPAddr, IPN IPMask,
HANDLE hIF, IPN IPGateway, HANDLE hLLA );
Parameter(s) CallFlags Call Type Flags

RtFlags Route Type Flags
IPAddr Destination IP address of route
IPMask Destination IP Mask of route (or NULL)
hIF Interface (or NULL)
IPGateway Gate IP address (or NULL)
hLLA Static host link-layer address (or NULL)
A-40
Route Object
Call Flags FLG_RTF_REPORT Reports new route (NEW)
Return Value Referenced handle to newly created route.
Description Called to create a new host or network route and add it to the route table. Exist-
ing routes can not be modified via this call.
Some flag combinations make no sense, and the following are strictly en-
forced:
- FLG_RTE_UP flag is always SET.
- FLG_RTE_EXPIRED and FLG_RTE_MODIFIED flags are always

CLEARED.
- If FLG_RTE_HOST is set then the route is a host route and dwIPMask is

ignored, and FLG_RTE_CLONING can not be set.
- If FLG_RTE_GATEWAY is set then IPGateway must specify a valid

(reachable) IP address.
- If FLG_RTE_GATEWAY is not set then hIF must be valid.
- If FLG_RTE_IFLOCAL is set then the specified host address is local to this

machine, and FLG_RTE_HOST must also be set, FLG_RTE_GATEWAY
can not be set, and hIF must be valid.
- If FLG_RTE_CLONING is specified in Flags, the route is a cloning network

route. The IPMask argument must be valid, and neither FLG_RTE_HOST
nor FLG_RTE_GATEWAY may be set.
- If FLG_RTE_STATIC is specified in Flags, the route is referenced once by

the route code, and later dereferenced during shutdown.
RtFind Find a Route
Syntax void RtFind( uint CallFlags, IPN IPAddr );
Call Flags FLG_RTF_REPORT Reports any new (cloned) or unfound route

(NEW or MISS)
Return Value Referenced handle to best match route (or NULL)
Description This call searches the route table for a route that matches the supplied IP ad-
dress. The search always returns the “best” match for a route. The best match
is a match with the most bits in the subnet mask. Thus, a host match takes
priority over a network match.

Route Object
When there is more than one route with the same subnet mask, the following
matching guidelines are used (listed from BEST to WORST):
- Route has a local destination (occurs with host addresses only).
- Route has a gateway destination.
- Route has a subnet destination on a connected interface
Sometimes a search is desired where particular matches are desired. The fol-
lowing flags can be combined with the value of CallFlags to change the behav-
ior of the seach:
FLG_RTF_CLONE Clone a network route to a host route if host not
found
FLG_RTF_HOST Find only non-gateway host routes
RtSetTimeout Set the Timeout for a Non-Static Route
Syntax void RtSetTimeout( HANLE hRt, UINT32 dwTimeOut );

Description This call allows an application to specify that the stack should timeout a refer-
enced route. When the route is added to the timeout list, the system will add
a reference. Thus once the application sets the timeout value, it should call
RtDeRef() to dereference the route. The route will stay valid until the timeout
value is exceeded, after which it is dereferenced by the system. Note that if this
function is called and the route is not dereferenced by the caller, it will still be
removed from the system route table when the expiration time elapses, but the
object will not be freed.
RtSetFailure Set the Timeout for a Non-Static Route
Syntax void RtSetFailure( HANLE hRt, uint CallFlags, uint FailCode );

Call Flags FLG_RTF_REPORT Reports the status change of the route
(UP or DOWN)
Description This call allows an application to specify a particular error with a route, or clear
a previously indicated error. Setting an error clears the FLG_RTE_UP bit in the
flags. When use of the route is attempted, the specified error is returned. De-
fined error codes for the FailCode argument are:
NULL Route is operating normally (sets
FLG_RTE_UP flag)
RTC_HOSTDOWN Host is down
A-42
Route Object
RTC_HOSTUNREACH Host unreachable

RTC_NETUNREACH Network unreachable
RtRemove Remove Route from System Route Table
Syntax void RtRemove( HANLE hRt, uint CallFlags, uint FailCode );

Call Flags FLG_RTF_REPORT Reports the removal of the route (REMOVED)
Description This call allows an application to remove a route from the system route table
independently of any held references to the route. If is similar to the RtSetFai-
lure() call, but differs in two ways:
1) It removes the route from the system route table so that is can no longer
be returned by RtFind().
2) It calls the IP and Sockets layers to flush the route from any local cache.
Calling this function clears the FLG_RTE_UP bit in the flags. When use of the
route is attempted, the error specified in FailCode is returned. Defined error
codes for the FailCode argument are:
RtGetFailure Set the Timeout for a Non-Static Route
Syntax uint RtGetFailure( HANLE hRt );

Return Value Failure code or NULL for normal operation.
Description This call allows an application to retrieve the error code of a route where the
FLG_RTE_UP bit is not set in the route flags. Defined error codes are:
RtGetFlags Get the Route Flags
Syntax uint RtGetFlags( HANLE hRt );

Return Value Route flags
Description This function returns the state of the route flags for the indicated route. The flag
values and definitions were discussed earlier in this section.

Route Object
RtGetIPAddr Get the Route IP Address
Syntax IPN RtGetIPAddr( HANLE hRt );
Return Value IP host/network address.
Description This function returns the specified route’s IP address in network format.
RtGetIPMask Get the Route IP Subnet Mask
Syntax IPN RtGetIPMask( HANLE hRt );
Return Value IP subnet mask
Description This function returns the specified route’s IP subnet mask in network format.
RtGetGateIP Get the Route Gateway IP Address
Syntax IPN RtGetGateIP( HANLE hRt );
Return Value IP address of the Gateway or NULL.
Description This function returns the Gateway IP address for the specified route (assuming
the FLG_RTF_GATEWAY bit is set in the route flags).
RtGetIF Get the Route’s Destination Hardware Interface
Syntax HANDLE RtGetIF( HANLE hRt );
Return Value HANDLE to Ether Object representing target interface.
Description This function returns an Ether device handle to the egress (target) device of
the route. Even local IP addresses have target devices (the device they are
bound to).
RtGetMTU Get the MTU of a Packet Sent via this Route
Syntax uint RtGetMTU( HANLE hRt );
Return Value Packet payload MTU in bytes.
Description This function returns the MTU (not including layer 2 header) of a packet sent
via the supplied route.
A-44
Route Object
RtWalkBegin Start Walking the Route Table
Syntax HANDLE RtWalkBegin();
Return Value HANDLE to first route in system route table or NULL if no routes.
Description This function initiates a walk of the route table. It returns the first route in the
table. The walk must be terminated with RtWalkEnd() for the system to behave
properly.
RtWalkNext Get Next Route While Walking the Route Table
Syntax HANDLE RtWalkNext( HANDLE hRt );
Return Value HANDLE to next route in system route table or NULL if no routes.
Description This function gets the next route (based off the previous route supplied) in a
walk of the route table. The walk must be terminated with RtWalkEnd() for the
system to behave properly.
RtWalkEnd Stop Walking the Route Table
Syntax void RtWalkEnd( HANDLE hRt );
Description This function completes the walk of the route table. The last route (if any) ob-
tained from RtWalkBegin() or RtWalkNext() is specified in the calling argu-
ment. Otherwise, NULL is used.

Route Control Object
A.12 Route Control Object

A.12.1 Synopsis
The route control object isn’t so much of an object as it is a function. Its purpose
is to serve as a collection point for route related information in the system. A
routing daemon may wish to make use of this information, or it could simply
be logged as debugging information.
When so configured, route control messages are transformed into debug mes-
sages by the stack and logged via DbgPrintf(). By default, the route control de-
bug messages are be disabled. Also, the message function can be hooked by
an application.
Note, control messages can also be suppressed individually by not supplying
the FLG_RTF_REPORT flag to the Route object API function when the call is
made (as mentioned in the previous section).
A.12.2 Route Control Messages

The basic form of the route control message is an unsigned int message value,
with two unsigned 32 bit values for additional data. In most cases these are
immediate data. In one instance, the value is actually a 32 bit memory pointer.
Messages are passed internally to the stack via the function:
void RTCReport( uint Msg, UINT32 Param1, UINT32 Param2 );
Applications should not call this function directly.
The possible values for Msg are as follows:
MSG_RTC_UP Route is Valid/Pending

Parameter(s) Param1 = Route IP
Param2 = Route IP Mask (all ones for host route)
Description Called after a “down” message indicating that a route that had previously been
in the down state is now up again. This does not mean that the route has been
validated, but only that it will attempt to validate itself if used.
MSG_RTC_DOWN Route is Down

Description Called when a route goes “down” due to an error. Packets sent via a route in
this state will generate an error. The most common reason for a route to go
down is for a non-response to 5 successive ARP requests. In this case, the
route will come back up after the down time has expired.
A-46
MSG_RTC_MISS Route Find “Missed” on Route

Description Called when the route table was searched for a route and no matching route
was found. This message will never be sent when there is a default route in
the table since all searches will have a match (unless a special restricted
search is performed).
MSG_RTC_NEW New Route has been Entered into the Route Table
Description Called when a new route is created and entered into the route table. Routes
can be created by applications, when new bindings are created, by ICMP redi-
rects, or when local host routes are cloned from local subnet routes.
MSG_RTC_EXPIRED Route has Expired

Description Called when a route with an expiration timeout has expired and been removed
from the table.
MSG_RTC_REMOVED Route has been Manually Removed

Description Called when a route has been manually removed from the table. This message
is not generated when static routes are removed at system shutdown. Gener-
ally, a route can only be removed when its reference count reaches zero. This
can not happen to a static route or a route with an expiration timeout. For the
former, no message is ever generated. For the latter, the MSG_RTC_EX-
PIRED message is used.
MSG_RTC_MODIFIED Route has been Manually Modified

Description Called when a route has been manually modified via the RtModify() call. The
stack does not use this function, so if it is not called by an application, this mes-
sage will never occur.

MSG_RTC_REDIRECT Route has been Redirected

Param2 = New Destination Gateway IP
Description Called when an ICMP redirect message is received for a given IP host ad-
dress. Since the invention of classless subnets, all redirects are treated as
HOST redirects. If the stack is configured to generate redirect routes automati-
cally (will do so by default), this message will occur after the new static host
redirect route has been created (which will also generate a MSG_RTC_NEW
message). If the stack does not create the redirect route, this message occurs
before the socket layer is notified so that if a new route is created as a result
of this message, the sockets layer will find it.
MSG_RTC_DUPIP A Duplicate IP Address has been Detected in the System
Parameter(s) Param1 = Duplicated IP

Param2 = Pointer to 6 byte MAC address of offending device
Description Called when an ARP packet is received from a device that has an IP address
which is the same as the IP address of the stack on that physical interface. De-
pending on the age of the address, the application may wish to destroy the
binding.
RTCAddHook Hook RTC Messages
Syntax uint RTCAddHook ( void (*pfn)( uint, UINT32, UINT32 ) );

Return Value 1 if the hook was installed, or NULL on an error (too many hooks).
Description Called to hook a message function to receive route control messages. The ar-
gument is a pointer to a message function of the type:
void MyMsgFun( uint Msg, UINT32 Param1, UINT32 Param2 );
The function returns 1 if the hook was installed, or NULL if not.
Note that the supplied callback function is called from within an llExit() / llEnt-
er() pair, and thus may call the stack API directly, but may not call any applica-
tions API functions, like sockets functions. If such action is required, the call-
back function may call llExit() when called and then llEnter() before returning.
When the hook is no longer required, the function may be unhooked by calling
RTCRemoveHook().
A-48
RTCRemoveHook Unhook RTC Messages
Syntax void RTCRemoveHook ( void (*pfn)( uint, UINT32, UINT32 ) );
Return Value none
Description Called to remove a previously “hooked” callback function.

Configuring the Stack
A.13 Configuring the Stack
A.13.1 Synopsis
The stack has multiple configuration options that can be changed by the sys-
tem programmer. This is possible by altering the default values in a stack con-
figuration structure before the stack is initialized.
A.13.2 Configuration Structure
The stack internal configuration structure is _ipcfg. Any element in this struc-
ture may be modified before the initial system call to ExecOpen(). This struc-
ture should not be modified after this initial call.
The _ipcfg structure of type IPCONFIG, which is defined as follows:
typedef struct _ipconfig {

uint IcmpDoRedirect; // Update RtTable on ICMP redirect (1=Yes)
uint IcmpTtl; // TTL for ICMP messages RFC1700 says 64
uint IcmpTtlEcho; // TTL for ICMP echo RFC1700 says 64
uint IpIndexStart; // IP Start Index
uint IpForwarding; // IP Forwarding (1 = Enabled)
uint IpNatEnable; // NAT Translation (1 = Enabled)
uint IpReasmMaxTime; // Max reassembly time in seconds
uint IpReasmMaxSize; // Max reassembly packet size
uint RtcEnableDebug; // Enable Route Control Messages (1=On)
uint RtcAdvTime; // Time in sec to send RtAdv (0=don’t)
uint RtcAdvLife; // Litetime of route in RtAdv
int RtcAdvPref; // Preference Level (signed) in RtAdv
uint RtArpDownTime; // Time 5 failed ARPs keep Rt down (sec)
uint RtKeepaliveTime; // VALIDATED route timeout (sec)
uint RtCloneTimeout; // INITIAL route timeout (sec)
uint RtDefaultMTU; // Default MTU for internal routes
uint SockTtlDefault; // Default Packet TTL
uint SockTosDefault; // Default Packet TOS
int SockMaxConnect; // Max Socket Connections
uint SockTimeConnect; // Max time to connect (seconds)
uint SockTimeIo; // Default Socket IO timeout (seconds)
int SockBufMax; // Absolute max Socket buffer size
int SockBufMinTx; // Min Tx space for ”able to write”
int SockBufMinRx; // Min Rx data for ”able to read”
uint PipeTimeIo; // Default Pipe IO timeout (seconds)
int PipeBufSize; // Pipe internal buffer size
int PipeBufMinTx; // Min Tx space for ”able to write”
int PipeBufMinRx; // Min Rx data for ”able to read”
} IPCONFIG;
A-50
The structure entries as defined as follows:
_ipcfg.IcmpDoRedirect Update Route Table on ICMP Redirect
Default Value 1 (Yes)
Description When set, causes ICMP to automatically create a route to perform redirects
on an IP host to the gateway supplied in the redirect message. If set to false
(0), the system programmer can take whatever action they feel necessary as
the ICMP redirect will also generate a route control message.
_ipcfg.IcmpTtl TTL for ICMP Messages
Default Value 64
Description This is the TTL value ICMP will use in messages it generates as a result of rout-
ing IP packets. Legal values are in the range of (1–255).
_ipcfg.IcmpTtlEcho TTL for ICMP ECHO Reply Messages
Default Value 255
Description This is the TTL value ICMP will use in echo reply messages it generates in re-
sponse to receiving echo requests. Legal values are in the range of (1–255).
_ipcfg.IpIndexStart IP Start Index
Default Value 1
Description This is the initial value that is placed in the IP Id field for IP packets generated
by the system. Legal values are in the range of (1–65535).
_ipcfg.IpForwarding IP Forwarding Enable
Default Value 0 (No)
Description When set to true (1), this allows the stack to forward packets it receives for oth-
er IP address to their next hop destination. I.E.: it allows the stack to act as a
router.

_ipcfg.IpNatEnable IP Network Address Translation Enable

Description When set to true (1), this allows the stack to make use of the network address
translation (NAT) module. Note that in addition to setting this structure ele-
ment, NAT must also be configured. This is described more in the following
section.
_ipcfg.IpReasmMaxTime Max IP Packet Reassembly Time in Seconds
Default Value 10
Description This is the maximum time that the stack will hold IP packet fragments while at-
tempting to assemble a complete packet. If the time expires before all the frag-
ments arrive, the packet is discarded.
_ipcfg.IpReasmMaxSize Max IP Packet Reassembly Packet Size in Bytes
Default Value 3020

Description This is the maximum packet size that the stack will attempt to reassemble. As
soon as the stack determines that the total packet size exceeds this value, the
packet is discarded. Making the size larger than 3020 will cause internal
memory errors in the stack as the current memory system has a max block size
of 3068 bytes. Of course the memory allocation support in the HAL can be
changed to support larger allocations (see the HAL section). This value is not
otherwise restricted.
_ipcfg.RtcEnableDebug Enable Route Control Messages

Description Route control messages are used to keep the system informed of route up-
dates. When set to Yes (1), this variable causes RTC to process the route con-
trol message and convert the message into a debug call to llDebugMessage().
Note that an application may also hook into the RTC message loop using the
RTCAddHook () function.
_ipcfg.RtcAdvTime Time in Sec to Send RtAdv

Default Value 0 (Don’t Send Router Advertisements)
Description The stack has the ability to automatically send ICMP router advertisements at
a predetermined interval. Setting this variable to a non-zero value determines
the interval.
A-52
_ipcfg.RtcAdvLife Lifetime of Route in RtAdv
Default Value 120
Description If sending router advertisements (see above), this is the route lifetime that will
be sent in the ICMP message.
_ipcfg.RtcAdvPref Preference Level of Route in RtAdv
Default Value 0
Description If sending router advertisements (see above), this is the route preference level
that will be sent in the ICMP message. This value is signed.
_ipcfg.RtDownTime Time in Seconds a Route is “Down” due to Failed ARP
Default Value 20
Description In order to stop an application from sending endless packets to a route that is
not responding to ARP, the route is brought “down” for a period of time so that
the application will receive an error when IP attempts to send. After the desig-
nated time, the route is brought back up and will attempt more ARP requests
if used again.
_ipcfg.RtKeepAliveTime Time in Seconds a Validated Route is Held
Default Value 1200
Description Routes should not be held indefinitely. Use of a route is also not sufficient to
keep the route alive. This value represents the time an ARP validated route
is held before it expires. If the route is revalidated via ARP during this period,
the period is extended for this interval from that point in time.
_ipcfg.RtCloneTimeout Default Timeout in Seconds of a Cloned Route
Default Value 120
Description When a host route is first cloned from a network route, it is assigned this default
timeout. Once the route is validated via ARP, the timeout is extended (see
above).

_ipcfg.RtDefaultMTU Default MTU for Local Routes
Default Value 1500
Description When a route is created, it gets its MTU from the egress device. However, if
the route is local to the system, there is no egress device. In this case, a default
MTU is used.
_ipcfg.SockTtlDefault Default TTL for Packets Sent via a Socket
Default Value 64
Description This is the default IP packet TTL value of packets sent via a socket. Note that
the application can override this value with the sockets API.
_ipcfg.SockTosDefault Default TOS for Packets Sent via a Socket
Default Value 0
Description This is the default IP packet TOS value of packets sent via a socket. Note that
the application can override this value with the sockets API.
_ipcfg.SockMaxConnect Maximum Connections on a Listening Socket
Default Value 8
Description This is max number of connects a socket will pend waiting for a sockets ac-
cept() call from the application. Note: This value is also the upper bounds of
the ”max connection” argument supplied by an application via the sockets lis-
ten() function (calls with higher values are silently rounded down).
_ipcfg.SockTimeConnect Maximum Time in Seconds to Wait on a Connect
Default Value 80
Description This is max amount to time the sockets layer will wait on an actively connecting
socket. The default value of 80 is a few seconds longer than the TCP keep
time, so TCP will generate the official (more accurate) timeout error.
A-54
_ipcfg.SockTimeIo Maximum Time in Seconds to Wait on Socket Read/Write

Default Value 0
Description This is max amount to time the sockets layer will wait on a read or write opera-
tion without any progress. For example, if the user calls send() with a very large
buffer, the function will not timeout so long as some fraction of the data is sent
during the timeout period. After every successful transfer of data, the timeout
period is reset. A timeout value of ZERO means “never timeout”.
_ipcfg.SockBufMax Maximum Size in Bytes of a TCP/UDP Buffer
Default Value 4096

Description This is the size of the TCP send and receive buffers. UDP and RAW IP buffers
are virtual, but will not allow data to queue above this value. This value can not
be overridden by the sockets option function.
_ipcfg.SockBufMinTx Minimum Size in Bytes for Socket “‘Able to Write”
Default Value 2048

Description This is the size in bytes required to be free in the TCP buffer before it is re-
garded as “able to write” by the system. (Affects how the “write fd set” behaves
in a select() call.) This value is usually about 25% to 50% of the send buffer
size. UDP and RAW IP sockets are always able to write.
_ipcfg.SockBufMinRx Minimum Size in Bytes for Socket “Able to Read”
Default Value 1
Description This is the size in bytes required to be present in a socket buffer to be regarded
as “able to read” by the system. (Affects how the “read fd set” behaves in a se-
lect() call.) Alter at you own risk.
_ipcfg.PipeTimeIo Maximum Time in Seconds to Wait on Pipe Read/Write

Default Value 0
Description This is max amount to time the file layer will wait on a read or write operation
on a pipe without any progress. For example, if the user calls send() with a very
large buffer, the function will not timeout so long as some fraction of the data
is sent during the timeout period. After every successful transfer of data, the
timeout period is reset. A timeout value of ZERO means “never timeout”.

_ipcfg.PipeBufSize Size in Bytes of Each End of a Pipe Buffer
Default Value 1024
Description This is the size of a Pipe send and receive buffer. This value is only examined
when pipes are created, so changing this value will not affect the buffering of
existing pipes.
_ipcfg.PipeBufMinTx Minimum Size in Bytes for Pipe “Able to Write”
Default Value 256
Description This is the size in bytes required to be free in the Pipe buffer before it is re-
garded as “able to write” by the system. (Affects how the “write fd set” behaves
in a select() call.) It is usually about 25% to 50% of the send buffer size. This
value is only examined when pipes are created, so changing this value will not
affect the buffering of existing pipes.
_ipcfg.PipeBufMinRx Minimum Size in Bytes for Pipe “Able to Read”
Default Value 1
Description This is the size in bytes required to be present in the Pipe receive buffer to be
regarded as “able to read” by the system. (Affects how the “read fd set” be-
haves in a select() call.) Alter at you own risk. This value is only examined when
pipes are created, so changing this value will not affect the buffering of existing
pipes.
A-56
Network Address Translation
A.14 Network Address Translation
A.14.1 Synopsis
The stack includes a small network address translation (NAT) function which
can be used to setup virtual networks when the stack it acting as a router.
When enabled, NAT will translate routed packets sent from or to a targeted
virtual network.
A.14.2 Operation
NAT works by altering the TCP/UDP port numbers of a packet sent from a virtu-
al network, and then using an alternate IP on the physical network to transfer
the packet. For ICMP packets, the Id field of ICMP requests is used.
When configured, NAT will have a target virtual network that consists of a IP
base address and a subnet mask. It also has a physical IP address which is
used as a type of proxy for the translated packets.
The types of packets translated include:
- Any TCP or UDP packet
- ICMP EHCO and TSTAMP packets sent from the virtual network
- ICMP EHCOREPLY and TSTAMPREPLY packets sent to the virtual net-

work
- ICMP error packets sent to the virtual network in response to a translated

packet sent from the virtual network.
The translation entries are created dynamically, and have a lifetime based on
their protocol. ICMP and UDP translation entries have a fixed time limit based
off the last time they were accessed. TCP entry expiration is based on the state
of the TCP connection.
Note that some protocols (like FTP) communicate TCP/UDP port information
in the packet payload. These types of protocols will not function under NAT
without a custom proxy program to alter the packet payload. Individual proxies
are not provided.

A.14.3 NAT Configuration

In order to make use of NAT, it must be configured via the function described
here. Also, by default the NAT code is not called by the stack. This is to in-
crease stack efficiency when NAT is not in use. In order to enable the NAT
module, the IpNatEnable element of the stack configuration structure must be
set.
Note that when using the NAT service feature in NETTOOLS or when using
the configuration system, this low-level configuration is not required.
NatSetConfig Configure the Network Address Translation Module
Syntax void NatSetConfig( IPN IPAddr, IPN IPMask, IPN IPServer );
Parameter(s) IPAddr IP address of the Virtual Network

IPMask IP mask of the Virtual Network
IPSever Physical IP address of the server which will host the NAT
translation
Description This function configures NAT with a virtual network and a physical server. Note
that both the virtual and physical addresses must also be contain in the stack’s
route table. NAT should only be used when the stack is acting as a router, and
when there are more than one ethernet devices present.
A-58
Obtaining Stack Statistics
A.15 Obtaining Stack Statistics

Stack statistics are available from global structures or global arrays exported
by the stack library. The declaration of these global identifiers appears in the
interface specification for the individual protocols. The following protocols con-
tain statistics information:
Protocol Statistics Definition

IP IPIF.H
ICMP ICMPIF.H
TCP TCPIF.H
UDP UDPIF.H
Raw Transport (non-TCP/UDP) RAWIF.H
Network Address Translation NATIF.H

Appendix
AppendixBA
This section is required only for system programmers who need low level ac-
cess to the Network Address Translation (NAT) Layer. This API does not ap-
ply to sockets application programming.
This section describes functions that are callable from the kernel layer. Users
should familiarize themselves with the operation of the operation of llEnt-
er()/llExit() functions before attempting to use the APIs described in this sec-
tion.
NAT has a unique status in the stack software in that it can be an integral part
of programming at both the user and kernel levels, or can be entirely redundant
and even purged from the stack build.
This section describes the operation of the Network Address Translation soft-
ware included in the TCP/IP stack, how to configure it, how to install port map-
pings, and how to program proxy filter routines to support protocols like FTP.
Topic Page
B.1 NAT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

B.2 NAT Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
B.3 NAT Proxy Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20
B-1
NAT Operation
B.1 NAT Operation

NAT is basically what the acronym implies – a translation of packet IP address.
It is used by the stack when routing, to translate the IP address of a packet to/
from a private LAN from/to a public WAN. NAT is required when the IP address
paradigms on either side of the router are incompatible, for example, virtual
addresses vs. physical addresses, or private vs. public. In the case of a home
LAN, NAT allows multiple clients on the home LAN to use a single ISP account
by sharing the router WAN IP address obtained from the ISP.
B.1.1 Typical Configuration

For the examples that follow, consider the typical configuration illustrated be-
low. The TCP/IP stack is executing as a home router (HR) and connects the
home LAN subnet (192.168.0.x) to the Internet (WAN) via an ISP which has
assigned HR an address of 128.1.2.12. The hosts on the home network (H1
and H2) have obtained their internet addresses from HR via DHCP. The IP of
HR on the home LAN as well as the IP subnet used by the home LAN is pre-
configured in HR. The illustration also shows a host on the public internet (IH)
to which the LAN hosts will connect. Lastly, we assume the home LAN subnet
is virtual, and NAT is required to allow H1 and H2 to share the WAN IP address
assigned to HR by the ISP (128.1.2.12).
Figure B–1. Basic Home Network Configuration
64.1.1.100 Internet Host

(IH)
Internet
128.1.2.12 Home Router

ISP
(HR)
WAN
using NAT
192.168.0.1
192.168.0.32 192.168.0.33
Home
Host 1 LAN Host 2
(H1) (H2)
192.168.0.x
B-2
NAT Operation
B.1.2 Basic NAT

When sharing a single WAN IP address, the IP address obtained from the ISP
is assigned to the router (the TCP/IP stack in routing mode). Client machines
that are to share the IP address are placed on the home LAN. The router routes
traffic between the LAN and the WAN (internet via the ISP).
As packets traverse from the LAN to the WAN across the router, the source
IP address of the packet (a LAN address) is replaced with the public IP address
of the router. The result is that all packets sent to the WAN appear to have origi-
nated from the router with the public IP address obtained from the ISP.
As packets traverse from the WAN to the LAN across the router, the destination
IP address of the packet (the router’s WAN IP as obtained from the ISP) is re-
placed with the home LAN IP address of the physical client machine to which
the packet is ultimately destined.
In order to perform this translation successfully, some details must be ad-

dressed. First, in order to allow multiple clients to share the public IP address
in a non-ambiguous fashion, there must exist a deterministic method of map-
ping packets from the WAN to their correct destination on the LAN. This is done
be keeping records of LAN IP clients that have initiated IP traffic, and by alter-
ing the TCP/UDP port (or ICMP Id field) as well as the IP address when per-
forming the translation.
Every time a LAN client sends a packet to the WAN, the local IP address, port/
id, and protocol is recorded for reverse mapping, as well as the destination IP
address and port for security. When a packet is received from the WAN, the
destination port/id is checked against the current database of NAT entries to
see if the packet’s destination address and port/id should be translated to a
LAN client.
For example, when accessing the Internet, all communications is normally ini-
tiated by the client. In this case, communications will be initiated by H1 or H2.
Assume that H1 attempts to establish an HTTP connection with the Internet
host (IH). It will send a connection request to the IP address assigned to IH,
and a TCP port value of 80, which is HTTP. The request will be from its own
IP address with an ephemeral port value that is picked from a pool (consider
it random for our purposes – say 1001). So the request will be addressed as
follows:
Packet 1
To From Protocol
64.1.1.100 : 80 192.168.0.32 : 1001 TCP
Network Address Translation B-3

NAT Operation
When the router HR receives this packet, it searches for a NAT entry that
matches the From address of the packet. Since this is the first packet, assume
the table is empty. When no entry is found, (skipping proxies for now) the router
will create a new entry. It does this by recording information from packet 1, as
well as picking a new port value from its own pool that has been specifically
reserved for NAT (assume the range is 50000 to 55000, and that it chooses
50001). The new port is used as the packets source port. The NAT entry record
would look like the following:
NAT Entry Table
Foreign Local Mapped

Foreign IP Port Local IP Port Port IP Protocol TCP State Timeout
64.1.1.100 80 192.168.0.32 1001 50001 TCP SYNSENT 00:01:00
The Local IP and Local Port values are those that are local to hosts on the
home LAN. The Foreign IP value is the foreign side of the connection as
viewed by hosts on the home LAN. The Mapped Port value is the source port
when the packet is sent from HR. The source IP address used in the packet
is that assigned to HR by the ISP. The IP protocol of the packet is recorded,
and when using TCP, the state of the TCP connection is tracked to establish
a reasonable timeout value. The SYNSENT value indicates that a connection
request was sent. Before a full connection is established, the timeout is set fair-
ly low – say 1 minute.
As the packet is transmitted from HR to the ISP, it would look like the following:
Packet 1 (modified)
To From Protocol
64.1.1.100 : 80 128.1.2.12 : 50001 TCP
When IH receives the packet, it believes that the connection request came
from HR. It thus sends the response packet to HR. The packet would be ad-
dressed as follows:
Packet 2 (response to packet 1)
To From Protocol
128.1.2.12 : 50001 64.1.1.100 : 80 TCP
B-4
NAT Operation
When HR receives the packet, it checks the NAT entry table for an entry with
a Mapped Port value equal to the destination port of the packet (in this case
50001). The value of Protocol and the source IP address/port values must also
match the Protocol, Foreign IP, and Foreign Port fields of the NAT entry. This
helps ensure that the reply is from the desired server.
Here, HR finds the entry and proceeds to modify the packet. It replaces the
destination address/port with the “local” address/port stored in the entry. It also
resets the timeout of the entry. After modification, the packet would be ad-
dressed as follows:
Packet 2 (modified)
To From Protocol
192.168.0.32 : 1001 64.1.1.100 : 80 TCP
Once a connection is established, the timeout of the entry is set quite high (say
five hours). This is because TCP connections can stay connected for an indefi-
nite period of time without exchanging any packets.
If H2 attempts to connect to the same host simultaneously, there is no problem
sharing the public IP address assigned to HR. For example, H2 sends a con-
nection request to IH addressed as follows:
Packet 3
To From Protocol
64.1.1.100 : 80 192.168.0.33 : 1024 TCP
HR would not find a NAT entry for 192.168.0.33:1024, so it would create one:
NAT Entry Table

64.1.1.100 80 192.168.0.33 1024 50002 TCP SYNSENT 00:01:00
64.1.1.100 80 192.168.0.32 1001 50001 TCP CONNECT 04:59:23
The modified packet and its reply would proceed similar to packets 1 and 2.
Packets that pass from the LAN to the WAN are searched based on Local IP
combined with Local Port. Packets that pass from the WAN to the LAN are
searched based on Mapped Port. Note that for all entries on the NAT entry
table, these values are unique.

NAT Operation
B.1.3 NAT Port Mapping
So far we’ve only examined communications that has been initiated by hosts
on the home LAN. Note that any unsolicited packets sent to HR from the WAN
will not match any entry in the NAT table. These packets will be forwarded to
the internal protocol stacks on HR, where they may or may not be used.
Now assume that a host on the home LAN (say H2) wishes to place an HTTP
server on the Internet. With what we’ve examined so far, it would be impossible
to contact such a sever from the WAN since no unsolicited traffic (like an HTTP
connect request) can pass from the WAN to the LAN. However, H2 can acquire
a portion of HR’s WAN presence by mapping one of the well-known port values
on the public WAN IP address to itself through port mapping.
In port mapping, a NAT entry is created to send all traffic destined for a specific
port on the public IP address to an alternate destination. For well known ports
like HTTP, the port value is not usually altered. Only the destination IP address
changes. In this case, port 80 (HTTP) on the public IP address is mapped to
port 80 of the LAN host H2. The entry would look as follows:
NAT Entry Table

wild wild 192.168.0.32 80 80 TCP – STATIC
When a connection request arrives from a remote host for the public IP ad-
dress assigned to HR, as with the basic NAT discussion of the previous sec-
tion, the destination port of the packet is matched with the Mapped Port value
of the NAT entry. Normally, the Foreign IP and Port of the NAT entry must also
match for source IP and port of the packet, but here the values are ”wild”. This
is because when the entry is created, the foreign peer is unknown. Since, ev-
ery TCP connection state must be tracked in its own NAT entry, a second entry
must be spawned. Any match of a wild NAT entry will spawn a fully qualified
entry. For example, assume the following packet arrives:
Packet 4
To From Protocol
128.1.2.12 : 80 64.1.1.100 : 2006 TCP
B-6
NAT Operation
The resulting NAT entry table would be:
NAT Entry Table

64.1.1.100 2006 192.168.0.32 80 80 TCP SYNSENT 00:01:00
The packet sent to the LAN by HR would be:
Packet 4 (modified)
To From Protocol
192.168.0.32 : 80 64.1.1.100 : 2006 TCP
Note that the wildcard entry’s timeout is STATIC. This means that the entry will
never expire. Note that when the new entry is spawned, it acquires a timeout.
One last point to note here is that the installation of a port map for port 80 does
not prohibit HR from running its own HTTP server hosted on its private LAN
IP address (192.168.0.1). This means that local hosts could get to a local
HTTP server on 192.168.0.1, and the public HTTP server on 192.168.0.32, but
outside hosts connecting to 128.1.2.12 could only get to the public HTTP serv-
er on 192.168.0.32.
For example, assume the same topology as before, with the HR running both
and HTTP and Telnet servers, H1 running an HTTP server, and H2 running a
Telnet server. This is illustrated below:
Figure B–2. Public Servers on the Home Network
64.1.1.100 Internet Host

(IH)
Internet
128.1.2.12 Home Router HTTP server

ISP
(HR)
WAN Telnet server
using NAT
192.168.0.1
192.168.0.32 192.168.0.33
Home
Host 1 LAN Host 2
(H1) (H2)
192.168.0.x
HTTP Telnet
server server

NAT Operation
In order to make the servers on H1 and H2 public, the following NAT port map-
ping entries are installed on HR:
NAT Entry Table

With these mappings, the externally available HTTP server and Telnet server
publicly accessible on the WAN IP (128.1.2.12) are actually executing on H1
and H2. However HR can have its own HTTP and Telnet servers and make
them available to hosts on the LAN.
Also note that regardless of how hosts on the LAN access HR (either through
192.168.0.1 or 128.1.2.12), their packets are not processed via NAT. Thus
they are never altered. The following are some connection examples:
Client Protocol Used Target Address Resulting Server Connection

IH HTTP 128.1.2.12 HTTP on H1
H2 HTTP 128.1.2.12 HTTP on HR
H2 HTTP 192.168.0.1 HTTP on HR
H2 HTTP 192.168.0.32 HTTP on H1
IH Telnet 128.1.2.12 Telnet on H2
H1 Telnet 128.1.2.12 Telnet on HR
H1 Telnet 192.168.0.1 Telnet on HR
H1 Telnet 192.168.0.33 Telnet on H2
B.1.4 NAT Proxy Filters

B.1.4.1 Problem Synopsis
Translating the IP destination address of a packet via NAT guarantees that all
packets can be redirected to their correct physical destination, but it does not
guarantee that the information will be understood by the recipient. Since one
side of the connection always believes they are actually connected to a differ-
ent IP address than their physical peer, there is a possibility that the application
using the information will become confused. The confusion arises when there
is information in the packet payload that is dependent on the IP address/port
of the peer connection.
B-8
NAT Operation
B.1.4.2 Problem Example – FTP Clients on the LAN

As a straightforward example of a situation that requires a proxy filter, consider
FTP (file transfer protocol). FTP actually uses two ports to transmit a file. The
first port is used to establish the control connection. Then, new ports are used
to establish the data connection to actually send the file. The FTP protocol al-
lows an FTP client to specify its port for the data connection to the server. If
no port is specified by the client, the client’s control port value is used.
The above scenario presents a couple problems for standard NAT. First, if NAT
is used to create an entry for the FTP control connection, the entry could not
be used for the data connection. As an example, say H1 sends an FTP connec-
tion request to IH. The packet would be address something like the following:
Packet 1
To From Protocol
64.1.1.100 : 21 192.168.0.32 : 1137 TCP
HR would not find a NAT entry for 192.168.0.33:1137, so it would create one:
NAT Entry Table

64.1.1.100 21 192.168.0.32 1137 50003 TCP SYNSENT 00:01:00
The modified packet and its reply would proceed as discussed in section B.1.2.
The modified packet would be:
Packet 1 (modified)
To From Protocol
64.1.1.100 : 21 128.1.2.12 : 50003 TCP
Now assume that eventually the FTP server on IH attempts to establish a data
connection back to what it thinks is the FTP client’s ephemeral port (50003).
Note classic FTP uses port 20 to establish data connections. Its connection
request packet would be:
Packet 2 (Data connection request)

To From Protocol
128.1.2.12 : 50003 64.1.1.100 : 20 TCP

NAT Operation
Since there is no NAT entry record that will match the address values in this
packet (specifically port 20 in the From field), this packet will not be forwarded
to the FTP client. In order for this to work, there must be a port mapping
installed for 64.1.1.100 that has a wildcard port value (we can’t be sure that
the connection request will arrive on port 20). The NAT entry table would be
as follows:
NAT Entry Table

64.1.1.100 wild 192.168.0.32 1137 50003 TCP – STATIC
64.1.1.100 21 192.168.0.32 1137 50003 TCP CONNECT 04:58:39
With such a mapping, if a connection request from port 20 arrived, the wild card
entry would be matched, and another entry spawned for port 20 on IH. The
table would look as follows:
NAT Entry Table

64.1.1.100 20 192.168.0.32 1137 50003 TCP SYNSENT 00:01:00
64.1.1.100 wild 192.168.0.32 1137 50003 TCP – STATIC
64.1.1.100 21 192.168.0.32 1137 50003 TCP CONNECT 04:58:39
The second issue in dealing with an FTP client is that the client can change
the port on which the FTP server attempts connection. This is done via a PORT
command sent from the client to the server. The PORT command contains in-
formation about the client in the packet payload.
For example, assume the FTP client (H1) creates a new socket for the data
connection, and its ephemeral port value is 1142. H1 would then send an FTP
PORT command on the control connection to the server. The server would
then attempt a connection. The following is an approximation of the operation
(it is not the exact syntax of the port command).
Packet 3 (FTP Client H1 Sends Port Command for Port 1142)
To From Protocol Packet Payload
64.1.1.100 : 21 192.168.0.32 : 1137 TCP “PORT 192.168.0.32, 1142”
B-10
NAT Operation
As a reminder, the FTP server would normally see the packet as:
Packet 3 (modified incorrectly)

64.1.1.100 : 21 128.1.2.12 : 50003 TCP “PORT 192.168.0.32, 1142”
This packet creates a couple problems. First, the IP address in the PORT com-
mand does not match the IP address of the FTP server’s connected peer. This
would produce an error. Plus, the IP address in the PORT command is not a
real Internet address. Lastly, even if the FTP server tried to connect to
128.1.2.12:1142, there is no mapping for the port number in the NAT entry
table.
The correct procedure for modifying this packet is to solve all the above prob-
lems. First, a new NAT entry is created for 192.168.0.32:1142. The foreign IP
address is left as a wildcard since as before, we don’t know what port the FTP
server will use. The NAT entry table would then look as follows:
NAT Entry Table

64.1.1.100 wild 192.168.0.32 1142 50004 TCP – 00:02:00
64.1.1.100 wild 192.168.0.32 1137 50003 TCP – STATIC
64.1.1.100 21 192.168.0.32 1137 50003 TCP CONNECT 04:58:39
In recap, note that we have the original NAT entry for the FTP control connec-
tion, and now two wildcard entries for possible FTP data connection requests.
The final step of the modification is to alter the payload of the packet so that
the information in the PORT command matches the WAN IP address of HR
(128.1.1.21) and the Mapped Port of the new NAT entry (50004). The correctly
modified packet would be:
Packet 3 (modified correctly)

64.1.1.100 : 21 128.1.2.12 : 50003 TCP “PORT 128.1.2.12, 50004”
It is also possible for a client to request the FTP server to create a new port
(the PASV command), but that does not create any issues for FTP clients on
the LAN. If the FTP server were on the LAN and the client on the WAN, the
proxy process would key off the PASV command.

NAT Operation
B.1.4.3 Stack Support for Proxy Filters
The bad news for the modification procedure discussed above is multifaceted:
1) The creation of the first data connection wildcard entry depends on the
knowledge by some entity that an FTP control connection has occurred,
and what IP/PORT the connection occurred on.
2) The creation of the second data connection wildcard entry depends on the
detection of a PORT command being passed from the client to the server.
3) The modification of the data payload of the packet containing the PORT
command requires that some entity is examining packet payloads.
4) Modification of a TCP packet payload can permanently alter the values of

the TCP sequence and acknowledge fields in the TCP header of all future
packets on the control connection.
The first three problems are very specific to FTP, and the fourth problem (TCP
sequence) is specific to any alteration of a TCP packet payload. The good
news is that the proxy filter support routines remove much of the burden of sup-
porting these transformations.
The solution is twofold. First, the stack allows a programmer to install “proxy
filter” callback functions on specified TCP/UDP port values, either outgoing
(for clients) or incoming (for servers). There are three callback functions in-
volved.
The first callback function “Enable” is called when a new connected is at-
tempted, or when the NAT entry expires. This function allows the programmer
to establish the basic connection state for the protocol in question. In the case
of the FTP client example, the first wildcard data connection mapping would
be installed here. Note that this function can also be used to filter connection
requests. If this function returns zero, the connection request is ignored.
The second and third callback functions are mirrors of the other. They are the
“Tx” and “Rx” functions. The “Tx” callback is called with the IP header of every
packet that passes from the LAN to the WAN for the connection in question,
while the “Rx” callback is called with the IP header of every packet that passes
from the WAN to the LAN. While in these functions, the programmer can call
a “packet modify” function to modify the payload of the packet. The system will
automatically track and perform modifications to the TCP sequence values
(when using TCP).
B-12
NAT Operation
In the case of the FTP client, there would be no “Rx” callback since only pack-
ets from the client need be examined. The “Tx” callback would look for PORT
commands from the client, and when one was detected, it would install the sec-
ond wildcard port mapping as discussed in the previous section, and then
modify the packet payload so that the PORT command reflected the WAN IP
of HR, and the Mapped Port of the NAT entry.
B.1.4.4 FTP Proxy Filter Example Code
From the discussion in this section, it would be easy to draw the conclusion
that developing proxy filter code would be horribly complicated. However, the
actual implementation is straightforward. The code to implement the filter dis-
cussed in section B.1.4.3 is shown below. The API for NAT and Proxy is dis-
cussed in the following sections.
//
// GetVal – Convert ASCII decimal string to integer
//
static uint GetVal( UINT8 **pData )
{
uint v = 0;
while( **pData >= ’0’ && **pData <= ’9’ )
v = v*10 + (*(*pData)++ – ’0’);
(*pData)++;
return(v);
}
//
// FTPCProxyEnable – Proxy for FTP Clients behind firewall
//
// NOTE: Proxy callback function operate at the kernel level. They
// may not make calls to user–level functions.
//
int FTPCProxyEnable( NATINFO *pin, uint Enable )
{
HANDLE hNat;
// Some implementations of FTP require the host to listen for

// connections on the ephemeral port used to connect to the FTP
// server. We create a STATIC mapping to handle this.
if( Enable )
{
// Create it
hNat = NatNew( pNI–>IPLocal, pNI–>PortLocal, pNI–>IPForeign, 0,
IPPROTO_TCP, pNI–>PortMapped, 0 );
pNI–>pUserData = hNat;
}
else
{
// Destroy it

NAT Operation
NatFree( pNI–>pUserData );
}
return(1);
}
//
// FTPCProxyTx – Proxy for FTP Clients behind firewall
//
// NOTE: Proxy callback function operate at the kernel level. They
// may not make calls to user–level functions.
//
int FTPCProxyTx( NATINFO *pNI, IPHDR *pIpHdr )
{
UINT16 Length, Offset;
TCPHDR *pTcpHdr;
UINT8 *pData;
HANDLE hNAT;
NATINFO *pNINew;
char tmpstr[32];
UINT16 PortNew;
IPN IPNew;
pData = (UINT8*)pIpHdr;
// Get pointer to TCP header

Offset = (pIpHdr–>VerLen & 0xf) * 4;
pTcpHdr = (TCPHDR *)(pData + Offset);
// Get length of the IP payload

Length = HNC16(pIpHdr–>TotalLen) – Offset;
// Get the offset into the TCP payload and payload size
Offset += pTcpHdr–>HdrLen >> 2;
Length –= pTcpHdr–>HdrLen >> 2;
// Get pointer to TCP payload

pData += Offset;
//
// For clients, we only care about sending PORT commands
//
// For example, if our client IP is 192.138.139.32, and it reports
// port 384, the form of the command sent to the FTP server would
// be: ”PORT 192,138,139,32,1,128\r\n”
//
// We replace the Client IP with the router’s IP, and the client
// port with a NAT port which is mapped to the client port.
//
if( !strncmp( pData, ”PORT ”, 5 ) )
{
// Get the IP/Port declared by sender
// Form is ”i1,i2,i3,i4,p1,p2”
pData += 5;
IPNew = ((UINT32)GetVal(&pData)) << 24;
B-14
NAT Operation
IPNew |= ((UINT32)GetVal(&pData)) << 16;

IPNew |= ((UINT32)GetVal(&pData)) << 8;
IPNew |= ((UINT32)GetVal(&pData));
IPNew = htonl( IPNew );
PortNew = GetVal(&pData);
PortNew = (PortNew<<8) + GetVal(&pData);
// Add a NAT mapping to client’s IP and Port

hNAT = NatNew( IPNew, PortNew, pNI–>IPForeign, 0, IPPROTO_TCP,
0, NAT_IDLE_SECONDS );
if( !hNAT )
return(0);
// Get Server IP and Mapped Port

IPNew = htonl( NatIpServer );
pNINew = NatGetPNI( hNAT );
PortNew = pNINew–>PortMapped;
// Print a repalcement string with with IP and Port

sprintf( tmpstr, ”%u,%u,%u,%u,%u,%u\r\n”,
((uint)(IPNew >> 24)),
((uint)(IPNew >> 16)&0xFF),
((uint)(IPNew >> 8)&0xFF),
((uint)(IPNew)&0xFF),
PortNew>>8, PortNew&0xFF );
// Replace the original string with ours

ProxyPacketMod( Offset+5, Length–5, strlen(tmpstr), tmpstr );
}
return(1);
}

NAT Port Mapping
B.2 NAT Port Mapping

B.2.1 Synopsis
NAT port mapping allows a client machine on the LAN (or home network) to
appear on a specific port of the router’s public WAN IP address. This API (and
NAT in general) is only used when the TCP/IP stack is acting as an IP router,
and when one the IP network on one side of the router is using virtual IP ad-
dresses.
The functions described in this section illustrates how to install and remove
port mappings. The functional operation of NAT and NAT Port Mapping is dis-
cussed in more detail in section B.2.3.
B.2.2 Function Overview

The following functions are used to create and destroy port mappings:
NatNew() – Create a new NAT entry (for port mapping)
NatFree() – Free a NAT entry
NatGetPNI() – Get a pointer to a NAT entry’s NATINFO structure
B.2.3 NAT Entry Information Structure

A port mapping is in actuality just a NAT entry. Each NAT entry has its own infor-
mation structure. This NATINFO structure allows the programmer to examine
the status of a particular entry.
The specification of the NATINFO structure is as follows:
typedef struct _natinfo {
uint TcpState; // Current TCP State (Simplified)
#define NI_TCP_CLOSED 0 // Closed or closing
#define NI_TCP_SYNSENT 1 // Connecting
#define NI_TCP_ESTAB 2 // Established
IPN IPLocal; // Translated IP Address
UINT16 PortLocal; // Translated TCP/UDP Port
IPN IPForeign; // IP Adress of Foreign Peer
UINT16 PortForeign; // Port of Foreign Peer
UINT8 Protocol; // IP Potocol
UINT16 PortMapped; // Locally Mapped TCP/UDP Port (router)
HANDLE hProxyEntry; // Handle to Proxy Entry (if any)
UINT32 Timeout; // Expiration time in SECONDS
void *pUserData; // Pointer to proxy callback data
} NATINFO;
- uint TcpState;
This is a condensed version of the state of the TCP connection that is be-
ing translated by this entry. This field is only valid when the Protocol field is
set to IPPROTO_TCP. The defined values are:
B-16
NAT Port Mapping
NI_TCP_CLOSED The connection is closed

NI_TCP_SYNSENT The peers are in the process of connecting
NI_TCP_ESTAB A connection has been established
- IPN IPLocal;
This is the IP address (in network format) of the peer host on the local net-
work (LAN). It is the entity that has been assigned a virtual IP address be-
hind the firewall.
- UINT16 PortLocal;
This is the port in use by the peer host on the local network (LAN). It is the
entity that has been assigned a virtual IP address behind the firewall.
- IPN IPForeign;
This is the IP address (in network format) of the peer host on the public
network (WAN). It is the entity that is on the physical network outside the
firewall.
- UINT16 PortForeign;
This is the port in use by the peer host on the public network (WAN). It is the
entity that is on the physical network outside the firewall.
- UINT8 – Protocol;
This is protocol in use by the NAT entry. It must be IPPROTO_TCP, IP-

PROTO_UDP, or IPPROTO_ICMP.
- UINT16 PortMapped;
This is the port in use by the router on its public (WAN) IP address. It is this
port that maps back to a specific local IP/port on the LAN.
- HANDLE hProxyEntry;
When a NAT entry is created as a result of a proxy filter being installed on a

specific port, the HANDLE to the proxy filter that spawned the NAT entry is
stored here.
- UINT32 Timeout;
This is time in seconds when the proxy entry will expire. The system
checks with a fairly large granularity, so the actual expiration can occur 10
to 20 seconds later. If this value is ZERO, the entry is static. A NAT entry
must be specified as STATIC when it is created. Setting Timeout to ZERO
will cause the entry to expire in 0 to 20 seconds.

NAT Port Mapping
- void * pUserData;
This field is reserved for use by proxy filter callback functions. It is not used
by the system software.
The NAT information structure of little importance when only port mapping is
required. Its real function is for use in NAT proxy filters.
B.2.4 NAT API Functions
NatNew Create a NAT Entry (for Port Mapping)
Syntax HANDLE NatNew( IPN IPLocal, UINT16 PortLocal,

IPN IPForeign, UINT16 PortForeign,
UINT8 Protocol, UINT16 PortMapped,
UINT32 Timeout );
Parameter(s) IPLocal IP address (in network format) of host on the LAN to map
PortLocal TCP/UDP port value of host on the LAN to map
IPForeign IP address of WAN peer (usually NULL/wild for port
mappings)
PortForeign TCP/UDP port of WAN peer (usually NULL/wild)
Protocol IP protocol (IPPROTO_TCP or IPPROTO_UDP)
PortMapped Port on router’s public WAN to map (usually a “well-known”
port)
Timeout Timeout of entry in seconds (NULL for STATIC)
Return Value Handle to NAT entry, or NULL on error.
Description This function creates a NAT entry with the parameters as specified.
For example, to allow a host on a virtual IP address of 1.2.3.4 to run a Telnet

server reachable via the router’s public (physical) IP address, a mapping
would be installed to map TCP port 23 (telnet) to 1.2.3.4:23. If the connection
were to be open to all foreign hosts, then IPForeign and PortForeign would be
left NULL. The value of Timeout would also be NULL to make the entry STAT-
IC…
hNatTelnet = NatNew( htonl(0x01020304), 23, 0, 0, IPPROTO_TCP, 23, 0 );
The function returns a handle to the NAT entry created. This handle should be
freed with NatFree() when the mapping is no longer desired.
B-18
NAT Port Mapping
NatFree Destroy a NAT Entry
Syntax void NatFree( HANDLE hNat );
Parameter(s) hNat Handle to NAT entry created with NatNew()
Description This function frees the supplied NAT entry. It is called to remove a STATIC NAT
entry that is no longer required.
NatGetPNI Get a Pointer to a NAT Entry’s NATINFO Structure
Syntax NATINFO NatGetPNI( HANDLE hNat );
Parameter(s) hNat Handle to NAT entry created with NatNew()
Return Value Pointer to NATINFO structure or NULL on error.
Description This function returns a pointer to the NATINFO structure defined above in sec-
tion B.2.3. It is used mainly by NAT proxy filter callback functions.

NAT Proxy Filters
B.3 NAT Proxy Filters

B.3.1 Synopsis
NAT proxy filters are used to allow NAT to operate correctly with network proto-
cols that have addressing specific data in their packet payload data. This API
(and NAT in general) is only used when the TCP/IP stack is acting as an IP
router, and when one the IP network on one side of the router is using virtual
IP addresses.
The functions described in this section illustrates how to install and remove
port proxy filters and their associated callback functions. The functional opera-
tion of NAT and NAT Port Mapping, and NAT Proxy is discussed in more detail
in section B.2.3.
B.3.2 Function Overview

The following functions are used to create and destroy proxy filters:
ProxyNew() Create Proxy Filter for NAT entries
ProxyFree() Destroy a Proxy Filter declaration
The following can be called from within a proxy filter callback function:
ProxyPacketMod() Modify a packet being processed by NAT
B.3.3 NAT Proxy Filter Callback Functions

The proxy filter callback functions allow the proxy programmer to examine NAT
entry properties as the entries are created, plus the examination of packet data
as packets pass between the LAN and WAN. This section describes the syntax
of the callback functions that are supplied to the proxy filter when it is first
installed in the system.
ProxyEnableCallback Proxy Enable Callback Function
Syntax int SampleProxyEnableCallback( NATINFO *pNI, uint EnableFlag );

Parameter(s) pNI Pointer to NATINFO structure of Nat entry created
EnableFlag Set to 1 for an enable request
Return Value 1 to allow normal operation, or NULL to abort new NAT entry.
Description This function is called when a NAT entry containing a proxy is created or de-
stroyed. When the entry is created, the value of EnableFlag is 1. When the
entry is being destroyed, the value of EnableFlag is zero.
When EnableFlag is set, the return value of this function determines if the NAT
entry will be enabled. If this function returns NULL, the NAT entry is immediate-
ly destroyed (in this event, the callback is not called a second time for this de-
stroy). This can be used to restrict peer connections.
B-20
NAT Proxy Filters
ProxyTx/RxCallback Proxy Tx/Rx Callback Functions
Syntax int SampleProxyTxCallback( NATINFO *pNI, IPHDR *pIpHdr );

int SampleProxyRxCallback( NATINFO *pNI, IPHDR *pIpHdr );
Parameter(s) pNI Pointer to NATINFO structure of Nat entry in use

pIpHdr Pointer to the IP header of the packet being translated
Return Value 1 to allow normal operation, or NULL to abort the supplied packet.
Description This function is called when a packet is crossing the router from the WAN to
the LAN (“Rx” callback) or from the LAN to the WAN (“Tx” callback). The NAT
entry containing a proxy which matched the packet is described by the sup-
plied NATINFO structure. This structure was described in section B.2.3 above.
The purpose of the callback is to examine the packet and take appropriate ac-
tion based on its contents. The packet payload can be easily modified by the
ProxyPacketMod() function described later in this section. The translation of
the IP address and port information can not be altered by this callback, howev-
er the callback can act as a packet filter and discard unwanted packets by re-
turning a value of NULL.
B.3.4 NAT Proxy API Functions
ProxyNew Create a New Proxy Filter for NAT Entries
Syntax HANDLE ProxyNew( uint NatMode, UINT8 Protocol, UINT16 Port, IPN
IPTarget,
int (*pfnEnableCb)( NATINFO *, uint ),
int (*pfnTxCb)( NATINFO *, IPHDR * ),
int (*pfnRxCb)( NATINFO *, IPHDR * ) );
Parameter(s) NatMode Port direction to detect (NAT_MODE_RX or

NAT_MODE_TX)
Protocol Protocol to use (IPPROTO_TCP or IPPROTO_UDP)
Port Port value for RX or TX packets to detect
IPTarget New IP destination NAT_MODE_RX proxy
pfnEnableCb Pointer to proxy “Enable” callback function (NULL if none)

NAT Proxy Filters
pfnTxCb Pointer to proxy “Tx” callback function (NULL if none)

pfnRxCb Pointer to proxy “Rx” callback function (NULL if none)
Return Value Handle to new proxy, or NULL on error.
Description This function creates a “hook” that is examined whenever a new NAT entry is
created.
The calling parameter NatMode specifies the direction of the proxy

(NAT_MODE_RX for servers behind the firewall, and NAT_MODE_TX for cli-
ents behind the firewall).
The Protocol and Port value is the IP protocol and ”well know” port of the proto-
col to proxy.
For example, if setting up a FTP client proxy, set:
NatMode = NAT_MODE_TX, Protocol = IPPROTO_TCP, and Port = 21.
IPTarget is used only in server proxies (when NatMode is set to

NAT_MODE_RX). This specifies the machine behind the firewall that is actual-
ly providing the service.
The three pointers to callback functions correspond to the proxy filter callback
functions described in the previous section.
The function returns a handle to the new proxy. Note that a proxy handle is not
the same as (or compatible with) a NAT entry handle.
The proxy should be destroyed by calling ProxyFree() when it is no longer

needed.
ProxyFree Destroy a Proxy Filter Declaration
Syntax void ProxyFree( HANDLE hProxy );
Parameter(s) hProxy Handle to Proxy Filter entry created with ProxyNew()
Description This function frees the supplied Proxy Filter entry. It is called to remove an
entry that is no longer required.
B-22
NAT Proxy Filters
ProxyPacketMod Modify the Contents of a Packet
Syntax IPHDR *ProxyPacketMod(uint Offset, uint OldSize, uint NewSize, UINT8

*pNewData );
Parameter(s) Offset Offset in bytes from start of IP header to first modified byte
OldSize Size of old data at Offset
NewSize Size of new data to replace old data at Offset
pNewData Pointer to new data to replace old data
Return Value Pointer to new IP header of packet. This pointer is used for further modifica-
tions (if needed).
Description This function may only be called from a proxy filter callback function. Its pur-
pose is to modify the contents of a TCP or UDP packet, and perform the neces-
sary adjustments for packet size – including TCP sequencing adjustment.

Appendix
AppendixCA
Point to Point Protocol
Point to point protocol (PPP) was originally designed as a replacement for

SLIP (serial line IP) in sending IP packets a serial line. In addition to its massive
popularity in performing this function, PPP has also been increasingly used for
the transmission of packets over other media. This is due to PPP’s inherent
peer-to-peer nature, allowing for per-connection security and billing.
The TCP/IP stack has built in support for both PPP severs and clients. The
PPP support API is designed to be shared by one or more physical devices.
One obvious device that can be hooked to PPP is a serial line, but the stack
also contains support for PPP over Ethernet (PPPoE). The low level PPP API
as well as Serial HDLC and PPPoE are all discussed in this appendix.
Topic Page
C.1 Low-Level PPP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

C.2 Serial HDLC Client and Server Support . . . . . . . . . . . . . . . . . . . . . . . . C-14
C.3 PPPoE Client and Server Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-20
C.4 Creating PPP Server User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . C-25
C-1
Low-Level PPP Support
C.1 Low-Level PPP Support

This section describes the operation of the PPP support API included in the
TCP/IP stack.
C.1.1 Please Note

Unlike the HDLC and PPPoE APIs which are application callable, the low level
PPP support API is designed to be called from the kernel layer only. Users
should be thoroughly familiar with the operation of the operation of the kernel
and the llEnter()/llExit() functions before attempting to use the APIs described
in this section.
C.1.2 PPP Operation

PPP is very much like Ethernet in that there is a defined packet format. The
basic PPP packet is shown below. It consists of flag delimiters, address and
control bytes, protocol field (similar to ether-type under Ethernet), and a two
byte checksum.
Figure C–1. Standard PPP Frame Over Serial Line
Flag (7E) Addr (FF) Control (03) Protocol Payload CRC Flag (7E)
1 1 1 2 1500 2 1
In order to abstract out the actual processing of the PPP data from the process-
ing of the PPP frame encoding, the PPP support included in the TCP/IP stack
expects a smaller frame, consisting of the protocol and payload fields only.
This format is shown in Figure C–2.
Figure C–2. PPP Frame Processed by PPP API
Protocol Payload
2 Size specified by layer 2 (about 1500)
The abstraction of PPP from the layer 2 encoding allows PPP to be carried by
a variety of physical devices. The programming interface to the PPP layer
called by the application is actually exposed by the layer 2 encoder. This layer
2 encoder is referred to as a serial interface (SI), but does not have to be a seri-
al port. This interoperation between PPP and the SI is shown in Figure C–3.
The functions shown in the dotted rectangle are those provided by the serial
interface software.
C-2
Figure C–3. Serial Interface (SI) Abstraction
ÎÎÎ
Application Software
PPP Connect
ÎÎÎ
Session API
ÎÎÎ
Timer
ÎÎÎ
ÎÎÎ
Hardware
ÎÎÎ
Packet Decoding TCP/IP
Stack
ÎÎÎ
Packet Encoding
ÎÎÎ
TX Packet Call Status
ÎÎÎ
Serial Interface
(SI) Callback
As shown in Figure C–3, the SI interface has the responsibility of providing for
connection control, a timer used by PPP for timeout, packet encoding and de-
coding, and a SI callback function for status messages and packet transmis-
sion. Note that the SI driver developer also defines the actual API used by the
application software to establish and tear down PPP connection sessions.
There is no specific requirements in specifying the session API for any particu-
lar PPP device, but the APIs defined for HDLC and PPPoE can be used guide.
C.1.3 Function Overview

The SI interface module is charged with communicating with both the hard-
ware and the application program, but the PPP packets themselves are pro-
cessed via the PPP support functions in the stack. The PPP support software
provides the following functions for use by the SI module:
pppNew() Create a new PPP connection instance
pppFree() Destroy an existing PPP connection instance
pppTimer() Inform PPP that a 1 second timer tick has expired
pppInput() Pass in a received PPP packet for processing
The formal declaration of these functions appear later in this section.
NOTE: These functions can only be called in kernel mode. Please refer to Ap-
pendix A for programming in kernel mode.
Point to Point Protocol C-3

C.1.4 Supported Protocols

In keeping with trying to maintain a small footprint, the PPP software supports
a subset of the general PPP protocols. The following are supported:
- Link Control Protocol (LCP)

- Internet Protocol Control Protocol (IPCP)
- Password Authentication Protocol (PAP)
- Challenge Handshake Authentication Protocol (CHAP) using MD5
- Internet Protocol (IP)
C.1.5 SI Module Callback Function

The PPP support API is used for connection instance creation and destruction,
and to pass received packets to the stack. In order to get information about
PPP back from the stack, and in order to allow the stack to request the trans-
mission of PPP packets, the SI module supplies a callback function. A pointer
to this callback is passed to PPP as a parameter to pppNew().
NOTE: This function is called in kernel mode. Please refer to Appendix A for
programming in kernel mode.
C.1.5.1 SIControl Function Declaration
Syntax void SIControl( HANDLE hSI, uint Message, UINT32 Data, HANDLE hPkt );
Parameter(s) hSI Handle to SI private data

Message Message code describing the PPP event
Data Additional data concerning the message
hPkt Handle to a packet when Message is
SI_MSG_SENDPACKET
Description This function is called when a PPP needs to notify the serial interface (SI) of
a change in status, or when it needs SI to transmit a packet.
The hSI parameter is a handle (pointer to a void) that is originally passed to

PPP via pppNew(). This value allows the SI module to know which of its own
connection instances is in use. The PPP instance handle in use is not supplied,
but rather should be obtained by reference from the supplied SI handle. If the
programmer of the SI module does not wish to track handles, then this parame-
ter may be NULL (always as originally supplied to pppNew()). This is NOT the
handle to the PPP instance that is passed to other functions in the PPP API.
The purpose of the callback is determined by the value of the Message param-
eter. The following message values are defined for the this parameter:
C-4
SI_MSG_CALLSTATUS PPP connection status has changed

SI_MSG_SENDPACKET PPP is requesting a packet be encoded and
transmitted
SI_MSG_PEERCMAP LCP has received the peer’s 32 bit asynch
character map
C.1.5.2 SI_MSG_CALLSTATUS Message

When this message value is set, the callback function was called by PPP to
update the status of the connection instance. When the callback is called with
this message, the value of Data will contain additional information about the
call. Data can be set to any of the following values:
SI_CSTATUS_WAITING Connection instance is idle
SI_CSTATUS_NEGOTIATE Instance in LCP negotiation stage
SI_CSTATUS_AUTHORIZE Instance in authorization stage
SI_CSTATUS_CONFIGURE Instance in IP configuration stage
SI_CSTATUS_CONNECTED Instance is fully connected and
operational
SI_CSTATUS_DISCONNECT Connection dropped
SI_CSTATUS_DISCONNECT_LCP Connection dropped in LCP stage
SI_CSTATUS_DISCONNECT_AUTH Connection dropped in
authorization stage
SI_CSTATUS_DISCONNECT_IPCP Connection dropped in IP
configuration stage
In the case that Data is set to any of disconnect messages, pppFree() should
be called to destroy the connection instance. For all other status values, no ac-
tion is required.
Note: It is always safe to assume that then the value of Data >= SI_CSTA-
TUS_DISCONNECT, that the message is some type of disconnect.
C.1.5.3 SI_MSG_ SENDPACKET Message

When this message value is set, the callback function was called by PPP to
transmit a packet. The Data parameter is set to the 16 bit PPP protocol of the
packet, and the hPkt parameter contains a handle to a packet (PKT) object that
contains the packet payload. It is the job of the SI callback function to encode
the packet and transmit it on the physical hardware.
C.1.5.4 SI_MSG_ PEERCMAP Message

Serial interfaces to PPP require a translation map for the first 32 character val-
ues. This map informs the packet encoded which characters must be escaped

and which do not. The default value of the peer CMAP should be 0xffffffff, and
updated only when this message is received. Whether or not PPP will attempt
to exchange CMAP information with its peer, is determined by passing flags
to pppNew() when the connection instance is created.
C.1.5.5 Example Callback Function Implementation
The following is an example of a SI module callback function from the PPPoE

code inside the TCP/IP stack. Some of the code specific to PPPoE has been
removed for clarity. The code that remains illustrates the basic processing that
must be done for the various SI callback messages. The function calls made
in this example are described in Appendix A.
//––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
// SI Control Callback Function for PPPoE
//––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
void pppoeSI( HANDLE hSI, uint Msg, UINT32 Aux, HANDLE hPkt )
{
// hSI is really a pointer to our private data structure
PPPOE_INST *ppi = (PPPOE_INST *)hSI;
HANDLE hFrag;
uint Offset,ValidSize,Payload;
UINT8 *pb;
ETHHDR *pEth;
switch( Msg )
{
case SI_MSG_CALLSTATUS:
// Record status so client can call ”GetStatus” function
ppi–>Status = (uint)Aux;
if( Aux >= SI_CSTATUS_DISCONNECT )

{
// Close PPP
if( ppi–>hPPP )
{
hTmp = ppi–>hPPP;
ppi–>hPPP = 0;
pppFree( hTmp );
}
// Terminate the PPPOE session
<PPPoE specific code removed for clarity>
}
break;
case SI_MSG_PEERCMAP:
// PPPoE does not use async translation maps. The peer map in Aux
DbgPrintf( DBG_WARN, ”PPPOE: Unexpected Peer CMAP %08lx”,Aux );
C-6
break;
case SI_MSG_SENDPACKET:
// Make sure packet is valid
if( !hPkt || !(hFrag = PktGetFrag( hPkt )) )
{
DbgPrintf(DBG_ERROR,”pppoeSI: Bad packet”);
goto TxDone;
}
// Silently discard packet if we’re not connected

if( !ppi–>SessionId )
goto TxDone;
// Get the buffer parameters

pb = FragGetBufParams( hFrag, 0, &ValidSize, &Offset );
// We can’t have an LLC since SI framing is undefined

if( PktGetFlags( hPkt ) & FLG_PKT_LLC_VALID )
{
DbgPrintf(DBG_ERROR,”pppoeSI: LLC on PPP packet”);
PktFree( hPkt );
return;
}
// NOTE: Unlike a serial port, PPPoE will use Ethernet to send

// the packet data. Thus, we would like to reuse the supplied
// packet handle and pass that handle directly to the low–level
// packet driver. To do this, we go through a little extra work
// on the packet. A serial device could simple start encoding data
// at this point.
//
// Aux = 16 bit PPP Protocol Value
// ValidSize = Size of Payload field
// (pb+Offset) = Pointer to start of Payload data
<PPPoE specific code removed for clarity>
// If we consume the packet here (a serial version of the callback

// always will), we must free the packet handle AFTER we have copied
// out the payload data.
TxDone:
PktFree( hPkt );
break;
}
}

C.1.6 Tips for Implementing a PPP Serial Interface (SI) Module Instance
C.1.6.1 Multiple Instances
PPP supports multiple instances, but it is up to the SI module implementation

to track multiple instances of itself. In general, a module that supports multiple
instances will have a locally global head pointer to its first instance, and then
an array or linked list for additional instances.
When a new PPP connection is established, a new SI module instance should

be allocated and a handle to that instance is passed to the pppNew() function.
The handle that pppNew() returns must be associated with the handle to the
SI instance. The PPP handle must be passed to all other PPP API functions,
and PPP will pass back the SI instance handle to the SI callback function.
When new data arrives from the hardware, it is the responsibility of the SI mod-
ule to associate that data with a specific SI instance. The SI instance can then
be accessed to retrieve the handle to the PPP instance to use with any PPP
function calls.
C.1.6.2 Using the Timer Object
PPP requires that its pppTimer() function be called once every second. The
easiest way to implement this requirement is to use the timer object built into
the kernel. The timer can be allocated when the SI instance is allocated, asso-
ciated with the instance, and then freed when the SI instance is destroyed. The
timer object is supplied a callback function that is called in kernel mode. In this
callback function, the pppTimer() function is called for all known instances of
PPP. This is shown later on in the example code.
C.1.6.3 Registering Packet Padding Requirements
Although a serial interface will probably not have any special requirements for
packets from the stack, it must at least be able to construct valid packets to
send to the pppInput() function. In order to use the packet allocation function
provided by the IF API (see Appendix A), the SI module should declare its pad-
ding requirements via the IFSetPad() function. For a serial interface that does
not use the packet buffer to physically send the packet, the size of the PPP
“header” would be 2 bytes (protocol field), and the padding would be 2 bytes
(checksum).
As an example of a system that does use the packet to send, consider PPPoE.
It uses the Ethernet device to send a PPPoE encapsulated packet. Its padding
requirements are 14 bytes for the Ethernet header, plus 6 bytes for the PPPoE
header, plus 2 bytes for the PPP header (protocol field), for a total of 22 bytes.
C-8
C.1.6.4 Creating a Packet
Along with decoding any packet that is received on the physical hardware and
stripping off all but the protocol and payload fields, the SI module must supply
the received data as a packet (PKT) object to the pppInput() function. The fol-
lowing example code illustrates the creation of a packet object for holding new
packet data. This function assumes a packet with a max payload (MRU) of
1500 bytes
HANDLE SIModuleCreatePacket( calling parameters )

{
HANDLE hPkt;
HANDLE hFrag;
uint Offset,ValidSize;
UINT8 *pb;
// Create a packet with up to 1500 bytes of payload

// (If we informed the IF module of our header requirements, we
// know we’ll have room for our 2 byte header)
if( !(hPkt = IFCreatePacket( 1500, 0, 0 )) )
return( 0 );
// Get the memory frag for this packet

hFrag = PktGetFrag( hPkt );
// Get pointers to packet headers

pb = FragGetBufParams( hFrag, 0, 0, 0 );
Offset = PktGetSizeLLC( hPkt );
// The value of ”Offset” is that assigned by IFCreatePacket().

// Its probably 14 bytes, but we better make sure its at least 2
// bytes. We’ll take off 2 bytes (the size of our header) and start
// writing our data there. We know we can write up to 1502 bytes.
if( Offset <= 2 )
Offset = 0;
else
Offset –= 2;
// Set pb to point to where we start writing data

pb += Offset;
//–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
// Fill in the packet buffer here. The pointer ’pb’ now
// where the 2 byte protocol field should start.
//–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
//
// Fixup packet frag info
//
// The value of ’Offset’ is already valid, but we need to provide
// the size of the data. This size includes 2 byte protocol
// value. For example, for a 1500 byte IP packet, the value
// of ’PACKETSIZE’ is 1502

//
FragSetBufParams( hFrag, PACKETSIZE, Offset );
// This handle is what we give to PPP
return( hPkt );
}
C.1.7 PPP API Functions

The following is the full description of the PPP functions described in this sec-
tion.
pppNew Create a New PPP Connection Instance
Syntax HANDLE pppNew( HANDLE hSI, uint pppFlags, uint mru, IPN IPServer, IPN
IPMask, IPN IPClient, char *Username, char *Password,
UINT32 cmap,
void (*pfnSICtrl)( HANDLE, uint, UINT32, HANDLE ) );
Parameter(s) hSI Handle to SI module to be passed back to callback functio
pppFlags Connection option flags
mru Maximum receive unit (max size of Payload)
IPServer IP address of server in server mode (NULL in client mode)
IPMask IP subnet mask of client in server mode (NULL in client mode)
IPClient IP address of client in server mode (NULL in client mode)
Username Pointer to username in client mode (NULL in server mode)
Password Pointer to password in client mode (NULL in server mode)
cmap 32 bit local CMAP to pass to peer
pfnSICtrl Pointer to SI module callback function
Return Value Handle to new PPP connection instance, or NULL on error.
Description This function is called to create a new PPP connection instance. The type of
connection created is determined by the calling parameters.
- hSI – This is a private handle to created by the caller that points back to
the caller’s instance data. It is passed back to the caller via the callback
function pointed to by pfnSICtrl, and can be used to link back to caller’s
instance data when the callback is executed.
- pppFlags – The flags determine what type of connection instance to
create, and what type of options to support in the connection instance. In
the pppFlags parameter, one and only one of the following flags must be
set:
PPPFLG_SERVER Create PPP server connection instance
PPPFLG_CLIENT Create PPP client connection instance
C-10
When operating in SERVER mode, any of the following flags can also be
set:
PPPFLG_OPT_AUTH_PAP Require PAP authentication
PPPFLG_OPT_AUTH_CHAP Require CHAP authentication
PPPFLG_OPT_USE_MSE Use MS extensions as server
PPPFLG_OPT_LOCALDNS Claim Local IP as DNS server
PPPFLG_SIOPT_SENDCMAP Send an async character map
PPPFLG_SIOPT_RECVCMAP Accept an async character map
PPPFLG_CH1 Allow server channel/group 1
account users
account users
account users
account users
When operating in CLIENT mode, any of the following flags can also be
set:
PPPFLG_OPT_USE_MSE Use MS extensions as client
- mru – The MRU is maximum receive unit, or the max size of the payload
portion of a PPP packet. For a standard serial link, the MRU is typically
1500, but can be smaller.
- IPServer – When creating the PPP instance in SERVER mode, this is the
IP address in network format of the TCP/IP stack reported to the peer.
When operating in CLIENT mode, this value is NULL.
- IPMask – When creating the PPP instance in SERVER mode, this is the
IP subnet mask of the peer’s IP network reported to the peer. When oper-
ating in CLIENT mode, this value is NULL.
- IPClient – When creating the PPP instance in SERVER mode, this is the
IP address in network format of the peer reported to the peer. When oper-
ating in CLIENT mode, this value is NULL.
- Username – When creating the PPP instance in CLIENT mode, this is a
pointer to a NULL terminated string containing the username to use in PAP
or CHAP authentication. The maximum string length is defined by
PPPNAMELEN. When operating in SERVER mode, this value is NULL.

- Password – When creating the PPP instance in CLIENT mode, this is a

pointer to a NULL terminated string containing the password to use in PAP
or CHAP authentication. The maximum string length is defined by
PPPNAMELEN. When operating in SERVER mode, this value is NULL.
- cmap – When the PPPFLG_SIOPT_SENDCMAP flag is set in the

pppFlags parameter, this is the CMAP value that is sent to the peer; other-
wise it is NULL.
- pfnSICtrl – This is a required pointer to the caller’s callback function to

handle status updates from the stack, and requests to transmit PPP pack-
ets. See section C.1.5 for more detail.
When successful, this function returns a handle to a new PPP instance. This
handle is used by the caller when calling other function in the PPP API.
pppFree Destroy PPP Connection Instance
Syntax void pppFree( HANDLE hPPP );
Parameter(s) hPPP Handle to PPP instance created with pppNew()
Description This function is called to close and destroy a PPP connection instance created
with pppNew(). This function MUST be called to free the PPP handle, even if
the PPP connection itself is already disconnected.
pppInput Send a PPP Packet to PPP for Processing
Syntax void pppInput( HANDLE hPPP, HANDLE hPkt );

hPkt Handle to packet
Description This function is called when a PPP packet is received on a active serial inter-
face. The packet is data decoded into the PPP protocol and payload fields, and
given to PPP as a packet object. The handle hPPP is the PPP connection
instance returned from pppNew() for this connection, and hPkt is a packet ob-
ject created by using the kernel API (see section C.1.6.4).
C-12
pppTimer Notify PPP of One Second Tick
Syntax void pppTimer( HANDLE hPPP );
Description This function is called on an active PPP instance to notify PPP that one second
has elapsed. Since the PPP API is entirely stateless, it relies on the serial inter-
face for time tick notification.

Serial HDLC Client and Server Support
C.2 Serial HDLC Client and Server Support
C.2.1 Please Note

The HDLC API is user callable. Unlike the low level PPP support API, users
should not use the llEnter()/llExit() functions when calling the functions de-
scribed in this section.
C.2.2 Synopsis
The implementation of HDLC supplied in the TCP/IP stack library is available
in an optional serial support library that includes the HAL layer serial driver
(llSerial). The HDLC module is all that is required to enable PPP over the serial
port. There is no need to call the PPP API directly.

Called by Application:
hdlcNew() Create a Serial HDLC Client Session
hdlcFree() Destroy a Serial HDLC Client Session
hdlcGetStatus() Get the Call Status of a Serial HDLC Client
Session
hdlcsNew() Create a Serial HDLC Server Session
hdlcsFree() Destroy a Serial HDLC Server Session
hdlcsGetStatus() Get the Call Status of a Server HDLC Client
Session
Called by Serial Port Driver:

hdlcInput() Send HDLC input buffer for processing
C.2.4 HDLC API Functions
hdlcNew Create a Serial HDLC Client Session
Syntax HANDLE hdlcNew( uint Dev, uint pppFlags, UINT32 cmap, char *Username,
char *Password );
Parameter(s) Dev Physical index of serial port to use

cmap Async control character map
C-14
Username Pointer to client account username

Password Pointer to client account password
Return Value If it succeeds, the function returns a handle to a PPPoE client instance. Else,
it returns NULL.
Description This function is called to create a new serial HDLC client instance on the physi-
cal serial interface specified by the index Dev.

the pppFlags parameter, the following flags must be set:
In addition, any of the following flag can also be set:

(strongly recommended)
- cmap – This is the desired value of the async character control map that
is sent to the peer to allow frame compression by skipping the escape cod-
ing of characters when it is not required. The mask contains set bit for each
character (0 to 31) that must be escaped when sent by the peer. If the
PPPFLG_SIOPT_SENDCMAP option is not set, it is assumed that all 32
characters must be sent via the escape sequence.
- Username – This is a pointer to a NULL terminated string containing the

username to use in PAP or CHAP authentication. The maximum string
length is defined by PPPNAMELEN.
- Password – This is a pointer to a NULL terminated string containing the

password to use in PAP or CHAP authentication. The maximum string
When successful, this function returns a handle to a new serial HDLC instance
The current status of the connection can be queried at any time by calling
hdlcGetStatus().

hdlcFree Destroy a Serial HDLC Client Session
Syntax void hdlcFree( HANDLE hHDLC );
Parameter(s) hHDLC Handle to HDLC Client Session
Description This function is called to close and destroy a serial HDLC client session that
was created with hdlcNew(). This function is always called once for every
HDLC instance handle. If the connection is no longer active, it frees the
instance memory. If the connection is still active, it first disconnects the call
first.
hdlcGetStatus Get the Status of a Serial HDLC Client Session
Syntax uint hdlcGetStatus( HANDLE hHDLC );
Parameter(s) hHDLC Handle to HDLC Client Session
Return Value This function returns a uint that will be set to one of the following values:
SI_CSTATUS_WAITING Connection is idle (PPPoE
session opening)
SI_CSTATUS_NEGOTIATE Connection in LCP negotiation
stage
SI_CSTATUS_AUTHORIZE Connection in authorization
stage
SI_CSTATUS_CONFIGURE Connection in IP configuration
stage
SI_CSTATUS_CONNECTED Connection is fully connected
and operational
SI_CSTATUS_DISCONNECT_LCP Connection dropped in LCP
stage
authorization stage
configuration stage
Description This function is called to get the connection status of a serial HDLC client ses-
sion using the HDLC instance handle returned from hdlcNew(). This function
can be called anytime after the handle is created with hdlcNew(), and before
it is destroyed with hdlcFree().
C-16
hdlcsNew Create a Serial HDLC Server Session
Syntax HANDLE hdlcsNew( uint Dev, uint pppFlags, UINT32 cmap, IPN IPServer,
IPN IPMask, IPN IPClient );
Parameter(s) Dev Physical index of serial port to use

cmap Async control character map
IPServer IP address of server in network format
IPMask IP subnet mask in network format of the peer’s network
IPClient IP address in network format of the client
Return Value If it succeeds, the function returns a handle to a serial HDLC server instance.
Else, it returns NULL.
Description This function is called to create a new serial HDLC server instance on the
physical serial interface specified by the index Dev.


account users
account users
account users
account users
- cmap – This is the desired value of the async character control map that
is sent to the peer to allow frame compression by skipping the escape cod-
ing of characters when it is not required. The mask contains set bit for each

character (0 to 31) that must be escaped when sent by the peer. If the
PPPFLG_SIOPT_SENDCMAP option is not set, it is assumed that all 32
characters must be sent via the escape sequence.
- IPServer – This is the IP address in network format of the TCP/IP stack

reported to the peer
- IPMask – This is the IP subnet mask of the peer’s IP network reported to

the peer
- IPClient – This is the IP base address in network format of the IP address

to be assigned to the client.
When successful, this function returns a handle to a new serial HDLC instance
The current status of the connection can be queried at any time by calling
hdlcGetStatus().
hdlcsFree Destroy a Serial HDLC Server Session
Syntax void hdlcsFree( HANDLE hHDLC );
Parameter(s) hHDLC Handle to HDLC Server Session
Description This function is called to close and destroy a serial HDLC server session that
was created with hdlcsNew(). This function is always called once for every
HDLC instance handle. If the connection is no longer active, it frees the
instance memory. If the connection is still active, it first disconnects the call
first.
hdlcsGetStatus Get the Status of a Serial HDLC Server Session
Syntax uint hdlcsGetStatus( HANDLE hHDLC );
Parameter(s) hHDLC Handle to HDLC Server Session
session opening)
stage
stage
C-18

stage
and operational
stage
authorization stage
configuration stage
Description This function is called to get the connection status of a serial HDLC server ses-
sion using the HDLC instance handle returned from hdlcsNew(). This function
can be called anytime after the handle is created with hdlcsNew(), and before
it is destroyed with hdlcsFree().

PPPoE Client and Server Support
C.3 PPPoE Client and Server Support
C.3.1 Please Note

The PPPoE API is user callable. Unlike the low level PPP support API, users
should not use the llEnter()/llExit() functions when calling the functions de-
scribed in this section.
C.3.2 Synopsis
The PPPoE (PPP over Ethernet) specification allows for PPP packets to be
transmitted in a peer to peer method over an Ethernet tunnel. The standard
has gained in popularity since it allows for the use of multiple user accounts
on a single Ethernet network.
The implementation of PPPoE supplied in the TCP/IP stack library is built into
the stack library code, and linked to the Ether object which handles packets
from all Ethernet devices in the HAL layer. Thus is it not necessary to access
or alter the HAL to use PPPoE.
The software can be used as a PPP server or PPP client, but not both simulta-
neously. In both cases, PPPoE makes use of the the PPP programming inter-
faces described earlier in this section. Thus for server mode, the PPP sever
will make use of the same user account information as a serial based server.

The PPPoE function API is quite short:
pppoeNew() Create a PPPoE Client Session
pppoeFree() Destroy a PPPoE Client Session
pppoeGetStatus() Get the Call Status of a PPPoE Client Session
pppoesNew() Create a PPPoE Server Session
pppoesFree() Terminate a PPPoE Server Session
C.3.4 PPPoE API Functions
pppoeNew Create a PPPoE Client Session
Syntax HANDLE pppoeNew( HANDLE hEther, uint pppFlags, INT8 *Username, INT8
*Password );
Parameter(s) hEther Handle to Ether device on which to look for a PPPoE server
C-20
Username Pointer to client account username

Password Pointer to client account password
Return Value If it succeeds, the function returns a handle to a PPPoE client instance. Else,
it returns NULL.
Description This function is called to create a new PPPoE client instance on the Ether type
interface specified by the handle hEther.


- Username – This is a pointer to a NULL terminated string containing the

username to use in PAP or CHAP authentication. The maximum string
- Password – This is a pointer to a NULL terminated string containing the

password to use in PAP or CHAP authentication. The maximum string
When successful, this function returns a handle to a new PPPoE instance The
current status of the PPPoE connection can be queried at any time by calling
pppoeGetStatus().
pppoeFree Destroy a PPPoE Client Session
Syntax void pppoeFree( HANDLE hPPPOE );
Parameter(s) hPPPOE Handle to PPPoE Client Session
Description This function is called to close and destroy a PPPoE client session that was
created with pppoeNew(). This function is always called once for every PPPoE
instance handle. If the connection is no longer active, it frees the instance
memory. If the connection is still active, it first disconnects the call.

pppoeGetStatus Get the Status of a PPPoE Client Session
Syntax uint pppoeGetStatus( HANDLE hPPPOE );
Parameter(s) hPPPOE Handle to PPPoE Client Session
session opening)
stage
stage
stage
and operational
stage
authorization stage
configuration stage
Description This function is called to get the connection status of a PPPoE client session
using the PPPoE instance handle returned from pppoeNew(). This function
can be called anytime after the handle is created with pppoeNew(), and before
it is destroyed with pppoeFree().
pppoesNew Create a PPPoE Server Session
Syntax HANDLE pppoesNew( HANDLE hEther, uint pppFlags, uint SessionMax, IPN
IPServer, IPN IPMask, IPN IPClientBase, INT8
*ServerName, INT8 *ServiceName );
Parameter(s) hEther Handle to Ether device on which to invoke the PPPoE server
SessionMax Max number of client connections allowed
IPServer IP address of server in network format
IPMask IP subnet mask in network format of the client address pool
IPClientBase IP base address in network format of the client address pool
C-22
ServerName Server name reported via PPPoE protocol

ServiceName Service name reported via PPPoE protocol
Return Value If it succeeds, the function returns a handle to a PPPoE server instance. Else,
it returns NULL.
Description This function is called to create a new PPPoE sever instance on the Ether type
interface specified by the handle hEther.
- SessionMax – This value is the maximum number of simultaneous peer

connections to be allowed at any given time. Thus, it is also the size mini-
mum size of the client IP address pool.


PPPFLG_OPT_USE_MSE Use MS extensions as server
PPPFLG_OPT_LOCALDNS Claim Local IP as DNS server
account users
account users
account users
account users
- IPServer – This is the IP address in network format of the TCP/IP stack

reported to the peer
- IPMask – This is the IP subnet mask of the peer’s IP network reported to

the peer
- IPClientBase – This is the IP base address in network format of the IP ad-

dress pool to be assigned to and reported to peer connections. The size
of the address pool is determined by the value of SessionMax.
- ServerName – This is a required pointer to a NULL terminated string con-

taining the server name that is reported to PPPoE clients. The maximum

length of this name including the NULL terminator is defined by

PPPOE_NAMESIZE. If a longer name is supplied, this function will fail.
- ServiceName – This is a required pointer to a NULL terminated string con-

taining the service name that is reported to PPPoE clients. The maximum
length of this name including the NULL terminator is defined by
PPPOE_NAMESIZE. If a longer name is supplied, this function will fail.
When successful, this function returns a handle to a new PPPoE server

instance The status individual connects is not available to the caller, but
tracked automatically by PPPoE. When sessions are added or destroyed, the
IP address callback supplied to NC_NetStart() is called and connections can
be tracked by the applications programmer via this function callback.
pppoesFree Destroy a PPPoE Server Session
Syntax void pppoesFree( HANDLE hPPPOES );
Parameter(s) hPPPOES Handle to PPPoE Server Session
Description This function is called to close and destroy a PPPoE server session that was
created with pppoesNew(). This function is always called once to shutdown
the PPPoE server. Any external client currently connected to the server is dis-
connected.
C-24
Creating PPP Sever User Accounts
C.4 Creating PPP Sever User Accounts
C.4.1 Synopsis
In order to use the PPP or PPPoE protocol in server mode, it advisable to pro-
tect access to the system through the use of a PPP authentication protocol.
The PPP supplied in the stack library allows for the use of either PAP or CHAP
in user authentication. The database of authorized users (name and pass-
word) is stored in the configuration system.
C.4.2 Adding and Reviewing User Accounts

The definition of the user account entry in the configuration system is defined
in 4.4.7. Note in that section that the server “channel” flags PPPFLG_CH1
through PPPFLG_CH4 are duplicated in both the server flags and the client
account flags. This allows the system programmer to allow different classes
of services for different channels.
The methodology of adding, querying, and removing user accounts is the

same for any other tag in the configuration system. Some simple examples fol-
low. More example code can be found in the sample console program.
C.4.3 Adding a PPP User Account

The following code adds a PPP user account for the user supplied in name with
a password supplied in password. Note that we also use the AcctFind() func-
tion to verify the account doesn’t already exists.
void AcctAdd( char *name, char *password )

{
CI_ACCT CA;
HANDLE hAcct;
int rc;
// Check string lengths for name and password

if( strlen( name ) >= CFG_ACCTSTR_MAX ||
strlen( password ) >= CFG_ACCTSTR_MAX )
{
printf(”Name or password too long, %d character max\n\n”,
CFG_ACCTSTR_MAX–1);
return;
}
// See if the account already exists

hAcct = AcctFind( tok2 );
if( hAcct )
{
printf(”Account exits – remove old account first\n\n”);

// We must de–reference the account we found

CfgEntryDeRef( hAcct );
return;
}
// Fill in the CA record

strcpy( CA.Username, name );
strcpy( CA.Password, password );
// Give user access to all channels

CA.Flags = CFG_ACCTFLG_CH1|CFG_ACCTFLG_CH2|CFG_ACCTFLG_CH3|CFG_ACCTFLG_CH4;
// Add it to the configuration

rc = CfgAddEntry( 0, CFGTAG_ACCT, CFGITEM_ACCT_PPP,
CFG_ADDMODE_NOSAVE, sizeof(CI_ACCT),
(UINT8 *)&CA, 0 );
if( rc < 0 )
printf(”Error adding account\n”);
else
printf(”Account added\n”);
return;
}
C.4.4 Searching for a PPP User Account

The following code implements the AcctFind() function called in the previous
example. Note that the same method could be used to print out a list of all ac-
counts.
HANDLE AcctFind( char *name )

{
HANDLE hAcct;
CI_ACCT CA;
int rc;
int size;
// Get the first user account

rc = CfgGetEntry( 0, CFGTAG_ACCT, CFGITEM_ACCT_PPP, 1, &hAcct );
// If there are no accounts, then we didn’t find it

if( rc <= 0 )
return(0);
// Search until we run out of accounts or have a match

while(1)
{
// Get the data for this entry into CA
size = sizeof(CA);
rc = CfgEntryGetData( hAcct, &size, (UINT8 *)&CA );
if( rc <= 0 )
{
// This is an unexpected error – deref the handle and abort
C-26
CfgEntryDeRef( hAcct );
return(0);
}
// See if the username matches the search name. If so, return

// the referenced handle
if( !strcmp( name, CA.Username ) )
return( hAcct );
// Since we didn’t match, get the next entry. If there is no

// next entry, we’re done searching.
rc = CfgGetNextEntry( 0, hAcct, &hAcct );
if( rc <= 0 )
return(0);
}
}
C.4.5 Removing a PPP User Account

Removing a specific user account is done by finding the account and removing
the entry handle.
The following uses the AcctFind() function to find the target account.
void AcctDelete( char *name )
{
HANDLE hAcct;
// Find the account to delete
hAcct = AcctFind( name );
// If we found the account, remove it

if( hAcct )
{
CfgRemoveEntry( 0, hAcct );
printf(”Account removed\n”);
}
}

Appendix
AppendixDA
Hardware Abstraction Layer (HAL)
As discussed in the introduction, hardware devices are supported though a

Hardware Abstraction Layer. This section describes the HAL API.
This section is required only for system programmers who need low level ac-
cess to the hardware for configuration and monitoring. This API does not ap-
ply to sockets application programming.
Topic Page
D.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2

D.2 Low-Level Timer Driver (llTimer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
D.3 Low-Level Packet Driver (llPacket) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5
D.4 Low-Level Serial Port Driver (llSerial) . . . . . . . . . . . . . . . . . . . . . . . . . . D-10
D-1
Overview
D.1 Overview
The function of the HAL is to provide resources to the stack library functions
and allow them to operate independently of the current run–time environment.
The HAL contains the functionality required by the stack that depends directly
on the hardware in a particular environment.
D.1.1 HAL Function Types

The HAL is interspersed with two different types of functions; those that are
called from kernel layer (inside an llEnter() / llExit() pairing), and those that are
not. (For more information on the llEnter() and llExit() functions, see
section A.1.)
In order to distinguish kernel layer functions from application support func-

tions, both have been given a different naming conventions. Kernel layer func-
tions are named with an “ll” prefix, without a leading underscore, for example:
llPacketSend(), while application functions have an underscore, for example:
_llPacketInit().
D.1.2 External Calls from HAL Functions

Since HAL functions are called from the stack kernel, they are executing within
an llEnter() / llExit() pair. This means that these HAL functions can call the
stack API directly, but should not call normal application functions.
If a HAL function must call an external application function, or if it is going to

call a potentially blocking function, then it should first call llExit(). Then when
it has completed, it should call llEnter() before returning to the stack. It is im-
portant not to block while in an llEnter() / llExit() pair.
D-2
Low-Level Timer Driver (llTimer)
D.2 Low-Level Timer Driver (llTimer)
D.2.1 Synopsis
The stack code requires a very basic simple time function. It consists of two
parts: a function API, which can be called from the stack to get the current time,
and a “scheduler” which sends timer event notifications every 500ms.
D.2.2 Function Overview

Application Functions:
_llTimerOpen() Initialize Timer Environment
_llTimerClose() Shutdown Timer Environment
_llTimerServiceCheck() Check for timer activity
Kernel Layer Functions:

llTimerGetTime() Get the Current Time
llTimerGetStartTime() Get the Initial Startup Time
D.2.3 Low-Level Timer API Functions

The following functions are required.
_llTimerOpen Initialize Timer Environment
Syntax void _llTimerOpen( UINT32 ctime );

Description This function is called to initialize the timer environment, and to set the initial
time. The value of ctime is the number of seconds elapsed from a known refer-
ence. An initial value of zero is also acceptable. The stack software is only con-
cerned with relative time. Some modest case should be taken when setting this
value since the stack does not cope with the timer value wrapping. This occurs
every 136 years, or in 2116 if time is based off of Jan 1, 1980.
_llTimerClose Shutdown Timer Environment
Syntax void _llTimerClose();

Description This function is called when shutting down the system to shutdown and clean-
up the timer environment.
Hardware Abstraction Layer (HAL) D-3

Low-Level Timer Driver (llTimer)
_llTimerServiceCheck Check for Timer Activity
Syntax UINT32 _llTimerServiceCheck();
Return Value 0 No timer event

1 At least one half second has elapsed since the last time the function
returned 1
Description This function is called by the network scheduler to determine if there has been
timer activity since the last call. When called, the timer returns 1 if a half-sec-
ond has elapsed since the last event, and 0 otherwise. On a return of 1, the
event is cleared and the function will not return 1 for another half second. Multi-
ple half second events are not “queued up”.
llTimerGetTime Get Current Time in Seconds and Milliseconds
Syntax UINT32 llTimerGetTime( UINT32 *pMSFrac );
Description Returns the number of seconds that have elapsed since the timer driver was
started. If the pointer pMSFrac is non-zero, the function writes the fractional
seconds (in milliseconds) to this location (0 to 999).
Note: Although the stack does not require “real time”, take care not to simply
use a millisecond timer and divide by 1000 as the value will “wrap” every 50
days.
llTimerGetStartTime Get the Initial Startup Time
Syntax UINT32 llTimerGetStartTime();
Return Value Initial start time in seconds.
Description Returns the initial start time that was passed to _llTimerOpen().
D-4
Low-Level Packet Driver (llPacket)
D.3 Low-Level Packet Driver (llPacket)

D.3.1 Synopsis
The stack code requires a very basic packet function library. Note that although
the high level packet API is documented here, the HAL contains a generic
packet driver that implements this API. It is more efficient to use the standard
llPacket driver and provide a hardware specific mini-driver than to implement
the llPacket API from scratch.

_llPacketInit() Initialize Driver Environment and
Enumerate Devices
_llPacketShutdown Shutdown Driver Environment
_llPakcetServiceCheck() Check for packet activity
llPacketOpen() Open Driver and Bind Logical Ether Object
to Device Id
llPacketClose() Close Driver and Unbind Logical Ether
Object from Device Id
llPacketSetRxFilter() Set Packet Receive Filter
llPacketGetMacAddr() Get MAC address
llPacketGetMCastMax() Get the Maximum Number of Multicast
Addresses
llPacketGetMCast() Get Multicast Address List
llPacketSetMCast() Set Multicast Address List
llPacketService() Service a Queued Packet
llPacketGetBuffer() Get a Packet Buffer from the System
llPacketSend() Send a Packet
llPacketReturnBuffer() Return an Rx Buffer to the System
D.3.3 Low-Level Packet API Functions

The low level support layer must provide the following functions:
_llPacketInit Initialize Driver Environment and Enumerate Devices
Syntax uint _llPacketInit();

Return Value Returns the number of physical packet devices.
Description This function is called by NETCTRL initializes the system to use packets de-
vices of a specific type. It also enumerates all the physical devices in the sys-
tem, and returns a device count. The stack will then call the llPacketOpen()
function once for each physical device indicated.

_llPacketShutdown Shutdown Driver Environment
Syntax void _llPacketShutdown();

Description This function is called by NETCTRL to indicate a final shutdown of the packet
driver environment. When called, there should be no currently open packet
drivers, and _llPacketInit() will be called again before any call to llPacketO-
pen().
_llPacketServiceCheck Check for Ethernet Packet Activity
Syntax uint _llPacketServiceCheck();

Return Value Returns 1 if there are packets available, 0 if not.
Description This function is called by NETCTRL to check if packets are available from the
Ethernet device. In a polling system, this function is called continuously. In an
interrupt driven semaphore system, it is called when packet activity is indi-
cated to the scheduler and at half second timer intervals for “dead man” polling
checks.
llPacketOpen Open Driver and Bind Logical Ether Object to Device Id
Syntax uint llPacketOpen( uint dev, HANDLE hEther );

Return Value This function should return 1 on success, and 0 on failure.
Description Opens the low level packet driver specified by the one’s based index dev. The
maximum value of dev is the number of devices returned from the _llPacketI-
nit() function. When opening the device, the packet driver should bind the
physical index with the logical Ether object handle specified in hEther. This
handle is used in receive indications to the stack.
llPacketClose Close Driver and Unbind Logical Ether Object from Device Id
Syntax void llPacketClose( uint dev );

Description Closes the low level packet driver specified by the one’s based index dev. The
maximum value of dev is the number of devices returned from the _llPacketI-
nit() function. After this call, the packet driver should no longer attempt to indi-
cate received packets to the stack.
D-6
llPacketSetRxFilter Set Packet Receive Filter
Syntax void llPacketSetRxFilter( uint dev, uint filter );

Description Called to set the types of packets which should be received via the receive indi-
cation function. Each level of filter is inclusive of the previous level. They are:
ETH_PKTFLT_NOTHING No Packets
ETH_PKTFLT_DIRECT Only directed Ethernet
ETH_PKTFLT_BROADCAST Directed plus Ethernet Broadcast
ETH_PKTFLT_MULTICAST Directed, Broadcast, and selected
Ethernet Multicast
ETH_PKTFLT_ALLMULTICAST Directed, Broadcast, and all Multicast
ETH_PKTFLT_ALL All packets
llPacketGetMacAddr Get MAC address
Syntax void llPacketGetMacAddr( uint dev, UINT8 *pbData );

Description Copies the 6 byte MAC address of the physical device index dev into the sup-
plied data buffer.
llPacketGetMCastMax Get the Maximum Number of Multicast Addresses
Syntax uint llPacketGetMCastMax( uint dev );

Return Value The maximum number of 6 byte MAC addresses that can be supplied for
llPacketSetMCast().
Description Called to the maximum number of multicast addresses that can be supported
on the physical packet device.
llPacketGetMCast Get Multicast Address List
Syntax uint llPacketGetMCast( uint dev, uint maxaddr, UINT8 *pbAddr );

Return Value The number of 6 byte MAC addresses written to pbAddr.
Description Called to get the current list of multicast addresses installed on the physical
device. The max size of the list (supplied as an address count) is in maxaddr.
The list is a contiguous stream of 6 byte addresses pointed to by pbAddr. The
function returns the number of addresses in the list supplied.

llPacketSetMCast Set Multicast Address List
Syntax void llPacketSetMCast( uint dev, uint addrcnt, UINT8 *pbAddr );

Description Called to install a list of multicast addresses on the physical device. The size
of the list (supplied as an address count) is in addrcnt. The list is a contiguous
stream of 6 byte addresses pointed to by pbAddr. The new list pre-empts any
previously installed list, and thus an address count of ZERO removes all multi-
cast addresses.
llPacketService Service a Queued Packet
Syntax void llPacketService();

Description This function is called to inform the driver that it may now indicate any queued
packet buffers to the Ether object corresponding to the physical ingress de-
vice. Packet drivers must internally queue their own packets. Queued packets
cause events to be sent to the scheduler which will in turn call this function.
Packets are passed to the Ether object via EtherRxPacket().
llPacketGetBuffer Get a Packet Buffer from the System
Syntax UINT8 *llPacketGetBuffer( uint size );

Description Called to get a packet buffer from the system, which will eventually be sent via
llPacketSend(), or returned to the packet driver via llPacketReturnBuffer().
Buffering is done in this fashion so packet drivers that use their own buffer
pools can support passing buffer ownership without copying data.
Note: This function should be able to handle requests for buffers up to 1536
bytes.
llPacketSend Send a Packet
Syntax void llPacketSend( uint dev, UINT8 *pb, uint offset, uint size, HANDLE hFrag
);
Description Called to send a packet out the physical packet device indicated by dev. The
size of the valid data is in size. The byte offset to the valid data in the supplied
buffer is in offset. Once the packet has been sent, the memory is returned by
calling FragFree( hFrag ), where hFrag is the handle to the packet fragment
supplied in the calling parameters.
Note: Although it is normally illegal to call any stack function from an interrupt
routine, calling FragFree() at interrupt time is allowed.
D-8
llPacketReturnBuffer Return an Rx Buffer to the System
Syntax void llPacketReturnBuffer( UINT8 *bAddr );
Description Called to return a packet buffer to the system, which was previously obtained
from a call to llPacketGetBuffer(). This is done so packet drivers that use their
own buffer pools can support passing buffer ownership without copying buffer
data.

Low-Level Serial Port Driver (llSerial)
D.4 Low-Level Serial Port Driver (llSerial)
D.4.1 Synopsis
In the current directory structure, the serial port driver (llSerial) may or may not
be part of the HAL directory (as it is an optional component). However, it is part
of the HAL architecture, and should be programmed using the same guide-
lines used for the llTimer and llPacket drivers.

_llSerialInit() Initialize Driver Environment and
Enumerate Devices
_llSerialShutdown Shutdown Driver Environment
_llSerialServiceCheck() Check for packet activity

llSerialOpenCharmode() Open Driver in Character Mode
llSerialCloseCharmode() Close Driver Character Mode
llSerialOpenHDLC() Open Driver in HDLC Mode
llSerialCloseHDLC() Close Driver HDLC Mode
llSerialConfig() Set Serial Port Configuration
llSerialService() Service a Queued HDLC Buffer
llSerialGetBuffer() Get a Serial Buffer from the System
llSerialSend() Send a Serial Buffer
llSerialReturnBuffer() Return an Serial Buffer to the System
D.4.3 Low-Level Serial API Functions

The low level support layer must provide the following functions:
_llSerialInit Initialize Driver Environment and Enumerate Devices
Syntax uint _llSerialInit();
Return Value Returns the number of physical serial devices.
Description This function is called by NETCTRL initializes the system to use the serial port.
It also enumerates all the physical devices in the system, and returns a device
count. The stack will then call the llSerialOpenCharmode() and/or llSerialO-
penHDLC() functions for each physical device it requires.
D-10
_llSerialShutdown Shutdown Driver Environment
Syntax void _llSerialShutdown();
Description This function is called by NETCTRL to indicate a final shutdown of the serial
driver environment. When called, there should be no currently open serial driv-
ers, and _llSerialInit() will be called again before any call to llSerialOpenChar-
mode() or llSerialOpenHDLC().
_llSerialServiceCheck Check for Serial Port Activity
Syntax uint _llSerialServiceCheck();
Return Value Returns 1 if there are HDLC input buffers available, 0 if not.
Description This function is called by NETCTRL and has two functions.
First, if there are characters for the “character mode” device waiting, they are
passed into the user application by calling character mode input callback func-
tion passed to llSerialOpenCharmode().
Second, if the device has been opened in HDLC mode, this function returns
1 if there are HDLC buffers pending. In this case, no additional “character
mode” input is received, however some queue character mode data may still
be passed to the callback function.
In a polling system, this function is called continuously. In an interrupt driven

semaphore system, it is called when packet activity is indicated to the schedul-
er and at half second timer intervals for “dead man” polling checks.
llSerialOpenCharmode Open Driver in Character Mode
Syntax uint llSerialOpenCharmode( uint dev, void (*pCharmodeRxCb)( char c ) );
Description Opens the low level serial driver specified by the one’s based index dev in
character mode. The maximum value of dev is the number of devices returned
from the _llSerialInit() function.
Character mode input simply passes all characters received at the port to the
character mode receiver.

When opening the device, the driver should save the callback function pointer
pCharmodeRxCb. This function should be called for each character received
while in character mode. When the driver is opened in HDLC mode, no charac-
ter mode input is received. When the HDLC mode is closed, the character
mode becomes active again.
llSerialCloseCharmode Close Driver Character Mode
Syntax void llSerialCloseCharmode( uint dev );

Description Closes the “character mode” of the low level serial driver specified by the one’s
based index dev. Once called, the serial driver should not attempt to call any
character mode callback function.
llSerialOpenHDLC Open Driver in HDLC Mode
Syntax uint llSerialOpenHDLC( uint dev, HANDLE hHDLC );

Description Opens the low level serial driver specified by the one’s based index dev in
HDLC mode. The maximum value of dev is the number of devices returned
from the _llSerialInit() function.
HDLC mode input builds up buffers of one HDLC frame each, and passes them
to the HDLC object when the llSerialService() function is called. Note that the
HDLC flag character (0x7E) should always be removed from the input buffer,
but no further processing is required.
When opening the device, the driver should bind the physical index with the
logical HDLC object handle specified in hHDLC. This handle is used in receive
indications to the stack.
llSerialCloseHDLC Close Driver HDLC Mode
Syntax void llSerialCloseHDLC( uint dev );

Description Closes the “HDLC mode” of the low level serial driver specified by the one’s
based index dev. Once called, the serial driver should not attempt to indicate
HDLC frame buffers to the scheduler or stack. Any queued buffers should be
flushed.
D-12
llSerialConfig Configure Serial Port
Syntax void llSerialConfig( uint dev, uint baud, uint mode, uint flowctrl );
Description This function is called by NETCTRL to configure the serial port attributes for
the indicated device.
The value of baud is the baud rate, and must be an even denominator of
230400, up to a max baud rate of 230400. For example: 230400, 115200,
57600, 38400, 28800, and 19200 are all legal values, while 56000 it not.
The value of mode indicates the mode of the device including data bits, parity,
and stop bits. Only the two most commonly used modes are defined:
HAL_SERIAL_MODE_8N1 8 Data Bits, No Parity, 1 Stop Bit
HAL_SERIAL_MODE_7E1 7 Data Bits, Even Parity, 1 Stop Bit
The value of flowctrl indicates the desired flow control operation. Legal values
for this parameter are:
HAL_SERIAL_FLOWCTRL_NONE No Flow Control
HAL_SERIAL_FLOWCTRL_HARDWARE Hardware Flow Control
This function can be called before or after the device is opened.
llSerialService Service a Queued HDLC Buffer
Syntax void llSerialService();
Description This function is called to inform the driver that it may now indicate any queued
HDLC buffers to the HDLC object corresponding to the physical ingress de-
vice. Serial drivers must internally queue their own buffers. Queued buffers
cause events to be sent to the scheduler which will in turn call this function.
HDLC buffers are passed to the HDLC object via HDLCInput().

llSerialGetBuffer Get a Serial Buffer from the System
Syntax UINT8 *llSerialGetBuffer();
Description Called to get a serial buffer from the system, which will eventually be sent via
llSerialSend(), or returned to the driver via llSerialReturnBuffer(). Buffering is
done in this fashion so drivers that use their own buffer pools can support pass-
ing buffer ownership without copying data.
All buffers are of a fixed size. They have a usable size in bytes indicated by the
#define: HAL_SERIAL_BUFFERSIZE (currently 3052 bytes).
llSerialSend Send a Serial Buffer
Syntax void llSerialSend( uint dev, UINT8 *pb, uint offset, uint size );
Description Called to send a serial buffer out the physical serial device indicated by dev.
The size of the valid data is in size. The byte offset to the valid data in the sup-
plied buffer is in offset. Once the buffer has been sent, the memory is returned
internally to the serial port’s free queue. Only buffers allocated via llSerialGet-
Buffer() can be used in this call.
llSerialReturnBuffer Return a Serial Buffer to the System
Syntax void llSerialReturnBuffer( UINT8 *bAddr );
Description Called to return a serial buffer to the system, which was previously obtained
from a call to llSerialGetBuffer(). This is done so drivers that use their own buff-
er pools can support passing buffer ownership without copying buffer data.
D-14
Appendix
AppendixEA
Web Programming with the HTTP Server
The easiest way for a user to get information from an embedded network de-
vice is through the web server. The HTTP server pulls files from the embedded
file system (EFS) that is included in the NDK software package’s OS adapta-
tion layer. These files can be compiled into the DSP application, located on a
network file system, a memory-based file system, or on a physical disk inter-
faced to the DSP. The NDK HTTP server accesses files through the EFS ap-
plication interface, which can be ported to any file system desired. The server
currently supports the HTTP/1.0 protocol.
Common Gateway Interface (CGI) programs execute on a web server and

process input from a user. They are very useful as interfaces to services run-
ning on the device. Writing CGI programs for the NDK is relatively simple and
only requires a few specific functions. The CGI interface is limited to HTTP
POST requests; GET requests are not supported by CGI.
The CGI program is built from a single C callable entrypoint (or CGI function).
Each CGI function is called on its own independent task thread. The task
threads are created with a priority of OS_TASKPRINORM and a stack size of
OS_TASKSTKHIGH. Note that consecutive calls to the same CGI function will
not be on the same task thread. Thus CGI functions can not share sockets from
one call to the next. In general, there is no persistent data in a CGI function.
Topic Page
E.1 Adding Web Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2

E.2 Writing CGI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-4
E.3 CGI Function Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-7
E.4 HTTP Server Exported Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-11
E-1
Adding WEB Content
E.1 Adding WEB Content
E.1.1 Operation
As previously mentioned, the HTTP server allows access to files using the em-
bedded file system (EFS) API. The default instantiation of this API is a RAM
based file system that resides in the OS adaptation layer. This OS adaptation
layer allows the HTTP server to work on any file storage device contained in
the system.
The default RAM based file system is built up mainly from a standard file i/o
API, with the addition of some private functions. These private functions allow
files to be created and destroyed by passing in memory pointers to where they
are stored. These functions are fully documented in section 2.6.
E.1.2 Converting Standard HTML Files

The example code supplied with the NDK adds WEB pages by converting
them from binary HTML files into data arrays declared in C. An MsDos utility
binsrc is supplied to allow conversion of files to a C array.
The calling format for binsrc is:
binsrc <input file name> <output file name> <identifier>
Parameters:
input file name File to be converted
output file name Name for file containing C data
representation of the input file name
identifier C name for data
For example, to convert an HTML file default.htm, for use by EFS, the follow-
ing command could be executed from the Windows command window:
binsrc default.htm default.c DEFAULT
The file default.c would contain the following:
#define DEFAULT_SIZE 1610
unsigned char DEFAULT[] = {0x3C, 0x21, 0x64, 0x6F, 0x63, 0x74, 0x79, 0x70, 0x65,
0x20, 0x68, 0x74, …
E.1.3 Declaring HTML Files to EFS

Once the HTML file is converted to a memory image, the “file” is declared to
the EFS file system by calling the function efs_createfile(). All the HTML files
are typically created at the same time, during initialization, and before the
HTTP server is actually invoked. In the example code, there are two functions
used, AddWebFiles() and RemoveWebFiles(). These functions include all the
code necessary to initialize and cleanup the EFS file environment.
E-2
Adding WEB Content
An example implementation of AddWebFiles() is shown below. Note the addi-

tion of two more file creation calls. The first call to efs_createfile() creates the
file we declared in default.c as converted from the file default.htm. The second
call shows an alternate method of creating files. In this case, the HTML for the
file was typed directly into the source code. The third call creates a CGI file that
is actually a C function entrypoint. When a post is attempted to sample.cgi,
the function cgiSample() is called.
// Include our externally converted pages

#pragma DATA_SECTION(DEFAULT, ”HTMLDATA”);
#include ”default.c”
// Declare our 404.htm file content

static const char htm404[] =
”<html><body><h1>HTTP/1.0 404 Object Not Found</h1></body></html>”;
// Delare our CGI function entry point

static int cgiSample(int htmlSock, int ContentLength );
// Our function to initialize EFS with our WEB files

void AddWebFiles(void)
{
efs_createfile(”index.html”, DEFAULT_SIZE, DEFAULT);
efs_createfile(”404.htm”, strlen(htm404), (UINT8 *)htm404);
efs_createfile(”sample.cgi”, 0, (UINT8 *)cgiSample);
}
One the above code is run, the EFS system is ready for the HTTP server to
serve up the content. Note the inclusion of the #pragma to place the converted
WEB page into a memory section named HTMLDATA. This allows the page
to be place out of the way by specifying the section’s location in the linker com-
mand file.
E.1.4 Cleaning up HTML Files
Since the EFS system uses memory records to simulate file content from static
data, the system should be flushed or cleaned when the shutting down or re-
booting. In the example code, the function RemoveWebFiles() is called when
the EFS files are no longer required.
An implementation of RemoveWebFiles() that corresponds to the

AddWebFiles() function shown above would be as follows:
void RemoveWebFiles(void)
{
efs_destroyfile(”sample.cgi”);
efs_destroyfile(”404.htm”);
efs_destroyfile(”index.html”);
}
Web Programming with the HTTP Server E-3

Writing CGI Functions
E.2 Writing CGI Functions
E.2.1 Adding Functions to the EFS

CGI programs must be in the EFS for the HTTP server to see them. An exam-
ple of this was shown in the previous section by adding an entry for the file
sample.cgi that translated into the C function cgiSample(). Whenever a
POST is made to the file sample.cgi, the cgiSample() function is called.
E.2.2 CGI Function Declaration

The standard declaration for a CGI function in C is:
Syntax static int cgiSample(int htmlSock, int ContentLength );
Parameter(s) htmlSock The network socket on which the HTTP POST was issued
ContentLength The size of the POST content waiting on socket htmlSock
Return Value All CGI functions return one if the input socket is left open, and zero if it is
closed or transferred to another thread.
Description This function reads in the HTTP POST content from the socket htmlSock, and
writes out an HTML reply based on the function and the form content read. The
size of the form content is specified by ContentLength.The CGI function must
decide whether or not to close the socket on which the POST arrived. By de-
fault, the socket is normally left open, but in some cases may need to be
closed. It is also possible that the CGI function may wish to take control of the
socket an close it at a later point in time. Note in this latter case, the socket
would be transferred to another thread, using the fdGetFileHandle() and File-
HandleGetFd() function calls.
The function must return either “0” or “1” to indicate the status of the socket
htmlSock. If the socket is closed or passed on to another task, the function re-
turns “0”. If the socket is still active, the function returns “1”.
When there is any doubt whether or not to close the socket, the socket is typi-
cally left open for the HTTP server to close when appropriate.
E.2.3 Parsing CGI Form Data

The first job a CGI function will most likely perform is to read the POST form
data from the socket. This can be done easily since the two calling arguments
to the function are the socket to read and the size of the data. In order to remain
reentrant, the CGI function should allocate its memory buffer to hold the form
data.
E-4
After reading in the data from the socket, each form entry can be parsed from
the from by using the supplied example function: cgiParseVars(). The formal
definition of the function is shown below.
Note that this function replaces parsePostVars(), a similar function that was
included in earlier versions of the Network Developer’s Kit. The parsePost-
Vars() function was not re-entrant, and has been purged from the NDK re-
lease. The source code to cgiParseVars() is included in the example applica-
tion code shipped with the NDK.
cgiParseVars Parse CGI Form POST Input
Syntax char *cgiParseVars(char PostInput[], int *pParseIndex );
Parameter(s) PostInput[] Pointer to the form data read in from the HTTP request socket
pParseIndex Pointer to an int holding the current parse position (initially
zero)
Return Value A pointer to a NULL terminated string within PostInput[], signifying the name
or value of a form entry. Also updates the value pointed to by pParseIndex.
Description Reads input from a CGI POST operation pointed to by PostInput[] at an offset
pointed to by pParseIndex and returns in sequence a pointer the name and
then the value of each post entry. This function modifies the data in PostInput[].
It also updates the current parsing position in the variable pParseIndex. The
parse index must be set to 0 on initial call.On the initial call to this function, the
integer value pointed to by pParseIndex should contain zero.
On reaching the end of the input, the function sets pParseIndex to –1. If called
again, the function will return a NULL pointer and leave the value of pParseIn-
dex unchanged.
E.2.4 Sending HTTP/HTML Replies

After parsing the CGI POST form data, the CGI function should send some sort
of reply to the requesting client. The reply takes the form of an HTTP message
signifying success or error, potentially followed by HTML data.
The HTTP server supplies several functions to aid in building and sending both
HTTP data over the socket. In addition, the example applications contain vari-
ous MACROS than can also help in initially developing a CGI function. The
HTTP functions are fully described at the end of this section, but the main reply
functions are usually one of the following:
Web Programming With the HTTP Server E-5

httpSendFullResponse() Send full HTTP response, including a sta-

tus code and an HTML file
or
httpSendStatusLine() Send HTTP status response, including a

status code and content type
httpSendClientStr() Used after httpSendStatusLine() to send
content data
As an example of using these function, consider the two response MACROS

included in hpptif.h.
//
// Common error responses
//
#define http404(Sock) httpSendFullResponse(Sock, HTTP_NOT_FOUND, “404.htm”)
#define http501(Sock) httpSendStatusLine(Sock, HTTP_NOT_IMPLEMENTED, \
(char *)CONTENT_TYPE_HTML)
The first MACRO, http404() is used to send a “file not found” response to the
client. This includes the HTML text defined for the 404 error. An example of
creating a 404.htm file appears earlier in this appendix.
The second MACRO, http501() is used to send a 501 – Not Implemented error
to the HTTP client. Here, no additional data is sent.
Under normal circumstances, the CGI function will use the httpSendStatus-
Line() function to send an OK message to the client, followed by the httpSend-
ClientStr() function to send client data in the form of a NULL terminated string.
Note that an additional carriage return and line feed are required to separate
the header from the HTML data.
For example, the following code sends a quick “Success” message.
// Send response status

httpSendStatusLine( Sock, HTTP_OK, CONTENT_TYPE_HTML );
// Terminate the response header

httpSendClientStr( Sock, CRLF );
// Send the Success Message

httpSendClientStr( Sock, ”<html><h1>Success!</h1><br></html>”);
Note that the httpSendClientStr() function replaces the httpSendClientData()

function from earlier releases of the NDK. For data sizes that can be repre-
sented by an integer, client data can also be sent simply by calling the sockets
send() function.
E-6
CGI Function Example
E.3 CGI Function Example

As an example of using all the concepts described so far, consider a simple
example. Assume an applications programmer wishes to create a WEB form
that inputs and processes user data.
E.3.1 Create the HTML Page

The HTML page can be created with an HTML editor, or by hand. For this ex-
ample, we have an HTML page that contains a simple CGI form. The contents
of the example page, default.htm are show below.
<html>
<head><title>CGI Sample</title></head>
<body>
<h1>CGI Sample Form</h1>
<hr WIDTH=”100%”>
Fill in the form fields and hit ’Submit’.
<form name=”my_form” method=”POST” action=”sample.cgi”>
Name: <input type=”text” name=”name”><br>
I dislike spam: <input type=”checkbox” name=”spam” value=”no!”><br>
Favorite Pizza:
<input type=”radio” name=”pizza” value=”pepperoni”> Pepperoni
<input type=”radio” name=”pizza” value=”sausage”> Sausage
<input type=”radio” name=”pizza” value=”cheese” checked> Cheese
<input type=”radio” name=”pizza” value=”other”> Other
<br>
Favorite Color: <select name=”color”>
<option value=”red”> Red
<option value=”green”> Green
<option value=”blue”> Blue
<option value=”yellow”> Yellow
<option value=”cyan”> Cyan
<option value=”magenta”> Magenta
<option value=”black”> Black
<option value=”while”> White
</select>
</p>
<input type=”submit”> <input type=”reset”>
</form>
</body>
</html>
The next step we perform is to convert this HTML file to C source file. We did
this back in section E.1.2. Once we have the page in C source code form, we
can add it to our program.

E.3.2 Create the Base WEBPAGE Source File

Once the HTML pages are ready in source form, the main WEBPAGE.C
source file is created. This file will perform all the necessary WEB processing
in the example. The basic source code declares the HTML pages as ”files” to
the EFS file system. To do this, it exports two functions called from the main
network initialization routine, AddWebFiles() and RemoveWebFiles(). Note
that a CGI function is also declared to handle processing of the CGI form con-
tained on the WEB page, called sample.cgi.
The source code as defined so far is shown below.

#include <netmain.h>
#include ”cgiparse.h” \\ Our Private CGI Parser. (See section E.2.3)
#pragma DATA_SECTION(DEFAULT, ”OBJMEM”);
#include ”webdata\default.c”
static const char htm404[]=
”<html><body><h1>HTTP/1.0 404 Object Not Found</h1></body></html>”;
static int cgiSample(int htmlSock, int ContentLength ); \\ Our CGI Function
void AddWebFiles(void)
{
efs_createfile(”index.html”, DEFAULT_SIZE, DEFAULT);
efs_createfile(”sample.cgi”, 0, (UINT8*)cgiSample);
efs_createfile(”404.htm”, strlen(htm404), (UINT8 *)htm404);
}
void RemoveWebFiles(void)}
{
efs_destroyfile(”404.htm”);
efs_destroyfile(”sample.cgi”);
efs_destroyfile(”index.html”);
}
E.3.3 Create CGI Function

All that is left is to create the CGI function. The CGI function performs the fol-
lowing steps:
1) Read in request data
2) Parse request using cgiParseVars(), or a similar function.
3) Process request in some meaningful way. Make sure the inputs are valid
before processing them to avoid crashes or security violations. This may
involve querying or updating the configuration, making a network request,
or updating a file.
4) Send a response. Keep in mind the first line of the response should indi-
cate whether the request was successful or not.
E-8
5) Send appropriate headers.

6) Send the response data. This could be a file or data generated by the CGI
program.
In addition to the commonly used strings defined in section E.4.1, in the exam-
ple function we define some additional strings that are used more than once.
There is also a MACRO to help disguise calls to httpSendClientStr(), and make
the source code a little more readable. These are shown below:
// We use the strings more than once in cgiSample()
static const char *tablefmt = ”<tr><td>%s</td><td>%s</td></tr>\r\n”;
static const char *divider = ”<hr WIDTH=\”100%\”><br>\r\n”
// Page Creation Macro
#define html(str) httpSendClientStr(htmlSock, (char *)str)
Last, the main body of the CGI function. Note that this example is also included
in the example application code in a slightly different form:
static int cgiSample(int htmlSock, int ContentLength )
{
char *name = 0, *spam = 0, *pizza = 0, *color = 0;
char *buffer, *key, *value;
int len;
int parseIndex;
char htmlbuf[MAX_RESPONSE_SIZE];
// 1. Read in the request data
// First, allocate a buffer for the request
buffer = (char*) mmBulkAlloc( ContentLength + 1 );
if ( !buffer )
goto ERROR;
// Now read the data from the client
len = recv( htmlSock, buffer, ContentLength, MSG_WAITALL );
if ( len < 1 )
goto ERROR;
// 2. Parse request using cgiParseVars(), or a similar function
// Setup to parse the post data
parseIndex = 0;
buffer[ContentLength] = ’\0’;
// Process request variables until there are none left
do
{
key = cgiParseVars( buffer, &parseIndex );
value = cgiParseVars( buffer, &parseIndex );
if( !strcmp(”name”, key) )
name = value;
else if( !strcmp(”pizza”, key) )
pizza = value;
else if( !strcmp(”spam”, key) )
spam = value;
else if( !strcmp(”color”, key) )
color = value;
} while ( parseIndex != –1 );

// 3. Process request in some meaningful way . . .

// (OK, we really don’t do this here.)
// 4. Send a response. Keep in mind the first line of the
// response should indicate whether the request was
// successful or not.
httpSendStatusLine(htmlSock, HTTP_OK, CONTENT_TYPE_HTML);
// 5. Send appropriate headers
// No more header data to send – CRLF terminates header
html( CRLF );
// 6. Send the response data
//
// Build our HTML response
// Here we’ll just echo back the input we received
// to an HTML table.
//
html(”<html><body text=#000000 bgcolor=#ffffff>\r\n”);
html(”<h1>Form Information</h1>”);
html(divider);
html(”<table border cellspacing=0 cellpadding=5>\r\n”);
if( name )
{
sprintf( htmlbuf, tablefmt, ”Name:”, name );
html( htmlbuf );
}
if( spam )
{
sprintf( htmlbuf, tablefmt, ”Likes Spam:”, spam );
html( htmlbuf );
}
if( pizza )
{
sprintf( htmlbuf, tablefmt, ”Favorite Pizza:”, pizza );
html( htmlbuf );
}
if( color )
{
sprintf( htmlbuf, tablefmt, ”Favorite Color:”, color );
html( htmlbuf );
}
html(”</table><br>\r\n”);
html(divider);
html(”<a href=index.html>Return to Main Page</a><br><br>\r\n”);
html(”</body></html>\r\n”);
ERROR:
if( buffer )
mmBulkFree( buffer );
return( 1 );
}
E-10
HTTP Sever Exported Functions
E.4 HTTP Sever Exported Functions
The HTTP server module exports several functions and strings to aid in the
creation of a CGI function. This section contains the formal specification for
these functions. The first part of this appendix describes how to use these func-
tions in creating a HTTP CGI function in C.
E.4.1 Commonly Used Strings
To aid in the creation of the response data, some commonly used HTML
strings can be defined. Some of these are already defined in the HTTPIF.H file.
These include the following (note that all entries except the first three include
a trailing space character.):
Global Name String Value

DEFAULT_NAME ”index.html”
CRLF ”\r\n”
SPACE ” ”
HTTP_VER ”HTTP/1.0 ”
CONTENT_LENGTH ”Content-length: ”
CONTENT_TYPE ”Content–type: ”
CONTENT_TYPE_APPLET ”application/octet-stream ”
CONTENT_TYPE_AU ”audio/au”
CONTENT_TYPE_DOC ”application/msword ”
CONTENT_TYPE_GIF ”image/gif ”
CONTENT_TYPE_HTML ”text/html ”
CONTENT_TYPE_JPG ”image/jpeg ”
CONTENT_TYPE_MPEG ”video/mpeg ”
CONTENT_TYPE_PDF ”application/pdf ”
CONTENT_TYPE_WAV ”audio/wav ”
CONTENT_TYPE_ZIP ”application/zip ”
E.4.2 Function Overview
The basic HTTP Server exported functions are as follows:
httpSendStatusLine() Send the status of this request to the client

httpSendClientStr() Send NULL terminated string data to client
httpSendFullResponse() Send a full formatted response to the client

HTTP Sever Exported Functions
E.4.3 HTTP Server Exported API Functions
httpSendStatusLine Send the Status of this Request to the Client
Syntax void httpSendStatusLine( int Sock, int StatusCode, char *ContentType );

Parameter(s) Sock Socket on which to send
StatusCode HTTP status code of the request
ContentType HTTP type string of the response
Description Sends a formatted response message to Sock with the given status code and
content type. The value of ContentType can be NULL if no ContentType is re-
quired.
The status code and content type should match HTTP standard definitions.
Some content type strings are listed in E.4.1. The pre-defined status codes in-
clude:
HTTP_OK (200)
HTTP_NO_CONTENT (204)
HTTP_NOT_FOUND (404)
HTTP_NOT_IMPLEMENTED (501)
httpSendClientStr Send NULL Terminated String Data to Client
Syntax void httpSendClientStr( int Sock, char *Response );

Response Pointer to NULL terminated string
Description This function sends the indicated NULL terminated response string to the indi-
cated client socket. In other words, it calls strlen() and send()
httpSendFullResponse Send a Full Formatted Response to the Client
Syntax void httpSendFullResponse( int Sock, int StatusCode, char *RequestedFile );

StatusCode HTTP status code of the request
RequestedFile Pointer to filename of file to include in body
Description Sends a full formatted response message to Sock, including the file indicated
by the filename pointed to by RequestedFile. The status code for this call is
usually HTTP_OK, but can also be HTTP_NOT_FOUND when sending the file
“404.HTM”.
E-12
Index
Index
CfgEntrySetData() 4-17
A CfgExecute() 4-7
accept() 3-14 CfgFree() 4-7
CfgGetDefault() 4-8
B CfgGetEntry() 4-8
CfgGetEntryCnt() 4-9
bind() 3-15 CfgGetImmediate() 4-9
BindFree() A-32 CfgGetNextEntry() 4-10
BindGetFirst() A-33 CFGITEM_ACCT_PPP 4-31
BindGetIF() A-33 CFGITEM_DHCP_DOMAINNAMESERVER 4-32
BindGetIP() A-33 CFGITEM_DHCP_HOSTNAME 4-32
BindGetNext() A-33 CFGITEM_IP_ICMPDOREDIRECT 4-34
BindNew() A-32 CFGITEM_IP_ICMPTTL 4-34
CFGITEM_IP_ICMPTTLECHO 4-34
C CFGITEM_IP_IPFORWARDING 4-34
CFGITEM_IP_IPINDEXSTART 4-34
CFG_ADDMODE_DUPLICATE 4-6 CFGITEM_IP_IPNATENABLE 4-34
CFG_ADDMODE_NOSAVE 4-6 CFGITEM_IP_IPREASMMAXSIZE 4-34
CFG_ADDMODE_UNIQUE 4-6 CFGITEM_IP_IPREASMMAXTIME 4-34
CFG_CLIENTSTATUS_INVALID 4-31 CFGITEM_IP_PIPEBUFMAX 4-35
CFG_CLIENTSTATUS_PENDING 4-30 CFGITEM_IP_PIPEMINRX 4-35
CFG_CLIENTSTATUS_STATIC 4-31 CFGITEM_IP_PIPEMINTX 4-35
CFG_CLIENTSTATUS_VALID 4-30 CFGITEM_IP_PIPETIMEIO 4-35
CFG_CLIENTTYPE_DYNAMIC 4-30 CFGITEM_IP_RTARPDOWNTIME 4-34
CFG_CLIENTTYPE_STATIC 4-30 CFGITEM_IP_RTCADVLIFE 4-34
CFG_DOMAIN_MAX 4-28 CFGITEM_IP_RTCADVPREF 4-34
CFG_HOSTNAME_MAX 4-30 CFGITEM_IP_RTCADVTIME 4-34
CFG_NETTYPE_DHCPS 4-28 CFGITEM_IP_RTCENABLEDEBUG 4-34
CFG_NETTYPE_DYNAMIC 4-28 CFGITEM_IP_RTCLONETIMEOUT 4-34
CFG_NETTYPE_VIRTUAL 4-28 CFGITEM_IP_RTDEFAULTMTU 4-34
CfgAddEntry() 4-5 CFGITEM_IP_RTKEEPALIVETIME 4-34
CfgEntryDeRef() 4-15 CFGITEM_IP_SOCKBUFMAX 4-34
CfgEntryGetData() 4-16 CFGITEM_IP_SOCKMAXCONNECT 4-34
CfgEntryInfo() 4-16 CFGITEM_IP_SOCKMINRX 4-34
CfgEntryRef() 4-17 CFGITEM_IP_SOCKMINTX 4-34
Index-1
Index
CFGITEM_IP_SOCKTIMECONNECT 4-34 CI_SERVICE_DNSSERVER 4-27

CFGITEM_IP_SOCKTIMEIO 4-34 CI_SERVICE_HTTP 4-27
CFGITEM_IP_SOCKTOSDEFAULT 4-34 CI_SERVICE_NAT 4-27
CFGITEM_IP_SOCKTTLDEFAULT 4-34 CI_SERVICE_TELNET 4-27
CFGITEM_IP_STACKMAX 4-35 ci_srvargs 4-24
CFGITEM_OS_DBGABORTLEVEL 4-33 CIS_FLG_CALLBYIP 4-25
CFGITEM_OS_DBGPRINTLEVEL 4-33 CIS_FLG_IFIDXVALID 4-25
CFGITEM_OS_TASKPRIHIGH 4-33 CIS_FLG_RESOLVEIP 4-25
CFGITEM_OS_TASKPRIKERN 4-33 CIS_FLG_RESTARTIPTERM 4-25
CFGITEM_OS_TASKPRILOW 4-33 CIS_SRV_STATUS_DISABLED 4-25
CFGITEM_OS_TASKPRINORM 4-33 CIS_SRV_STATUS_ENABLED 4-25
CFGITEM_OS_TASKSTKHIGH 4-33 CIS_SRV_STATUS_FAILED 4-25
CFGITEM_OS_TASKSTKLOW 4-33 CIS_SRV_STATUS_IPTERM 4-25
CFGITEM_OS_TASKSTKNORM 4-33 CIS_SRV_STATUS_WAIT 4-25
CFGITEM_SERVICE_DHCPCLIENT 4-24 CISARGS 4-24
CFGITEM_SERVICE_DHCPSERVER 4-24 close(). See fdClose(); FileHandleClose()
CFGITEM_SERVICE_DNSSERVER 4-24 Configuration Entry Functions 4-15
CFGITEM_SERVICE_HTTP 4-24 Configuration Functions 4-5
CFGITEM_SERVICE_NAT 4-24 connect() 3-15
CFGITEM_SERVICE_TELNET 4-24
CfgLoad() 4-11
CfgNew() 4-12
D
CfgRemoveEntry() 4-12 DBG_ERROR 2-3, 2-16
CfgSave() 4-13 DBG_INFO 2-3, 2-16
CfgSetDefault() 4-13 DBG_NONE 2-3, 2-16
CfgSetExecuteOrder() 4-14 DBG_WARN 2-3, 2-16
CfgSetService() 4-14 DbgPrintf() 2-15
CFGTAG_ACCT 4-31 DHCP Server Service 6-8
CFGTAG_CLIENT 4-30 DHCPClose() 6-13
CFGTAG_IP 4-33 DHCPOpen() 6-13
CFGTAG_IPNET 4-27 DHCPS Parameter Structure 6-8
CFGTAG_OS 4-33 DHCPS_FLG_LOCALDNS 6-8
CFGTAG_ROUTE 4-29 DHCPS_FLG_LOCALDOMAIN 6-8
CFGTAG_SERVICE 4-23 DHCPSClose() 6-10
CFGTAG_SYSINFO 4-32 DHCPSOpen() 6-10
CGI Function E-4 DNS Server Parameter Structure 6-16
cgiParseVars() E-5 DNS Server Service 6-16
CI_CLIENT 4-30 DNSGetHostByAddr() 5-9
CI_IPNET 4-28 DNSGetHostByName() 5-9
CI_ROUTE 4-29 DNSGetHostname() 5-8
CI_SERVICE_DHCPC 4-27 DNSServerClose() 6-17
CI_SERVICE_DHCPS 4-27 DNSServerOpen() 6-17
Index-2
Index
File Handle Functions 3-9

E File IO 2-17
efs_createfile() 2-18 FileHandleClose() 3-9
efs_destroyfile() 2-18 FileHandleGetFd() 3-10
efs_fclose() 2-20 fopen(). See efs_fopen()
efs_feof 2-20 FragCopy() A-17
efs_fopen() 2-20 FragFree() A-17
efs_fread() 2-21 FragGetAux1() A-17
efs_fseek() 2-21 FragGetAux2() A-17
efs_ftell() 2-21 FragGetBufParams() A-18
efs_fwrite() 2-22 FragGetNext() A-18
efs_getfilesize() 2-19 FragGetPrev() A-18
efs_loadfunction() 2-19 FragNewAlloc() A-16
efs_rewind 2-22 FragNewWrap() A-16
errno. See fdError() FragSetAux1() A-18
EtherAddMCast() A-30 FragSetAux2() A-19
EtherClearMCast() A-31 FragSetBufParams() A-19
EtherDelMCast() A-30 FragSetNext() A-19
EtherFree() A-29 FragSetPrev() A-19
EtherGetLLABCast() A-30 fread(). See efs_fread()
EtherGetLLADirect() A-30 frewind(). See efs_frewind()
fseek(). See efs_fseek()
EtherGetPktFilter() A-31
ftell(). See efs_ftell()
EtherNew() A-29
Full Duplex Pipes 3-34
EtherRxPacket() A-31
fwrite(). See efs_fwrite()
EtherSetPktFilter() A-31
F G
getpeername() 3-16
fclose(). See efs_fclose()
getsockname() 3-17
FD_CLR() 3-10
getsockopt() 3-17
FD_COPY() 3-11
FD_ISSET() 3-11
fd_set 3-10 H
FD_SET() 3-10 HDLC C-14
FD_ZERO() 3-11 hdlcFree() C-16
fdClose() 3-7 hdlcGetStatus() C-16
fdCloseSession() 3-6 hdlcNew() C-14
fdError() 3-7 hdlcsFree() C-18
fdGetFileHandle() 3-8 hdlcsGetStatus() C-18
fdOpenSession() 3-6 hdlcsNew() C-17
fdSelect() 3-7 HOSTENT 5-8
fdSelectAbort() 3-8 HTTP Exported Functions E-12
fdTransfer() 3-8 HTTP Server E-1
File Descriptor Functions 3-6 HTTP Server Support 6-14
Index-3
Index
HTTPClose() 6-15 ipcfg.RtDownTime A-53

HTTPOpen() 6-15 ipcfg.RtKeepAliveTime A-53
httpSendClientData() E-6 ipcfg.SockBufMax A-55
httpSendClientStr() E-12 ipcfg.SockBufMinRx A-55
httpSendFullResponse() E-12 ipcfg.SockBufMinTx A-55
httpSendStatusLine() E-12 ipcfg.SockMaxConnect A-54
ipcfg.SockTimeConnect A-54
I ipcfg.SockTimeIo A-55
ipcfg.SockTosDefault A-54
IFCreatePacket() A-27 ipcfg.SockTtlDefault A-54
IFGetIndex() A-26 IPCONFIG A-50
IFGetMTU() A-26
IFGetType() A-26
IFIndexFree() A-25
L
IFIndexGetHandle() A-26 listen() 3-22
IFIndexNew() A-25 LLADeRef() A-20
IFInit() A-25 LLAGetData() A-21
IFMaxIndex() A-25 LLAGetLength() A-21
IFSetPad() A-27 LLAGetType() A-21
inet_addr() 5-2 LLANew() A-20
inet_aton() 5-3 LLARef() A-20
IP options 3-21 LLASet() A-21
IP_HDRINCL 3-21 LLIGetLLA() A-22
IP_OPTIONS 3-21 LLIValidateRoute() A-22
IP_TOS 3-21 llPacketClose() D-6
IP_TTL 3-21 llPacketGetBuffer() D-8
ipcfg.IcmpDoRedirect A-51 llPacketGetMacAddr() D-7
ipcfg.IcmpTtl A-51 llPacketGetMCast() D-7
ipcfg.IcmpTtlEcho A-51 llPacketGetMCastMax() D-7
ipcfg.IpForwarding A-51 llPacketInit() D-5
ipcfg.IpIndexStart A-51 llPacketOpen() D-6
ipcfg.IpNatEnable A-52 llPacketReturnBuffer() D-9
ipcfg.IpReasmMaxSize A-52 llPacketSend() D-8
ipcfg.IpReasmMaxTime A-52 llPacketService() D-8
ipcfg.PipeBufMinRx A-56 llPacketServiceCheck() D-6
ipcfg.PipeBufMinTx A-56 llPacketSetMCast() D-8
ipcfg.PipeBufSize A-56 llPacketShutdown() D-6
ipcfg.PipeTimeIo A-55 llSerialCloseCharmode() D-12
ipcfg.RtcAdvLife A-53 llSerialCloseHDLC() D-12
ipcfg.RtcAdvPref A-53 llSerialConfig() D-13
ipcfg.RtcAdvTime A-52 llSerialGetBuffer() D-14
ipcfg.RtcEnableDebug A-52 llSerialInit() D-10
ipcfg.RtCloneTimeout A-53 llSerialOpenCharmode() D-11
ipcfg.RtDefaultMTU A-54 llSerialOpenHDLC() D-12
Index-4
Index
llSerialReturnBuffer() D-14 Network Control Functions 4-20

llSerialSend() D-14 Network Tools Services 6-1
llSerialServiceCheck() D-11 NT_MODE_IFIDX 6-3
llSerialShutdown() D-11 NT_MODE_IPADDR 6-3
llTimerClose() D-3 NtAddNetwork() 5-3
llTimerGetStartTime() D-4 NtAddStaticGateway() 5-4
llTimerGetTime() D-4 NTARGS 6-3
llTimerOpen() D-3 NtGetPublicHost() 5-5
llTimerServiceCheck() D-4 NtIfIdx2Ip() 5-5
NtIPN2Str() 5-6
NTPARAM_DHCPS 6-8
M NTPARAM_NAT 6-19
mmAlloc() 2-13 NTPARAM_TELNET 6-5
mmBulkAlloc() 2-14 NtRemoveNetwork() 5-3
mmBulkFree() 2-14 NtRemoveStaticGateway() 5-5
mmBulkRealloc() 2-14 NtTftpRecv() 5-10
mmCopy() 2-14
mmFree() 2-13 O
mmZeroInit() 2-14
oscfg 2-2
oscfg.DbgAbortLevel 2-3
N oscfg.DbgPrintLevel 2-2
oscfg.TaskPriHigh 2-3
NAT B-1
oscfg.TaskPriKern 2-3
NAT Port Mapping B-6, B-16
oscfg.TaskPriLow 2-3
NAT Proxy Filter B-8, B-20
oscfg.TaskPriNorm 2-3
NAT Proxy Filter Callback Functions B-20
oscfg.TaskStkHigh 2-4
NAT Service Support 6-18
oscfg.TaskStkLow 2-4
NATClose() 6-21
oscfg.TaskStkNorm 2-4
NatFree() B-19
OSENVCFG 2-2
NatGetPNI() B-19
NATINFO B-16
NatNew() B-18 P
NATOpen() 6-20 parsePostVars() E-5
NatSetconfig() A-58 pipe() 3-35
NC_NetStart() 4-20 Pipes 3-34
NC_NetStop() 4-22 PktFree() A-8
NC_SystemClose() 4-22 PktGetEthType() A-8
NC_SystemOpen() 4-22 PktGetFlags() A-9
NETTOOLS_STAT_COMPLETED 6-4 PktGetFrag() A-9
NETTOOLS_STAT_FAULT 6-4 PktGetIFRx() A-9
NETTOOLS_STAT_NONE 6-4 PktGetIFTx() A-9
NETTOOLS_STAT_PARAMUPDATE 6-4 PktGetLLADst() A-10
NETTOOLS_STAT_RUNNING 6-4 PktGetRoute() A-10
Network Address Translation Service 6-18 PktGetSizeLLC() A-10
Index-5
Index
PktGetSizeNet() A-10 RTCRemoveHook() A-49

PktGetSizeTP() A-11 RtDeRef() A-40
PktNew() A-8 RtFind() A-41
PktSetEthType() A-11 RtGetFailure() A-43
PktSetFlagsClear() A-11 RtGetFlags() A-43
PktSetFlagsSet() A-11 RtGetGateIP() A-44
PktSetFrag() A-12 RtGetIF() A-44
PktSetIFRx() A-12 RtGetIPAddr() A-44
PktSetIFTx() A-12 RtGetIPMask() A-44
PktSetLLADst() A-12 RtGetMTU() A-44
PktSetRoute() A-13 RtRef() A-40
PktSetSizeLLC() A-13 RtRemove() A-43
PktSetSizeNet() A-13 RtSetFailure() A-42
PktSetSizeTP() A-13 RtSetTimeout() A-42
Point to Point Protocol C-1 RtWalkBegin() A-45
PPP C-1 RtWalkEnd() A-45
PPP User Account 4-31, C-25 RtWalkNext() A-45
pppFree() C-12
pppInput() C-12
pppNew() C-10
S
PPPoE C-20 select(). See fdSelect()
pppoeFree() C-21 SemCount() 2-10
pppoeGetStatus() C-22 SemCreate() 2-10
pppoeNew() C-20 SemDelete() 2-11
pppoesFree() C-24 SemPend() 2-11
pppoesNew() C-22 SemPost() 2-12
pppTimer() C-13 SemReset() 2-12
printf() 2-15 send() 3-28
ProxyEnableCallback() B-20 sendto() 3-29
ProxyFree() B-22 Service Calling Conventions 6-2
ProxyNew() B-21 Service Report Function 6-2
ProxyPacketMod() B-23 setsockopt() 3-31
ProxyRxCallback() B-21 shutdown() 3-32
ProxyTxCallback() B-21 SO_BROADCAST 3-19
SO_DONTROUTE 3-19
R SO_ERROR 3-20
SO_IFDEVICE 3-21
recv() 3-22 SO_KEEPALIVE 3-18
recvfrom() 3-24 SO_LINGER 3-19
recvnc() 3-12, 3-25 SO_OOBINLINE 3-13, 3-19
recvncfree() 3-12, 3-26 SO_RCVBUF 3-19
recvncfrom() 3-12, 3-27 SO_RCVLOWAT 3-20
RTCAddHook() A-48 SO_RCVTIMEO 3-20
RtCreate() A-40 SO_REUSEADDR 3-18
Index-6
Index
SO_REUSEPORT 3-18 TaskYield() 2-9

SO_SNDBUF 3-19 TCP_MAXSEG 3-21
SO_SNDLOWAT 3-19 TCP_NODELAY 3-21
SO_SNDTIMEO 3-20 TCP_NOOPT 3-21
SO_TYPE 3-20 TCP_NOPUSH 3-21
socket() 3-32 Telnet Parameter Structure 6-5
Sockets 3-1 Telnet Server Service 6-5
Sockets Programming Interface 3-12 TelnetClose() 6-7
sprintf() 2-15 TelnetOpen() 6-6
TimerFree() A-34
TimerHSTick() A-35
T TimerNew() A-34
TOS 3-21
TaskBlock() 2-5
TTL 3-21
TaskCreate() 2-5
TaskDestroy() 2-7
TaskExit() 2-7 V
TaskGetEnv() 2-7 vprintf() 2-15
TaskGetPri() 2-7 vsprintf() 2-15
TaskSelf() 2-8
TaskSetEnv() 2-8
TaskSetPri() 2-9
W
TaskSleep() 2-9 WEB Content E-1
Index-7

Spru 524 A

Uploaded by

Copyright:

Available Formats

Spru 524 A

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Spru 524 A

Uploaded by

Copyright:

Available Formats

TMS320C6000 TCP/IP

Network Developer’s Kit (NDK)

Literature Number: SPRU524A

Printed on Recycled Paper

Reproduction of information in TI data books or data sheets is permissible only if reproduction

Copyright  2001, Texas Instruments Incorporated

Read This First

About This Manual

How to Use This Manual

- Chapter 1 – Introduction, summarizes the various API sets described in

- Chapter 2 – Operating System Abstraction API, describes the API used

- Chapter 4 – Initialization and Configuration, describes the TCP/IP

- Chapter 5 – Network Tools LIbrary Support Functions, describes the

- Chapter 6 – Network Tools Library Services, describes the network

- Appendix A – Internal Stack Functions, contains a partial list of internal

Read This First iii

- Appendix B – Network Address Translation, describes the optional

- Appendix C – Point to Point Protocol, describes the operation of the

- Appendix D – Hardware Abstraction Layer (HAL), describes the opera-

- Appendix E – Web Programming with the HTTP Server, describes how

Related Documentation From Texas Instruments

The following reference is provided for further information:

TMS320C6000 TCP/IP Network Developer’s Kit (NDK) User’s Guide

TMS320C6000 TCP/IP Network Developer’s Kit (NDK) Porting Guide

TMS320C6000 TCP/IP Network Developer’s Kit (NDK) Technical Data

The following typographical conventions are used in this specification:

- Text inside back-quotes (‘‘) represents pseudo-code

TMS320C6000, Code composer Studio, and DSP/BIOS are trademarks of

2 Operating System Abstraction API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

3 Sockets and Stream IO API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

4 Initialization and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

5 Network Tools Library Support Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

6 Network Tools Library Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

A Internal Stack Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

B Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

C Point to Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

D Hardware Abstraction Layer (HAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

E Web Programming with the HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

This chapter serves as an introduction to the programming API reference for

1.1 This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

1.1 This Document

1.1.1 Supplemental API Information

- Appendix A: Internal TCP/IP Stack Library Functions

- Appendix B: Network Address Translation

- Appendix C: Point to Point Protocol

- Appendix D: Hardware Abstraction Layer

- Appendix E: Web Programming with the HTTP Server

1.2 Additional Documentation

1.2.1 TMS320C6000 TCP/IP NDK User’s Guide

- TCP/IP NDK Installation and Test

- Running the Example Applications

- TCP/IP Stack Library Overview

- Network Application Development

1.2.2 TMS320C6000 TCP/IP NDK Porting Guide

The TCP/IP stack is designed to be executed in different operating modes with

Operating System Abstraction API

2.1 Operating System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.1 Operating System Configuration

2.1.2 Configuration Structure