TCP/IP Transport for DOS

Configuration

Part 2/3

Introduction     Utilities
 

Configuration

This chapter explains both the required and optional configurations for the TCP/IP Transport software.

Configuring Application Services

When you configure the Novell® TCP/IP Transport software, you must set up the required configuration and database files. Usually these files require customization to accommodate the specific features of your network.

The following table lists the service configuration files you must set up before you can run your applications.

Required Service Configuration Files
File Location Description
HOSTS \NET\TCP  This file is the hostname database file that lists the names, IP addresses, and aliases for the remote hosts on your network. 
RESOLV.CFG  \NET\TCP  This file defines the network's DNS domain name and name servers. TCP/IP requires this file only if the network uses a name server.

You can change the locations of these files using the PATH TCP_CFG parameter in the NET.CFG file. For more information on this parameter, see the table "Summary of NET.CFG PROTOCOL TCPIP Miscellaneous Settings".

You must configure either the RESOLV.CFG or HOSTS file to be able to resolve symbolic hostnames.

When you use the TCP/IP Transport software, you can connect to a remote host by specifying its Internet address. If a hostname database exists, you can also connect to a remote host by specifying its name or one of its aliases.

You can set up a hostname database in one of two ways:

You can place a host table file on each workstation.

You can have one or more Domain Name System (DNS) name servers on the network .

Your network is probably a mixed environment where some workstations or hosts running TCP/IP use a DNS name server and other systems use only a host table. You might require that each workstation or host on your network use both methods (use a DNS name server and have a host table on each workstation as a backup for the DNS).

Setting Up the HOSTS File

A host table is a listing of IP addresses, corresponding hostnames, and aliases. The HOSTS file, located on your workstation, is your TCP/IP Transport host table. This file must contain an entry for every host you access in your network. This file can also contain entries for specific hosts on remote networks.

The following is an example of a HOSTS file.

HOSTS File

 #
 # IP ADDRESS   HOSTNAME         ALIASES
 # 
 127.0.0.1      LOOPBACK         LB
 127.47.5.1     ENGR             ENGINEERING
 127.47.7.3     MKTG             MARKETING
 127.47.10.25   MANFG            MANUFACTURING

Each entry in the HOSTS file must have the following format: 

Internet_address hostname [ alias [...] ]

Each element in an entry must be separated by one or more space characters or a tab character.

Internet_address is a 4-byte address in standard dotted notation. Each byte is a decimal or hexadecimal value and is separated by a period. Hexadecimal numbers must start with the character pair 0x or 0X. Each number in the Internet address must be a value in the range 0 to 255 (decimal) or 0x00 to 0xFF (hexadecimal). Each entry should have a unique IP address.

Warning: Serious problems can occur if two workstations are assigned the same IP address.

hostname is the name of the system associated with this Internet address. It can contain any printable character other than space, tab, backspace, carriage-return and line-feed characters (CR-LF), end-of-line character, or comment character (#). The hostname is an arbitrary string, preferably long enough for each name to be unique across the network.

alias is another name for the same system. Typically, this is a shorter name and should be unique within your domain (that is, a subset of computers to be used). A single host can have more than one alias. For example, the following entry lists two aliases (SA and SELL) for the SALES host. 

129.47.9.5 SALES SA SELL

The first item on the line is the host's Internet address. The second item is the host's name (sometimes referred to as the primary name). Any items following the hostname are aliases associated with the host.

A number sign (#) in the HOSTS file, at any position on a line, indicates the beginning of a comment. Characters from the number sign up to the CR-LF or end-of-line character are ignored by functions that search the file.

You can create or modify a HOSTS file using any text editor.

Setting Up Domain Name System Support

The preferred way for the TCP/IP Transport software to identify remote hosts is to use a DNS name server. This is the only type of name server that the TCP/IP Transport software supports.

To use a DNS name server, your workstation calls the name server on a remote host to get address information. Like a host table, a name server has network addresses for the computers on your network.

Even if you have DNS name servers on your network, you may want to create a HOSTS file on each individual workstation or server in case the DNS name servers fail.

NOTE: If your site does not have a DNS name server, you must have a HOSTS file on each workstation.

By default, the TCP/IP Transport software determines the IP address for a hostname by first accessing a DNS name server. If a valid entry is in the DNS name server, the TCP/IP protocol stack opens a session with the remote host. If the software cannot find a DNS name server or it cannot find the remote hostname in the DNS name server, the software looks for the remote hostname in your workstation's HOSTS file.

You can change the way TCP/IP searches for an IP address by using the SEARCH command in the following format: 

SEARCH first_source [ second_source ] [SEQUENTIAL]

If you want TCP/IP to search the DNS name servers or the HOSTS file only, specify DNS or HOSTS file as first_source (do not specify a second_source). If you want to search both the DNS name servers and the HOSTS file, specify both sources in the order you want TCP/IP to search them. Include the SEQUENTIAL parameter if you want TCP/IP to search the DNS name servers sequentially.

To access a DNS name server on your network, you must have a resolver configuration file, RESOLV.CFG, on your workstation. This file is located in your \NET\TCP directory. It contains entries that specify the Internet address of the system on which the name server is running.

Two types of entries are available in the resolver file: domain and name server. The following example shows both types of entries.

Sample RESOLVE.CFG File

;COMPANY RESOLVER FILE 
DOMAIN COMPANY.COM
;
;MAXCACHE (FAST CACHING ONLY NAME SERVER FOR COMPANY.COM - INTERNAL ONLY) 
NAME SERVER 129.47.8.1 
;
;SECROOT (SECONDARY ROOT NAME SERVER FOR COMPANY.COM - VISIBLE TO INTERNET) 
NAME SERVER 129.47.4.2
;
;PRIMROOT (PRIMARY ROOT NAME SERVER FOR COMPANY.COM - VISIBLE TO INTERNET)
NAME SERVER 129.47.4.1

The domain entry is a single entry with the following format: 

DOMAIN domain_name

You must include the domain keyword. If your organization has an Internet domain assigned (for example, NOVELL.COM) and you need to communicate with the Internet, you must also include the domain_name. The domain_name has the extension .COM for a commercial organization, .MIL for a military organization, .EDU for a school, or .GOV for a government organization.

You can include up to three name server entries in the resolver configuration file. Each of these entries has the following format: 

NAMESERVER Internet_address

You must include the name server keyword with each name server entry. Internet_address is the Internet address of the name server in dotted notation.

The domain entry lets you specify a default domain to apply to all names without a domain. The name server entry lets you specify the IP address of a name server for the resolver functions (for example, name server 129.47.8.1).

You precede comments with a semicolon (;) character. For example: 

NAMESERVER 129.47.8.1 ; COMPANY RESOLVER FILE

If the file lists more than one Internet address, the resolver tries them in the order listed. In the example Sample RESOLVE.CFG File above, the resolver tries to locate an IP address on the maxcache name server first. If unsuccessful, the resolver checks the secroot name server, followed by the primroot name server.

To disable your domain name server, you can rename the RESOLV.CFG file in the \NET\TCP directory (for example, renaming the file to RESOLV.OFF turns your DNS off).

Optional Transport Configuration Files

Other optional configuration files customize the operation of the utilities and applications. These files are as follows:

Setting Up the PROTOCOL File

The PROTOCOL file contains information about the known protocols used on the Internet network. Each protocol is represented by a single line with the following parameters separated by one or more space characters:
protocol_name protocol_number [ alias [ ... ] ]

The protocol_name is the name of the Internet protocol associated with this protocol number. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#).

The protocol_number is the number of the Internet protocol.

The alias is an alternate name for the protocol.

For example, the TCP protocol has the following entry in the PROTOCOL file: 

TCP 6 TCP # TRANSMISSION CONTROL PROTOCOL

The following example shows a sample PROTOCOL file.

Sample PROTOCOL File

 # 
 # NAME    NUMBER   ALIASES
 #
 IP        0        IP       # INTERNET PROTOCOL, PSEUDO PROTOCOL NUMBER
 ICMP      1        ICMP     # INTERNET CONTROL MESSAGE PROTOCOL
 IGMP      2        IGMP     # INTERNET GROUP MULTICAST PROTOCOL 
 GGP       3        GGP      # GATEWAY-GATEWAY PROTOCOL
 TCP       6        TCP      # TRANSMISSION CONTROL PROTOCOL 
 PUP       12       PUP      # PARC UNIVERSAL PACKET PROTOCOL
 UDP       17       UDP      # USER DATAGRAM PROTOCOL

Setting Up the SERVICES File

The SERVICES file contains information about the known services used on the Internet network. Each service is represented by a single line with the following parameters, each separated by one or more blanks: 
service_name port_number/protocol_name [ alias [ ... ] ]

The service_name is the name of the service associated with this port number and protocol name. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#). These services are generally application, presentation, or session-level modules, such as TFTP, FTP, SMTP, and TELNET.

The port_number is the number of the Internet port used by the service. The protocol_name is the protocol with which the service is associated. This protocol is generally a transport-level or network-level module, such as TCP or UDP. Separate the port number and the protocol name with a slash.

The alias is an alternate name for the service.

A number sign (#) in the SERVICES file indicates the beginning of a comment. Characters between the number sign and the newline character are ignored by the functions that search the file.

For example, the following line is the entry for the SMTP mail protocol: 

SMTP 25/TCP MAIL

The following example shows a sample SERVICES file. 

 # 
 # SERVICE-NAME  PORT/PROTOCOL  ALIASES
 #
 ECHO            7/UDP
 ECHO            7/TCP
 DISCARD         9/UDP          SINK NULL
 DISCARD         9/TCP          SINK NULL
 SYSTAT          11/TCP
 DAYTIME         13/UDP
 DAYTIME         13/TCP
 NETSTAT         15/TCP
 FTP-DATA        20/TCP
 TELNET          23/TCP
 SMTP            25/TCP         MAIL
 TIME            37/TCP         TIMESERVER
 TIME            37/UDP         TIMESERVER
 NAME            42/UDP         NAMESERVER
 WHOIS           43/TCP         NICNAME         # USUALLY TO SRI-NIC
 DOMAIN          53/UDP
 DOMAIN          53/TCP
 HOSTNAMES       101/TCP        HOSTNAME        # USUALLY TO SRI-NIC
 SUNRPC          111/UDP
 SUNRPC          111/TCP
 #HOST-SPECIFIC FUNCTIONS
 #
 TFTP            69/UDP
 RJE             77/TCP
 FINGER          79/TCP
 LINK            87/TCP         TTY LINK
 SUPDUP          95/TCP
 ISO-TSAP        102/TCP
 X400            103/TCP                        # ISO MAIL
 X400-SND        104/TCP
 CSNET-NS        105-TCP
 POP-2           109/TCP                        # POST OFFICE
 UUCP-PATH       117/TCP
 NNTP            119/TCP        USENET          # NETWORK NEWS TRANSFER
 NTP             123/TCP                        # NETWORK TIME PROTOCOL
 NEWS            144/TCP        NEWS            # WINDOW SYSTEM
 #
 # UNIX-SPECIFIC SERVICES
 #
 # THESE ARE NOT OFFICIALLY ASSIGNED
 #
 EXEC            512/TCP
 LOGIN           513/TCP
 SHELL           514/TCP        CMD             # NO PASSWORDS USED
 PRINTER         515/TCP        SPOOLER         # EXPERIMENTAL
 COURIER         530/TCP        RPC             # EXPERIMENTAL
 BIFF            512/UDP        COMSAT
 WHO             513/UDP        WHOD
 SYSLOG          514/UDP
 TALK            517/UDP
 ROUTE           520/UDP        ROUTER ROUTED
 NEW-RWHO        550/UDP        NEW-WHO         # EXPERIMENTAL
 RMONITOR        560/UDP        RMONITORD       # EXPERIMENTAL
 MONITOR         561/UDP                        # EXPERIMENTAL
 INGRESLOCK      1524/TCP

Setting Up the NETWORKS File

The NETWORKS file contains information about the known networks that make up the Internet network. Each network is represented by a single line with the following parameters separated by one or more blank spaces: 

network_name Internet_number [ alias [...] ]

The network_name is the name of the network associated with this Internet network number. It can contain any printable character other than a field delimiter (space or tab), newline character, or number sign (#). The network name is an arbitrary string, preferably long enough for each name to be unique.

The Internet_number is the number of the Internet network. Hexadecimal numbers start with the character pair 0x or 0X.

The alias is another name for the same network.

For example, the network "cornet" might have the following entry in the NETWORKS file: 

CORNET   144.61   HORN

The NETWORKS file can be created from the official host database maintained at the Network Information System Center (NISC), although local changes may be required to bring it up to date regarding unofficial aliases and unknown networks. Such a file should be centrally administered for consistency.

The following example shows a sample NETWORKS file: 

 #
 # NETWORK-NAME    INTERNET-NUMBER    ALIASES
 #
 LOOPBACK          127
 COMPANY-NET       129.47
 SUBNET-A          129.47.4
 SUBNET-B          129.47.8

 # INTERNET NETWORKS
 ARPANET           10                 ARPA
 UCB-ETHER         46                 UCBETHER

Setting Up the ETHERS File

The configuration table read by RARPD when it is loaded is the text file ETHERS in the \NET\TCP directory.

Each line of this file contains one MAC address/IP address pair, separated by tabs or spaces. The MAC address is 6 hexadecimal bytes separated by colons. The IP address can be in dotted notation, or a symbolic hostname can be supplied.

Hostnames are resolved when RARPD is loaded, either through DNS or the HOSTS file.

Lines in the ETHERS file that start with the pound sign (#) are interpreted as comments.

The following is an example ETHERS file: 

 # ETHERNET ADDRESS        IP ADDRESS
 08:00:14:11:34:2C         LAB1
 02:60:8C:0D:FA:DF         129.47.5.98

Modifying NET.CFG

NetWare® and the TCP/IP Transport software use the NET.CFG file to configure other protocols, such as IPX. This file contains protocol sections that each define a separate protocol. For example, the Protocol RFCNBIOS section specifies fixed NetBIOS names for IP address mappings.

The NET.CFG file has three sections that are used by the TCP/IP Transport software:

The sections that follow explain the NET.CFG format and discuss NET.CFG settings that you can customize in the LINK SUPPORT, LINK DRIVER, and PROTOCOL TCPIP sections. These discussions are followed by a selection of example configurations.

Editing the NET.CFG File

You can use any text editor, such as DOS 5.0 EDIT, to update this file. The NET.CFG file uses the following format:

Section headings start at the beginning of a line (first column) and precede the parameter settings that apply to the section: 

Section_Heading

Parameter settings listed under each section heading are indented with a tab or one or more spaces: 

Section_Heading   Parameter Value(s)

Type numbers for values in decimal notation unless directed otherwise.

Type section headings and parameters in any combination of uppercase and lowercase letters.

Precede comments with a number sign (#) or semicolon (;).

End each line with a carriage return.

After changing NET.CFG, you might also need to change the AUTOEXEC.BAT file or other workstation batch files to load any new drivers you are configuring. The drivers read the information in NET.CFG when they are loaded into memory. For NET.CFG changes to take effect, you must unload and reload the drivers and TCPIP.EXE so that they read the new NET.CFG information. If you configure these programs to load from AUTOEXEC.BAT, rebooting the workstation has the same effect.

LINK DRIVER Section

The LINK DRIVER section of the NET.CFG file names the ODI drivers and specifies various hardware and software settings for each driver. The installation program sets up the LINK DRIVER section for your network board using the parameter settings necessary to run the Transport software. This section begins with the following section header: 
LINK DRIVER drivername

drivername specifies the ODI driver. For example, if the ODI driver file is NE2000.COM, drivername is NE2000TM.

The following table lists the parameters that configure the board and its driver for use by other software.

Summary of NET.CFG LINK DRIVER Settings
Parameter Syntax  Values  Explanation 
INT [ #1 | #2 ] IRQ_number   This parameter specifies the hardware interrupt number, IRQ_number, used by the network board. 
  [ #1 | #2 ]  This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type. 
  IRQ_number  This value specifies the decimal interrupt request number. 
PORT [ #1 | #2 ] address [ ports ]    This parameter specifies the starting port address and the number of ports used by the board. 
  [ #1 | #2 ]  This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type. 
  address  This value specifies the address, in hexadecimal, of the hardware port to use or the first port in a range of ports. 
  [ ports ]  This value specifies the number of ports in the range, in hexadecimal. 
DMA [ #1 | #2 ] channel    This parameter specifies the DMA channel to be used by the network board. 
  [ #1 | #2 ]  This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type. 
  channel  This value specifies the decimal DMA channel number. 
MEM [ #1 | #2 ] address [ length ]    This parameter specifies the range of DOS conventional memory to be reserved for use by the board. 
  [ #1 | #2 ]  This optional value specifies which network board channel you are configuring. Include this value only if you are configuring both communications channels on a board that supports two channels, or two network boards of the same type. 
  address  This value specifies the starting memory address, in hexadecimal. 
  length  This value specifies the length of the memory segment, in hexadecimal. 
SLOT number    For MCA boards, this parameter specifies the number, in decimal, of the slot into which you inserted the network board. This setting is required only if your workstation has more than one board of the same type. 
CONNECTOR DIX    For the 3C503.COM driver, this parameter configures the board to use the DIX (thick Ethernet) connector. If this setting is not included, the BNC/TP (thin) connector is used. 
FRAME { SLIP | PPP }    This parameter specifies the frame type used by the network board. You can include more than one frame setting for boards and drivers that support multiple frame types. 
PROTOCOL name protocol_ID frame_type    This parameter specifies the network protocol to be supported by the ODI driver. 
  name  This value specifies the name of the network protocol to be supported. 
  protocol_ID  This value specifies the hexadecimal ID number assigned to this protocol (see Table 2-3Table 2-3 for a list of the ID numbers). 
  frame_type  This value specifies the frame type used by this protocol. See the preceding Frame setting.

Additional settings are used by individual ODI drivers and may be required or optional. Refer to the ODI section of the hardware documentation for your network board for information about what LINK DRIVER settings the driver uses and which settings are required. Another source of this information is the .INS file for each driver. These files, which have the same name as the driver .COM file and are stored in the same directory, are ASCII text files that often contain information and comments about driver configuration.

The sections that follow describe the LINK DRIVER section header and its most frequently used parameters.

LINK DRIVER name

Each ODI driver that you configure has a separate LINK DRIVER section in the NET.CFG file. Replace name with the executable filename of the driver you are using, omitting the extension (for example, NE2000 for NE2000.COM).

The names of the drivers provided with the TCP/IP Transport software can be found in the file MANIFEST.TXT on the distribution diskette.

INT [ #1 | #2 ] IRQ_number

The INT setting (called IRQ, for interrupt request, by some vendors) specifies which interrupt your network board uses. For example, to specify interrupt 5 on an NE2000 board, place the following lines in your NET.CFG file: 
LINK DRIVER NE2000 
  INT #1 5

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses Interrupt 5, you can place the following lines in your NET.CFG file: 

LINK DRIVER 3C505 
  INT 5

If, however, you are using more than one channel or network board, each of which has an INT value, you must include the characters #1 for the first channel's value and #2 for the second channel's value.

PORT [ #1 | #2 ] address [ ports ]

Use the PORT setting to specify the starting port (address, a hexadecimal number) and the number of ports in the range (ports, also hexadecimal).

For example, suppose you want to specify the starting port for the first communications channel on your board. The port address for the board is 300. Place the following lines in the NET.CFG file: 

LINK DRIVER NE2000 
  PORT #1 300

The number of ports is optional. The following example specifies port ranges for both of a board's communications channels with 32 ports (20 hexadecimal) in each range: 

LINK DRIVER 3C505
  PORT #1 300 20
  PORT #2 700 20

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses 32 ports starting at address 300, you can place the following lines in your NET.CFG file: 

LINK DRIVER 3C505
  PORT 300 20

If, however, you are using more than one channel or network board, each of which has a port address and range, you must include the characters #1 for the first channel's values and #2 for the second channel's values.

DMA [ #1 | #2 ] channel

The direct memory access (DMA) option specifies the hardware DMA channel setting of the network board. This option lets you configure DMA channels by entering the channel number (channel, a decimal number) to be used. The default value is the first DMA channel (channel = 1).
Note: Do not confuse your workstation's DMA channels with the communications channels on your network board. Some network boards have more than one network communications channel, each of which can be connected to a separate network communications line. DMA channels, on the other hand, are a feature of your workstation. A set number of DMA channels are allocated among all controller boards in your workstation that make use of this facility.

For example, if the first communications channel on your board uses DMA channel 3 and the second communications channel uses DMA channel 4, place the following lines in your NET.CFG file: 

LINK DRIVER 3C505
  DMA #1 3
  DMA #2 4

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses DMA channel 3, you can place the following lines in your NET.CFG file: 

LINK DRIVER 3C505
  DMA 3

If, however, you are using more than one channel or network board, each of which has a DMA value, you must include the characters #1 for the first channel's value and #2 for the second channel's value.

MEM [ #1 | #2 ] address [ length ]

The MEM option specifies a range of conventional DOS memory to be reserved for use by the network board.

Use the hexadecimal physical (absolute) address of the memory used by the board for the address parameter. This address must match the starting address configured on the board. Enter the optional length parameter in hexadecimal paragraphs (a paragraph is 16 bytes) of the memory segment used by the board.

For example, if your board addresses the memory segment from D0000 to D4000, the starting address is D0000 and the range is 400 hexadecimal paragraphs. You would place the following lines in your NET.CFG file for an EXOSTM board: 

LINK DRIVER EXOS
  MEM D0000 400

You do not need to include the characters #1 if you are specifying a value for only one network board communications channel. For example, if you are configuring only the first communications channel on a 3C505 board and this channel uses memory address C0000, you can place the following lines in your NET.CFG file: 

LINK DRIVER EXOS
  MEM C0000

If, however, you are using more than one channel or network board, each of which has a Mem value, you must include the characters #1 for the first channel's value and #2 for the second channel's value: 

LINK DRIVER EXOS
  MEM #1 C0000
  MEM #2 D0000

Some network boards, such as the 3C503 board, can be configured to use either shared DOS memory (requiring a Mem setting) or their own on-board memory. Refer to the manufacturer's documentation for your network board to determine how best to configure your board.

SLOT number

In slot-based computers, the driver usually locates the board by scanning through the slots in order from lowest to highest. The SLOT parameter directs the driver to eliminate the scan and locate the board in the specified slot.

Use the number of the slot into which you inserted the board for the number parameter (a decimal value). The slot number is usually found on the back of the workstation.

For example, if you are using two NE/2&TM; boards in the same workstation and you insert one board into slot 1 and the other into slot 2, place the following lines in your NET.CFG file: 

LINK DRIVER NE2
  SLOT 1

LINK DRIVER NE2
  SLOT 2

You would then need to load the NE2.COM driver twice. The SLOT option directs the first NE2 driver loaded to use the NE/2 board in slot 1 and directs the second NE2 driver to use the NE/2 board in slot 2.

CONNECTOR DIX

The CONNECTOR DIX parameter configures the 3C503 LAN driver to use the DIX (thick) connector. BNC/TP (thin) is the default value. To specify the DIX connector, place the following lines in your NET.CFG file: 
LINK DRIVER 3C503
  CONNECTOR DIX

DIX can also be selected in the command line that loads the 3C503.COM driver, as in the following example: 

3C503 /D

FRAME frame_type

The FRAME parameter enables the frame types used by the network board. You can use this option more than once with network boards that support multiple frame types.

For example, to enable the ETHERNET_II frame type on an NE1000TM board, place the following lines in the NET.CFG file: 

LINK DRIVER
NE1000 FRAME ETHERNET_II
Use the following frame formats for TCP/IP networks:

Ethernet ETHERNET_II or ETHERNET_SNAP
Token Ring TOKEN-RING_SNAP
ARCnet NOVELL_RX-NET
IBM PCN2 IBM_PCN2_SNAP
FDDI FDDI_SNAP

For OSI networks, use frame type ETHERNET_802.2. For IPX networks, Ethernet LAN drivers default to the ETHERNET_802.3 frame type; token ring LAN drivers default to the TOKEN-RING frame type.

The following table lists the network types that support each NET.CFG frame type parameter. Additional frame types are supported by the NCOMX driver.

IPX Frame Types and Corresponding Network Types
Frame Type  Hex ID Number  Ethernet  Token Ring  ARCnet  IBM PC-NET  FDDI 
ETHERNET_II  8137  Supported  ---  ---  ---  --- 
ETHERNET_SNAP  8137  Supported  ---  ---  ---  --- 
ETHERNET_802.2  E0  Supported  ---  ---  ---  --- 
ETHERNET_802.3  0  Supported  ---  ---  ---  --- 
TOKEN-RING_SNAP  8137  ---  Supported  ---  ---  --- 
TOKEN-RING  E0  ---  Supported  ---  ---  --- 
NOVELL_RX-NET  FA  ---  ---  Supported  ---  --- 
IBM_PCN2_802.2  E0  ---  ---  ---  Supported  --- 
IBM_PCN2_SNAP  8137  ---  ---  ---  Supported  --- 
FDDI802.2  E0  ---  ---  ---  ---  Supported 
FDDI_SNAP  8137  ---  ---  ---  ---  Supported 

Note: --- indicates that this frame type is not supported on this network type.

 

PROTOCOL name protocol_ID frame_type

The PROTOCOL option lets existing ODI drivers handle new network protocols.

Replace name with the name of the new protocol.

Replace protocol_ID with the hexadecimal protocol ID number that the protocol is assigned (see the table above).

Replace frame_type with the frame type to which the new protocol ID applies. Make sure the LINK DRIVER section for this driver contains a Frame setting enabling support of this frame type.

For example, if you want to use a new protocol XYZ with an NE2-32 network board, include the following lines in the NET.CFG file: 

LINK DRIVER NE2-32
  FRAME ETHERNET_SNAP 
  PROTOCOL XYZ 904A ETHERNET_SNAP

LINK SUPPORT Section

The TCP/IP Transport software uses the buffer management functions provided by the LSL driver. The LINK SUPPORT section of the NET.CFG file includes parameters that determine the number and sizes of buffers available for the TCP/IP protocol. IPX does not use these buffers.

Standard Configuration. The installation program sets up the LINK SUPPORT section for an Ethernet configuration as follows: 

LINK SUPPORT 
  BUFFERS 8 1500
  MEMPOOL 4096

The installation program sets up the LINK SUPPORT section for a token ring configuration as follows: 

LINK SUPPORT
  BUFFERS 8 4200
  MEMPOOL 4096

BUFFERS number [ size ]

The BUFFERS setting controls the number and size of receive packet buffers. The default number of receive buffers is 8, and the default size is 1500 bytes. You can reduce the number of receive buffers if TCP connections are used sequentially. If you make heavy use of multiple TCP connections, you can increase the number of buffers for better performance. The buffer size is dependent on the topology of your configuration.

MEMPOOL size

The MEMPOOL setting controls the size of an internal send-buffer pool used by TCP/IP. TCP send data is copied into this pool before being sent to the remote system. The default size is 4096 bytes. You might need to increase the MEMPOOL size when communicating with remote TCP hosts that offer large receive windows and delay acknowledgments.

Optional Parameters. If you are configuring more than one network board or plan to use multiple protocol stacks, you can set two additional parameters to configure the required LSL support.

MAX BOARDS number

This parameter configures the maximum number of logical boards the LSL program can support.

Each driver and frame type supported by the driver uses one LSL logical board resource. For example, if you are configuring NE1000.COM to load all possible Ethernet frame types (ETHERNET_II, ETHERNET_802.3, ETHERNET_802.2, and ETHERNET_SNAP), four board resources are used.

Include the MAX BOARDS setting only if you require more than four logical boards (the default). The range of values for number is from 1 to 16.

MAX STACKS number

This parameter configures the maximum number of logical protocol stacks LSL can support. Each protocol stack uses one or more stack ID resources.

If a protocol stack fails to load because of an out-of-resource condition, you can solve the problem by increasing this value. Because support for additional stacks increases the amount of memory used by LSL.COM, you can conserve some memory by reducing this value if your system is not using all allocated stack support.

Include the MAX STACKS setting only if you require more than four logical stacks (the default). The range of values for number is from 1 to 16.

PROTOCOL TCPIP Section

During startup, TCPIP.EXE reads settings saved in the PROTOCOL TCPIP section of the NET.CFG file.
Note: You can specify a different location for the NET.CFG file by loading TCPIP with the -C drive:path command-line option.

The parameters that can be set in the PROTOCOL TCPIP section of the NET.CFG file to configure TCPIP.EXE are summarized in the following 4 tables.

Summary of NET.CFG PROTOCOL TCPIP Board Settings
Parameter  Values  Explanation 
BIND driver [ #board frame_type network_name ]    This parameter specifies the network interface board for the TCP/IP protocol stack. This parameter is needed only if you are running more than one ODI driver to support TCP/IP (for example, a workstation that uses both an Ethernet connection and a SLIP/PPP serial link, or a network gateway machine with two network boards). 

If the PROTOCOL TCPIP section does not specify this setting, TCP/IP uses the first driver it finds in memory (the first one loaded). 

The #board, frame_type, and network_name values are optional. Include them only when configuring TCP/IP to run over multiple network interfaces. 

  driver  This value specifies the name of the ODI driver for this board. For example, if the driver is NE1000.COM, the value for the driver parameter is NE1000. 
  #board  This value specifies the board number bound to this driver. This is the physical load sequence number of the board (not the same as the logical board number displayed by the driver when it is loaded). When this value is 0, TCP/IP binds to the first board it finds that supports TCP/IP and also supports the specified frame_type. 
  frame_type  This value specifies the frame format used for this network connection. This is the same as the frame value in the LINK DRIVER section for this driver. 
  network_name  This value specifies the descriptive name for this network connection. The network_name is used with the IP_ADDRESS, IP_ROUTER, and IP_NETMASK parameters to distinguish between the values for each network connection.

Summary of NET.CFG PROTOCOL TCPIP Address Settings

Parameter  Values  Explanation 
IP_ADDRESS address [ network_name ]    This parameter specifies your workstation's IP address. The value for this parameter is supplied during installation. The IP_ADDRESSparameter has no default value. 
  address  This value specifies the IP address in dotted notation. If this parameter is missing or is 0.0.0.0, the protocol stack uses BOOTP or Reverse ARP to determine the IP address. 
  network_name  This value specifies the descriptive network name used in the BIND setting or this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP. 
IP_ROUTER address [ network_name ]    This parameter specifies the default router address for an active network. TCP/IP uses the ICMP redirect mechanism to determine all other gateways. This address is supplied during installation. The IP_ROUTERparameter has no default value. You can specify up to three routers for each active network. 
  address  This value specifies an IP address in dotted notation. 
  network_name  This value specifies the descriptive network name used in the BIND setting for this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP. 
IP_NETMASK mask [ network_name ]    This parameter specifies the subnetwork mask if subnetworks are used. This parameter is supplied during installation. The IP_NETMASKparameter has no default value. 
  mask  Subnetwork mask in dotted notation. 
  network_name  The descriptive network name used in the Bind setting for this network connection. The network_name is required only if you are configuring multiple ODI drivers for TCP/IP.

Summary of NET.CFG PROTOCOL TCPIP Miscellaneous Settings
Parameter  Values  Explanation 
PATH TCP_CFG [ [ drive: ] path [ ; ... ] ]    This parameter specifies the directory or directories that contain the database configuration files HOSTS, NETWORKS, PROTOCOL, SERVICES, and RESOLV.CFG. The syntax is the same as the DOS PATH command. The default value is \NET\TCP. 
NO_BOOTP    This parameter specifies whether to bypass a BOOTP system, if one is present on the network, and use Reverse ARP to identify a workstation's IP address. 

The transport uses the address specified by the ip_address parameter first if this parameter is present; if not, it sends out a BOOTP request packet; and if no response is received from a BOOTP server, Reverse ARP is assumed. Including the NO_BOOTP parameter eliminates the BOOTP request packet step. 

TCP_WINDOW number    This parameter specifies TCPIP's maximum receive window size in bytes. You can specify a maximum value of 32,767 for number. 
TCP_MAXSEGSIZE number    This parameter specifies the maximum packet segment size you use when communicating with other nodes. You can specify a maximum of 8192 bytes for number. 
TCP_MINRXMIT number    This parameter specifies the minimum number of time-outs that TCPIP can use. You can specify a value from 1 through 540. Each timeout lasts 55 milliseconds. 
TCP_MAXRXMIT number    This parameter specifies the maximum number of time-outs that TCPIP can use. You can specify a value from one plus the number of TCP_MINRXMIT time-outs through 1080 time-outs. Each time-out lasts 55 milliseconds.

Summary of NET.CFG PROTOCOL TCPIP Socket Settings
Parameter  Values  Explanation 
TCP_SOCKETS number    This parameter specifies the maximum number of concurrent TCP connections. If you configure multiple ODI drivers for TCP/ IP, the number of TCP sockets you specify is the total shared by all drivers. 
The default value is 8. The range of values is 0 through 64. 
UDP_SOCKETS number    This parameter specifies the maximum number of concurrent UDP connections. You should have at least one UDP socket for each concurrently run application if you are planning to use the DNS. NetBIOS requires at least 2 UDP sockets. If you configure multiple ODI drivers for TCP/IP, the number of UDP sockets you specify is the total shared by all drivers. 
The default value is 8. The range of values is 0 through 32. 
RAW_SOCKETS number    This parameter specifies the maximum number of raw IP connections. You should have one raw IP socket if you are planning to use the PING command or the applications that use this capability (Serving FTPTM, IP Resolver, LWPCON). If you configure multiple ODI drivers for TCP/IP, the number of raw sockets you specify is the total shared by all drivers. 
The default value is 1.

Allocating Sockets

The default NET.CFG file configured by the installation program provides for eight TCP sockets, eight UDP sockets, and one raw socket. These default allocations are intended to be sufficient for most configurations. If you expect to make heavy concurrent use of applications that use sockets, you might want to modify the number of TCP sockets. You need one TCP socket for each TELNET session and two TCP sockets for each FTP session.

UDP sockets are used by LWPCON and by all applications that query DNS name servers. Because UDP sockets are used briefly to send and receive datagrams, then released, you need more than the default eight UDP sockets only if you make very heavy use of DNS.

One raw socket is required for use by PING, LWPCON, and other applications that have ping functions.

Using a BOOTP Server

If your network has a BOOTP server that is configured to supply your workstation with its IP address, router address, and subnetwork mask, omit the IP_ADDRESS, IP_ROUTER, and IP_NETMASK parameters from your NET.CFG file. If these parameters are missing, the TCP/IP Transport software expects their values to be supplied by a BOOTP server.

Using a Reverse ARP Server

The Reverse Address Resolution Protocol (RARPD) server program allows you to assign workstation IP addresses from a centrally administered IP address database on a single workstation.

RARPD maintains a table in memory associating IP addresses with physical hardware (MAC) addresses of workstations on the network. A workstation configured as a RARPD client queries the RARPD server on startup, supplying its MAC address. RARPD responds with the corresponding IP address.

If your network has a reverse ARP server, such as RARPD, that provides your workstation IP address when you restart the workstation, you need to configure the following in your NET.CFG file:

Setting Up NetBIOS

RFCNBIOS.EXE implements the NetBIOS B-node protocols as defined in RFCs 1001 and 1002. (The B-node protocols use broadcast datagrams for network management and some NetBIOS datagram operations.) With this software, you can run any workstation network application designed for the standard NetBIOS interface.
IMPORTANT: All directly connected NetBIOS nodes with which you plan to communicate must use an RFC1001/1002-compliant NetBIOS program. Also, all NetBIOS implementations must be B-node configurations.

The NetBIOS software is customized in the PROTOCOL TCPIP and PROTOCOL RFCNBIOS sections of the NET.CFG file. The following 2 tables summarize the NetBIOS settings.

Summary of NetBIOS NET.CFG Protocol TCPIP Section Settings
Parameter  Explanation 
NB_SESSIONS number This parameter specifies the maximum number of concurrent NetBIOS sessions. When you specify this setting, you must increase the number of TCP sockets you allocate (TCP_SOCKETS setting) to at least 1 plus the value of this setting. 
The default value of number is 4. You can specify a setting from 0 through 64. 
NB_COMMANDS number  This parameter specifies the maximum number of asynchronous NetBIOS commands. 
The default value of number is 20. You can specify a setting from 0 through 80. 
NB_DOMAIN domain_name  This parameter specifies the name of the logical domain for this NetBIOS station. The value of this setting is an ASCII string. By default the value of domain_name is null. 
NB_ADAPTER { 0 | 1 } This parameter specifies which NetBIOS board to use. 
NB_BRDCAST { 0 | 1 | IP_address}  This parameter specifies the format of IP broadcasts used when RFCNBIOS.EXE sends broadcast messages. 

The value 0 sets the broadcast address to use zeroes for the host portions of the IP address. For example, a Class B network with network address 122.44 would have broadcast address 122.44.0.0. 

The value 1 sets the broadcast address to use 255 for the host portions of the IP address. For example, a Class B network with network address 122.44 would have broadcast address 122.44.255.255.

Summary of NetBIOS NET.CFG Protocol RFCNBIOS Section Settings
Parameter  Explanation 
REMOTENAMEn IP_address  This parameter specifies an IP address on a different broadcast network from the workstation. This address is preloaded in the NetBIOS name cache. The value of n can be from 1 through 16.

The following information describes the configuration of the NetBIOS settings in the NET.CFG file.

NB_ADAPTER { 0 | 1 }

This parameter specifies which NetBIOS adapter number to bind to TCP/IP. This value must be either 0 or 1 (the first network board is 0, the second is 1).

You can specify this setting using NB_ADAPTER in the following format: 

NB_ADAPTER { 0 | 1 }

For example: 

PROTOCOL TCPIP
  IP_ADDRESS 129.47.6.84
  .
  .
  NB_ADAPTER 0

The default value for this setting is 0.

NB_BRDCAST { 0 | 1 } IP_address

This parameter specifies the format of IP broadcasts used when RFCNBIOS.EXE sends broadcast messages.

The value 0 sets the broadcast address to use zeroes for the host portions of the IP address. Therefore, a Class B network with a network address of 129.47 would have a broadcast address of 129.47.0.0.

The value 1 sets the broadcast address to use 255 for the host portions of the IP address. Therefore, a Class B network with a network address of 129.47 would have a broadcast address of 129.47.255.255.

You can specify this setting using NB_BRDCAST in the following format: 

NB_BRDCAST { 0 | 1 }

For example: 

PROTOCOL TCPIP
  IP_ADDRESS 129.47.6.84 
  . 
  . 
  NB_BRDCAST 0

The default value is 1.

NB_COMMANDS number

This parameter specifies the maximum number of asynchronous NetBIOS commands. Each pending NetBIOS command requires 32 bytes of memory.

You can specify this setting using NB_COMMANDS in the following format: 

NB_COMMANDS number

For example: 

PROTOCOL TCPIP
  IP_ADDRESS 129.47.6.84 
  . 
  . 
  NB_COMMANDS 16

You can specify a value from 0 through 80 for number. By default, number has the value of 8.

NB_DOMAIN domain_name

This parameter specifies the name of the logical domain for this NetBIOS station. All stations in the same logical domain must use the same value for NB_DOMAIN.

You can specify this setting using NB_DOMAIN in the following format: 

NB_DOMAIN domain_name

For example: 

PROTOCOL TCPIP
  IP_ADDRESS 129.47.6.84
  . 
  . 
  NB_DOMAIN BIOSPHERE_2

You can specify a string with up to 80 characters for domain_name. By default, domain_name has a null value.

NB_SESSIONS number

This parameter specifies the maximum number of concurrent NetBIOS sessions. Your TCP_SOCKETS setting must be at least 1 plus the number of sessions you specify with the NB_SESSIONS setting. You can specify a number from 0 through 64.

You can specify this setting using NB_SESSIONS in the following format: 

NB_SESSIONS number

For example: 

PROTOCOL TCPIP
  BIND NE1000
  IP_ADDRESS 129.47.6.84
  .
  .
  NB_SESSIONS 8

The default value for number is 4.

REMOTENAMEn IP_address

This parameter is included in the PROTOCOL RFCNBIOS section of the NET.CFG file. It specifies an IP address that is not on the same broadcast network as your workstation. This address is preloaded in the NetBIOS name cache.

You can specify the IP address with REMOTENAME in the following format: 

REMOTENAMEn IP_address

where n is the number you assign to an IP address, and IP_address is the IP address in decimal notation.

For example: 

PROTOCOL RFCNBIOS
  REMOTENAME1 129.57.52.6 
  REMOTENAME2 129.57.32.8

You can specify up to 16 remote names with this parameter.

Setting Up Multiple Network Interfaces

The TCP/IP Transport software can support up to four simultaneous network connections. You can install up to four network boards in your workstation and communicate simultaneously with networks of the same or different types.
Note: Configuring multiple network connections is not sufficient to designate a workstation as a router. A workstation connected to more than one network can communicate on each of the networks simultaneously, but it cannot route packets between these connections for other workstations.

You enable support for multiple networks by loading multiple ODI drivers and configuring them in the NET.CFG file. Depending on the network boards you install, you might load different ODI drivers or load the same ODI driver more than once. Each time you load an ODI driver, a separate LINK DRIVER section in the NET.CFG file provides the configuration parameters.

For example, if your workstation has both a token-ring network board and an NE2000 Ethernet network board, you can connect to two different networks. You need to load both TOKEN.COM and NE2000.COM. Your NET.CFG file would have two LINK DRIVER sections similar to the following: 

LINK DRIVER TOKEN 
  FRAME TOKEN-RING_SNAP

LINK DRIVER NE2000 
  INT #1 5 
  PORT #1 320 
  FRAME ETHERNET_II

You need only one LINK SUPPORT section to configure LSL.COM, which automatically supports both ODI drivers.

Each network connection has its own IP address and its own optional router address and subnetwork mask. In the PROTOCOL TCPIP section of NET.CFG, you need to designate which settings apply to each connection. To do this you assign a name to each network for use within NET.CFG. You can then use the name with each TCP/IP setting and use BIND statements to associate the settings with their network connections.

For example, you can assign the name FINANCE-NET to the token-ring connection, and assign MARKETING-NET to the Ethernet connection. You can then set up TCP/IP address settings for the two names: 

PROTOCOL TCPIP
  IP_ADDRESS     144.52.6.5     FINANCE-NET
  IP_ROUTER      144.52.6.6     FINANCE-NET
  IP_NETMASK     255.255.0.0    FINANCE-NET
  IP_ADDRESS     122.44.9.7     MARKETING-NET
  IP_ROUTER      122.44.3.97    MARKETING-NET
  IP_NETMASK     255.255.0.0    MARKETING-NET

You then use Bind to associate the appropriate driver (board instance) with its setting (network name): 

BIND TOKEN #1 TOKEN-RING_SNAP FINANCE-NET 
BIND NE2000 #1 ETHERNET_II MARKETING-NET

The BIND statement specifies the driver, board instance, frame format, and network name for each connection. In this example, two different ODI drivers are used, and each is the first instance of its board type.

The board instance numbers are used by BIND to distinguish different instances of the same ODI driver. They are not the same as the logical board numbers displayed by the ODI drivers when they are loaded. For example, if you have two ARCnet boards in your workstation, you load the TRXNET.COM driver twice, once to support each board. Board instance #1 is the first TRXNET.COM loaded into memory, and instance #2 identifies the second copy of TRXNET.COM in memory.

Note: When multiple network interfaces are configured and an application tries to reach a destination host that is outside the immediate networks of the interfaces connected, the protocol stack sends the packet through the default interface which is the first network specified in the NET.CFG file. This network is specified in the IP_ROUTER setting of the PROTOCOL TCPIP section.

Setting Up SLIP and PPP

The TCP/IP Transport software supports asynchronous serial line media by implementing the Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) in an ODI driver. SLIP and PPP operate on a workstation's COM devices. This driver supports the two most popular link layer protocols: SLIP and PPP. This support includes optional Van Jacobson TCP/IP header compression.

The following documents provide background information for the SLIP and PPP protocols.

The TCP/IP protocol stack receives the same functional support from the NCOMX and NWREMOTE drivers as from other LAN drivers except BOOTP and RARP. TCP/IP disables BOOTP and RARP support when TCP/IP is operating on the NCOMX and NWREMOTE drivers. When you use the SLIP frame type, the TCPIP driver does not load if the NET.CFG file does not specify an IP address. However, when you use the PPP frame type, the TCPIP driver loads in anticipation of IP address assignment from a remote host through PPP options negotiation.

The normal load sequence of the ODI driver should be followed when activating the protocol stack; that is, the NCOMX and NWREMOTE drivers must be loaded after the LSL driver but before the TCPIP driver. You can configure the NCOMX driver using parameter settings in the LINK DRIVER NCOMX section of your NET.CFG file. You can configure the NWREMOTE driver using parameter settings in the PROTOCOL NWREMOTE section of your NET.CFG file.

Note: For simple communications tasks, such as terminal access or file transfer, using TCP/IP over SLIP or PPP may be inefficient. It may be more effective to use a direct serial connection with terminal emulators and Kermit or Zmodem type protocols for file transfer. However, if you plan to use more sophisticated network services or connect to an internetwork, TCP/IP over SLIP or PPP is very effective.

A workstation-to-LAN or workstation-to-internetwork connection is the most probable configuration for the NCOMX and NWREMOTE drivers. A user with a personal computer at home or in a dormitory or remote office, or with a laptop while traveling, can dial in to the company or university LAN and instantly become the equivalent of a local workstation on the LAN. A remote user can access the same services that are available to the local workstation and gain Internet access if Internet service is available. A dial-up router using either the SLIP or PPP protocol is required on the LAN side.

Applications Running over the NCOMX Driver

For NCOMX to run reliably in MS Windows 386 enhanced mode, a COM device based on 16550A UART (Universal Asynchronous Receiver/Transmitter) is recommended. The 16550 includes a FIFO (first in, first out) buffer that improves throughput and reduces interrupt overhead. If you experience errors when using COM devices based on the slower 8250 or 16450 UART, try to lower the communication line speed by setting a lower baud rate value. Also, lowering the maximum receive and transmit unit (MAXIMUM FRAME SIZE) size in your NET.CFG file might correct the problem.

Loading the NCOMX Driver

The NCOMX driver must be loaded after the LSL driver but before the TCPIP driver. You must configure SLIP or PPP by setting parameters in your NET.CFG file. A sample NET.CFG file for the NCOMX driver is shown in the following example.

Sample Serial Port Settings in the NET.CFG File

LINK DRIVER NCOMX
      INT 4
      PORT 3F8
      BAUD 9600
      FRAME SLIP

NET.CFG Settings for the NCOMX Driver

The serial port has several LINK DRIVER NCOMX settings in addition to those illustrated in the previous example. All serial port settings are summarized in Table 2-10 and described in the following section.

NET.CFG Settings for NCOMX Driver
Keyword  Value  Default  Description 
FRAME  SLIP or PPP  PPP  This setting defines frame type on serial line media. Select SLIP or PPP. 
BAUD  300, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200  9600  This setting specifies the serial line speed in decimal format. 
INT  IRQ level  4  This setting specifies the interrupt level of the COMn: device. 
MAX FRAME SIZE n [ m]    1500  This setting specifies the maximum receive and transmit unit for SLIP_PPP where n is bytes in decimal; the valid range is 76 through 1500 bytes. The optional parameter m instructs SLIP_PPP to assume the largest receive size character mapping scenario. 
PORT  Base I/O address  3F8  This setting specifies the default address. By default, PORT is 3F8 and INT is 4 (COM1 settings)

LINK DRIVER NCOMX Settings

The NCOMX driver is customized in the LINK DRIVER section of the NET.CFG file.

The following NET.CFG settings are common to NCOMX:

The following paragraphs describe these NET.CFG settings.

BAUD

The BAUD setting lets you select a baud rate for the NCOMX driver to use. For example: 
LINK DRIVER NCOMX
  INT 4
  PORT 3F8 
  BAUD 9600 
  FRAME SLIP

The default value is 9600 baud.

FRAME

The FRAME setting lets you select either the SLIP or the PPP protocol. SLIP defines a sequence of characters that frame IP packets on a serial line. It provides no addressing, packet type identification, error detection or correction, or compression. PPP conveys multiple protocol packets on the same point-to-point link and provides error detection. For example: 
LINK DRIVER NCOMX 
  INT 4 
  PORT 3F8 
  BAUD 9600
  FRAME SLIP

The default valueis PPP.

MAX FRAME SIZE n [ m ]

The MAX FRAME SIZE setting lets you specify the maximum receive and transmit units for the SLIP or PPP protocol.

The MAX FRAME SIZE value (format of n [ m ]) is a decimal number within the range of 76 through 1500 bytes. The optional parameter m (for mapped) instructs the NCOMX driver to assume the worst case character mapping scenario where every data byte in a packet could be mapped into two bytes as required by the ACCM configuration (for example, a 500-byte packet could double its size to 1000 bytes). NCOMX uses half of the mru as its largest receive size, and the protocol stack uses that as the maximum datagram size it can send. The optional parameter m applies to PPP only. For example: 

LINK DRIVER NCOMX 
  INT 4 
  PORT 3F8 
  BAUD 9600
  MAX FRAME SIZE 1500 
  FRAME SLIP

The default value is 1500 for PPP and 1006 bytes for SLIP.

INT

The int setting lets you specify the interrupt request line of your COMn: device for the NCOMX driver. For example:
LINK DRIVER NCOMX INT 3 PORT 2F8 BAUD 9600 FRAME SLIP

The default value is 4.

PORT

The PORT setting lets you specify the base I/O address of your COMn: device for the NCOMX driver to use. For example: 
LINK DRIVER NCOMX 
  INT 4 
  PORT 3F8 
  BAUD 9600
  FRAME SLIP

The default value is 3F8.

The normal interrupt levels and port I/O addresses for COMn: ports are as follows:

  Int (Interrupt) Port
COM1: 4 3F8
COM2: 3 2F8
COM3: 4 3E8
COM4: 3 2E8

NET.CFG Settings for the NWREMOTE Driver

The NWREMOTE has several PROTOCOL settings in addition to those illustrated earlier. All NWREMOTE settings are summarized in the table below and are described in the following section.

NET.CFG Settings for NWREMOTE
Keyword  Value  Default  Description 
ACCM [ REMOTE ] map_number  map_number  ffffffff  The four-byte hexadecimal map number specifies an asynchronous control character map. 
ACCOMP [ REMOTE ] { YES | NO }    No  This setting enables or disables the PPP frame address and control fields compression. 
PCOMP [ REMOTE ] { YES | NO }    No  This setting enables or disables the PPP frame protocol field compression. 
AUTHEN [ REMOTE ] PAP username password    None  This setting enables and defines Password Authentication Protocol (PAP) usernames and passwords. 
COUNTER timeout max_config max_term max_nak [ protocol ]      The values are defined as follows: 
  timeout  3  timeout - restart timer timeout in seconds 
  max_config  10  max_config - retry counter for configuration-request 
  max_term  2  max_term - retry counter for terminate- request 
PAP does not use max_term. 
  max_nak  10  max_nak - retry counter for configuration-nak 
  protocol    protocol can be TCP, IPCP, or PAP. 
IPADDR [ REMOTE ] IP_address    None  This setting specifies the IP addresses in dotted notation for negotiation. 
MAGIC [ REMOTE ] seed_number    Not enabled  This setting specifies the initial seed number for process recognition. 
TCPIPCOMP [ REMOTE ] { VJ | NO } [ slots ] [ comp_slot ]      This setting enables or disables the Van Jacobson (VJ) header compression as follows: 
VJ or No - compress or do not compress 
    slots = 16  slot - 1 through 16 conversation slots 
    comp_slot = 0  comp_slot - do not compress slot ID (0) or compress slot ID (1)

Protocol NWREMOTE Settings

The following NET.CFG settings are specific to NWREMOTE:

The ACCM, ACCOMP, IPADDR, MAGIC, PCOMP, and TCPIPCOMP settings use the remote variable. If you do not specify remote, the setting defaults to local. The remote specifier instructs NWREMOTE to use the value entered in response to the remote site configuration requests.

ACCM [ REMOTE ] map_number

The ACCM [ REMOTE ] setting lets you specify whether the PPP protocol should use the asynchronous control character map (ACCM). ACCM is a configuration option that provides a way to negotiate the use of control characters (0x0 through 0x1F) for mapping on an asynchronous link.

When sending data, each character with a value less than 0x20 that is flagged in the remote ACCM is replaced by a 2-byte sequence consisting of the Control-Escape character (0x7D) and the original character with bit 6 complemented. Conversely, when receiving, the mapped 2-character sequence is converted back to the original character.

The eight hexadecimal bytes in ACCM use bit numbering from 31 to 0 from left to right. Each numbered bit corresponds to a control character with the same number value. When the bit is set to 0, the character does not need to be mapped; when the bit is set to 1, the character needs to be mapped.

The following example asks the remote host to map the escape XON (0x11) and XOFF (0x13) characters. For example: 

PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 000A0000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255

XON and XOFF have decimal values of 17 and 19, respectively, and the 17th and 19th bits of ACCM are set to one to request the remote host to send the appropriate 2-character sequences (0x7d, 0x31 and 0x7d, 0x33) when an XON or XOFF is encountered in the data packet. The default value is ffffffff.

ACCOMP [ REMOTE ] { YES | NO }

The ACCOMP [ REMOTE ] setting lets you instruct the NWREMOTE driver to compress the address and control field of the PPP header. For example: 
PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255

The default value is No.

AUTHEN [ REMOTE ] PAP username password

The AUTHEN setting lets you specify whether the PPP protocol should use authentication. If selected, PPP uses the name and password to identify the local system to the peer. This process is based on the Password Authentication Protocol (PAP). If you specify the REMOTE option, PPP uses username and password to authenticate the login username in the NET.CFG file. For example: 
PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 

  ACCOMP YES 

  AUTHEN PAP BRIAN BANG 

  MAGIC 1234FFFF 

  IPADDR 155.55.5.255

COUNTER   protocol   timeout   max_config   max_term   max_nak

The COUNTER setting lets you specify a timeout value and three retry counters for the PPP protocol. All values are in decimal format.

The protocol parameter can be any of the following:

If you do not specify the protocol, changes are applied to all protocols.

For example: 

PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255
timeout The timeout value for restarting the transmission of request packets. The default value is 3 seconds.
max_config The number of retries for sending a configuration request. The default value is 10 times.
max_term The number of retries for sending a terminate request. The max_term value is not used by PAP. The default value is 2 times.
max_nak The number of retries for sending a configuration NAK. The default value is 10 times.

IPADDR [ REMOTE ] IP_address

The IPADDR [ REMOTE ] setting lets you specify the IP addresses for PPP negotiation (in dotted decimal notation). If you specify the REMOTE option, PPP tries to assign the address to the remote host if the remote host did not specify an address to use in its configuration request. For example: 
PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255

There is no default value for this setting. If you specify 0.0.0.0, PPP determines your IP address from the remote end.

MAGIC [ remote ] seed_number

The MAGIC [ REMOTE ] setting provides a way to detect looped-back links and other datalink anomalies. The NWREMOTE driver uses the value you specify as a seed number to generate a unique number to identify itself. If you specify REMOTE, PPP tries to get the peer to use the number specified (that is, if the peer does not indicate that it will use the magic number in its initial configuration request). The MAGIC setting is a 4-byte hexadecimal number. For example: 
PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255

The default value is not to use the magic setting.

TCPIPCOMP [ REMOTE ] { VJ | NO } [ slots | comp_slot ]

The TCPIPCOMP setting enables or disables the Van Jacobson (VJ) TCP/IP header compression for the SLIP or PPP protocol as follows:

The format is as follows: 

tcpipcomp {VJ
| NO} [slots comp_slot]

If you specify NO (for no compression), you can omit the slots and comp_slot values. If you specify these values with the NO option, they are ignored. For example: 

PROTOCOL NWREMOTE
  TCPIPCOMP VJ 16 1 
  COUNTER LCP 5 10 5 10 
  ACCM 00000000 
  ACCOMP YES 
  MAGIC 1234FFFF 
  IPADDR 155.55.5.255

The default values for TCPIPCOMP are 16 slots and 0 (no compression).

Setting Up the SNMP Agent

SNMP is a Simple Network Management Protocol (SNMP) agent TSR program. It lets a remote Network Management Station (NMS) monitor the TCP/IP protocol stack running on the workstation. SNMP allows remote and local SNMP clients complete access to the TCP/IP portion of the Management Information Base (MIB). SNMP supports the MIB-II variables.

To use the LWPCON utility to access SNMP, see "Running LWPCON". LWPCON does not require the SNMP agent to be running on the workstation to return local statistics. The SNMP TSR is required if you want remote SNMP client programs to be able to gather statistics from your workstation.

The SNMP protocol is fully described in RFC 1157, Simple Network Management Protocol (SNMP). The MIB-II standard is described in RFC 1213, Management Information Base for Network Management of TCP/IP-Based Internets: MIB-II.

To use the SNMP agent on a workstation, you must first load and bind TCP/IP to the interface it will be using. The typical loading sequence is as follows: 

LSL 
NE2000 (or appropriate driver) 
TCPIP 
SNMP

The agent is a terminate and stay resident (TSR) program that can be loaded by typing the following command: 

SNMP <Enter>

To remove the agent from memory, type the following command: 

SNMP U <Enter>

You configure the SNMP agent by adjusting settings in the NET.CFG file. If NET.CFG is not configured for SNMP, it runs with the MonitorCommunity variable set to public (all clients can read the MIB values) and ControlCommunity set to disabled (client write access to the MIB values is not allowed).

SNMP NET.CFG Summary

There are five SNMP settings under the Protocol SNMP section of the NET.CFG configuration file. This table summarizes the valid and default values of these settings:

NET.CFG Settings for SNMP
Parameter  Explanation 
SYSCONTACT  This parameter specifies the name of the person who is responsible for this machine. Normally, this will be the name of the person using the machine. 
SYSNAME  This parameter specifies the full domain name. 
SYSLOCATION  This parameter specifies the physical location of the machine. 
MONITORCOMMUNITY  This parameter sets the community name for read-only access. By default, this community is public. 
CONTROLCOMMUNITY  This parameter sets the community name for read and write access. By default, this community is disabled.

Community Names

Community names are used to authenticate SNMP request messages received at the agent. The community name in a message requesting a given access type must match the name defined for that access type by one of the SNMP community options.

Community names are arbitrary 32-character text strings. You can use the string noAccess to disable the appropriate community. This name is reserved and is not case sensitive.

SNMP Operations

The SNMP protocol allows four operations:

The Trap operation has not been implemented in this release.

Authentication

SNMP defines a community as a relationship between an SNMP agent and one or more SNMP managers. At the present, only trivial authentication mechanisms are available with SNMP. This means that the community name is placed, in clear text, in an SNMP message. If the community name corresponds to a community known to the receiving SNMP entity, the sending SNMP entity is considered to be authenticated as a member of that community.

The SNMP agent lets you specify any community names you require. Two different communities are used by the agent. The monitor community is used for read-only access; the control community is used for read-write access. If the community name is not known to the agent, the request from the SNMP manager station is ignored.

By default, the monitor community is set to public and the control community is disabled. To override these default settings, edit the NET.CFG file.

Example NET.CFG Configurations

This section contains examples of NET.CFG files set up for different purposes. You can copy the appropriate parts of these examples into your workstation's NET.CFG file if you have a similar configuration.

This section provides the following examples:

Token Ring Configuration

The following example shows how to configure NET.CFG for a token ring TCP/IP network using the TOKEN.COM driver. IPX support is not configured in this example. The frame type used on token ring TCP/IP networks is always TOKEN-RING_SNAP. The increased buffer size (4202) is recommended only if problems are encountered using the default size (1500).

Sample NET.CFG File for Token Ring

LINK DRIVER TOKEN
       FRAME TOKEN-RING_SNAP 

LINK SUPPORT 
       BUFFERS 8 4202 
       MEMPOOL 4096 

PROTOCOL TCPIP
       PATH TCP_CFG        C:\NET\TCP
       IP_ADDRESS          144.52.6.5
       IP_ROUTER           144.52.6.6
       IP_NETMASK          255.255.0.0

ARCnet Configuration

The following example shows how to configure NET.CFG for an ARCnet network. IPX support is not configured in this example. This example uses a TRXNET board with NOVELL_RX-NET frame format, which is the frame format always used on ARCnet TCP/IP networks.

Sample NET.CFG File for ARCnet

LINK DRIVER TRXNET
       FRAME NOVELL_RX-NET

LINK SUPPORT
       BUFFERS 8 1500
       MEMPOOL 4096

PROTOCOL TCPIP
       PATH TCP_CFG        C:\NET\TCP
       IP_ADDRESS          144.52.6.5
       IP_ROUTER           144.52.6.6
       IP_NETMASK          255.255.0.0

SLIP and PPP Configurations

This section includes examples of the NET.CFG file for SLIP and PPP frame types.

The following example provides an sample NET.CFG file using SLIP frame type.

NET.CFG File Using SLIP Frame Types

LINK SUPPORT
      BUFFERS          8 1500
      MEMPOOL          4096

LINK DRIVER NCOMX
      INT              4 
      PORT             2F8 
      BAUD             2400
      FLOW CONTROL     1 
      MAX FRAME SIZE   800
      FRAME            SLIP

PROTOCOL NWREMOTE
      TCPIPCOMP        VJ 16 1
      COUNTER          LCP 5 10 5 10
      ACCM             00000000
      ACCOMP           YES
      MAGIC            1234FFFF
      IPADDR           129.47.236.1

PROTOCOL TCPIP  PATH TCP_CFG     C:\NET\TCP
      IP_ADDRESS       129.47.236.1
      IP_NETMASK       255.255.255.0 
      IP_ROUTER        129.47.236.11
      TCP_SOCKETS      8
      UDP_SOCKETS      8
      RAW_SOCKETS      1

The configuration in the previous example installs NWREMOTE to run on COM1: at 2400 baud, use a maximum packet size of 800 bytes, and enable Van Jacobson Header Compression.

SLIP is not capable of exchanging configurations, so the configurations have to be set statically and pre-agreed upon among peers. Configuration values such as max frame size and whether VJ compression are used need to be set to match the peer values.

The following example shows the NET.CFG file using the PPP frame type.

NET.CFG File Using PPP Frame Type

Link Support
      Buffers             8 1500
      MemPool             4096

LINK DRIVER NCOMX
      INT                 4
      PORT                3F8
      BAUD                9600
      FLOW CONTROL        1
      MAX FRAME SIZE      1000
      FRAME               PPP 

PROTOCOL NWREMOTE
      TCPIPCOMP           VJ 16 1
      COUNTER             LCP 5 10 5 10
      ACCM                00000000
      ACCOMP              YES
      MAGIC               1234FFFF
      IPADDR              0.0.0.0 

PROTOCOL TCPIP
      TCP_SOCKETS         8
      UDP_SOCKETS         8
      RAW_SOCKETS         1

The configuration in the previous example installs NCOMX to run on COM2: at 9600 baud, uses a maximum packet size of 1000 bytes, and sends the following information about the local workstation to the remote host.

The NCOMX driver will run on directly connected null-modem lines.

PPP negotiates link layer and network layer configurations among peers. The NET.CFG file in the previous example requests that the peer assign an IP address for you to use (no local IP_ADDRESS is specified under PROTOCOL TCPIP). The protocol stack TCP/IP will use the negotiated local and remote IP addresses to set its operating IP address, IP net mask, and router IP address. They are not statically configured in the PROTOCOL TCPIP section of the NET.CFG file.

SNMP Agent Configuration

The following example shows the NET.CFG file for configuring the SNMP agent.

NET.CFG with SNMP Settings

LINK SUPPORT
       BUFFERS                8 1500
       MEMPOOL                4096

PROTOCOL TCPIP
       BIND                   NE2000

PROTOCOL SNMP
       MONITORCOMMUNITY       PUBLIC
       CONTROLCOMMUNITY       NOVELLADMIN
       SYSCONTACT             HORACE FELTON
       SYSNAME                HORACEF@SUCCESS.COM
       SYSLOCATION            BUILDING #1 - OFFICE 209 

LINK DRIVER NE2000
       FRAME                  ETHERNET_II

Multiple Network Configuration

The following example shows a NET.CFG file set up to configure two different network connections, one through an NE2000 Ethernet board and one through asynchronous serial ports.

Example NET.CFG File for Multiple Network Connections

LINK SUPPORT
      BUFFERS 8 1500
      MEMPOOL 4096 

LINK DRIVER NE2000
      INT              5
      PORT             300
      MEM              D0000
      FRAME            ETHERNET_II
      PROTOCOL IPX 8137 ETHERNET_II 

LINK DRIVER NCOMX
      INT              4
      PORT             3F8
      BAUD             19200
      FLOW CONTROL     1
      MAX FRAME SIZE   1500
      FRAME            PPP

PROTOCOL NWREMOTE
      TCPIPCOMP        VJ 16 1
      COUNTER          LCP 5 10 5 10
      ACCM             00000000
      ACCOMP           YES
      MAGIC            1234FFFF
      IPADDR           129.47.236.12.3

PROTOCOL TCPIP 
      TCP_SOCKETS      8
      UDP_SOCKETS      8
      RAW_SOCKETS      1
      IP_ADDRESS       0.0.0.0           LOCAL-NET
      IP_ADDRESS       93.57.6.168       ENGINEERING-NET
      IP_ROUTER        93.57.4.254       ENGINEERING-NET
      IP_NETMASK       255.255.0.0       ENGINEERING-NET
      BIND NCOMX #1 PPP LOCAL-NET
      BIND NE2000 #1 ETHERNET_II ENGINEERING-NET

This NET.CFG file does the following:

The batch file that loads the drivers configured by this NET.CFG file loads both the NE2000.COM and the NCOMX driver, as in the following example.

Example Batch File for Multiple Network Connections

C:\YESNO "DO YOU WANT TO LOAD THE NETWORKING SOFTWARE?" 
IF ERRORLEVEL 1 GOTO NOLOAD 
PATH C:\NET\BIN;%PATH% 
C:\LSL.COM 
C:\NESL.COM 
C:\NE2000.COM 
C:\NCOMX.COM 
C:\NWREMOTE.COM 
TCPIP.EXE 
IPXODI.COM 
VLM.EXE 
:NOLOAD

When the batch file is executed, sign-on messages similar to the ones shown in the following example are displayed.

Example Sign-On Display for Multiple Network Drivers

NOVELL TCP/IP TRANSPORT V4.1 (920910)
(C) COPYRIGHT 1992 NOVELL, INC. ALL RIGHTS RESERVED 
NETWORK NAME: ENGINEERING-NET  BIND: NE2000 
IP ADDRESS:93.57.6.168         BOARD NUMBER: 1
SUBNET MASK: 255.255.0.0       BOARD INSTANCE: 1 
DEFAULT ROUTER: 93.57.4.254    FRAME: ETHERNET_II 
NETWORK NAME: LOCAL-NET        BIND: NCOMX 
IP ADDRESS: 122.44.9.7         BOARD NUMBER: 2 
SUBNET MASK: 255.255.0.0       BOARD INSTANCE: 1 
DEFAULT ROUTER: 122.44.3.97    FRAME: PPP

Concurrent TCP/IP and IPX Configurations

ODI supports concurrent TCP/IP and IPX protocol stacks. The LINK DRIVER section of the NET.CFG file must be modified if you plan to run both TCP/IP and IPX.

The following example is a sample NET.CFG file for using TCP/IP and IPX in an Ethernet configuration (ECONFIG) environment. In this example, both IPX and TCP/IP use the ETHERNET_II frame format.

Sample NET.CFG File for Concurrent TCP/IP and IPX Over Ethernet

LINK DRIVER NE1000
        INT #1 5
        PORT #1 320
        FRAME ETHERNET_II                   # ALLOW ETHERNET II PACKETS 

LINK SUPPORT
        BUFFERS 8 1500
        MEMPOOL 4096

PROTOCOL TCPIP
        PATH TCP_CFG         C:\NET\TCP
        IP_ADDRESS           129.47.6.129 
        IP_ROUTER            129.47.4.254
        IP_NETMASK           255.255.0.0

The following example shows a sample NET.CFG file for using TCP/IP and IPX in the default Ethernet 802.3 environment. The following line configures IPX to run over Ethernet 802.3: 

PROTOCOL IPX
0 ETHERNET_802.3

A Protocol IPX setting must be present to run IPX with TCP/IP when IPX is operating in an Ethernet 802.3 environment. In this example, TCP/IP uses the ETHERNET_II frame format, and IPX uses the ETHERNET_802.3 frame format.

Sample NET.CFG File for Concurrent TCP/IP and IPX Over Ethernet 802.3

LINK DRIVER NE1000
       INT #1 5
       PORT #1 320
       FRAME ETHERNET_II                # ALLOW ETHERNET II PACKETS
       FRAME ETHERNET_802.3             # ALLOW 802.3 PACKETS
       PROTOCOL IPX 0 ETHERNET_802.3    # MAKE IPX USE 802.3 

LINK SUPPORT
       BUFFERS 8 1500
       MEMPOOL 4096 

PROTOCOL TCPIP
       PATH TCP_CFG           C:\NET\TCP
       IP_ADDRESS             129.47.6.129
       IP_ROUTER              129.47.4.254
       IP_NETMASK             255.255.0.0

The following example shows how to configure NET.CFG for a token ring network running both TCP/IP and IPX. In this example, TCP/IP uses the TOKEN-RING_SNAP frame format and IPX uses the TOKEN-RING frame format.

Sample NET.CFG File for Concurrent TCP/IP and IPX Over Token Ring

LINK DRIVER TOKEN
       FRAME TOKEN-RING_SNAP
       FRAME TOKEN-RING
       PROTOCOL IPX E0 TOKEN-RING

LINK SUPPORT
       BUFFERS 8 4202
       MEMPOOL 4096 

PROTOCOL TCPIP
       PATH TCP_CFG      C:\NET\TCP
       IP_ADDRESS        144.52.6.5 
       IP_ROUTER         144.52.6.6 
       IP_NETMASK        255.255.0.0

 

 
Top     Introduction     Utilities