# Intel Network Drivers for DOS

## DOS Driver

The NDIS2 (DOS) driver is provided solely for the purpose of loading other operating systems -- for example, during RIS or unattended installations. It is not intended as a high-performance driver.

You can find adapter drivers, PROTOCOL.INI files, and NET.CFG files in the DOS directory on the Intel CD. For additional unattended install information, see the README files in the APPS\SETUP\PUSH directory.

### Automatic or Explicit Configuration of a Single NIC or Multiple NICs

When the driver finds that there is only one adapter in the system, it will use that adapter regardless of whether or not parameters in PROTOCOL.INI are present or correct. If the values of certain parameters do not match the actual configuration, warning messages are displayed to indicate that the parameter value was not used, and that the default value for the parameter has been used instead. For example, if the user specifies a SLOT parameter and the adapter is in a different slot, messages are displayed by the driver instructing the user to fix the PROTOCOL.INI information; the driver proceeds to function normally loading on the driver instance name. See the next section for more information.

One instance of the driver must be loaded for each adapter that is activated. When multiple adapters are installed, the SLOT parameter becomes advisable but not required.

A “multiple-adapter” configuration is defined as a system with one or more PCI buses, with more than one adapter installed in any combination of buses. From the driver’s viewpoint, a system with two PCI adapters and two PCI buses, with both installed in only one of the buses, is indistinguishable from a system with two adapters and two PCI buses where each adapter has been installed in a different bus. In fact, the user may not know if there are multiple buses, but just sees PCI slots on the motherboard.

The determination as to which adapter each driver will control should be made by the user based on the protocol stack(s) bound to each driver, and based on the network that is connected to each adapter. The “BINDINGS” list in each protocol stack’s PROTOCOL.INI section establishes the relationship between protocol stacks and drivers. The SLOT parameter in the driver’s PROTOCOL.INI section establishes the relationship between drivers and adapters, and a value can be provided for each driver loaded. If a SLOT parameter is not specified, the first driver instance will load on the first NIC/Port found in the scanning list, the second driver instance will load on the second NIC/Port found in the scanning list, etc. When the driver detects multiple NICs/Ports it will report all of the possible slots. The only way for the driver to know which driver instance is being loaded is to use the DRIVERNAME parameter instance number. Therefore, it is essential that the DRIVERNAME parameter instance syntax defined below be used correctly.

The adapters are automatically configured by the PCI system BIOS when the system boots. The driver queries the PCI BIOS and obtains all of the adapter’s configuration information. BIOS scanning using mechanisms 1 and 2, as defined in the PCI BIOS specification, are supported. The SLOT number is actually the encoded value of the PCI adapter’s device location, which is defined as shown below. The SLOT value reported by the driver and entered by the user is the value of bits 0 through 15. In versions of the driver prior to 2.01, the SLOT value reported by the driver and entered by the user was shifted right by 3 bits (divided by 8) so that SLOT 0x0088 was actually entered into PROTOCOL.INI as 0x0011. This doesn’t allow for multi-function devices to be specified with this SLOT parameter. So starting with v2.01, the driver does not shift the input parameter by 3 bits and SLOT 0x0088 would be entered as 0x0088. This also allows for specifying slot 0x0081 = Bus 0 Device 16 Function 1. If the driver finds that the entered SLOT number is not found in its slot list table, it may be because the SLOT uses the older convention (shifted right). The driver then tries to match this old style slot parameter to a slot in the slot list and loads on that slot if it finds a match. This is done for backward compatibility.

15 8 | 7 3 | 2 0
Bus Number | Device Number | Function Number

###

### Configuring with the PROTOCOL.INI File

The configuration parameters listed below are supported through the PROTOCOL.INI file. When the machine has a single adapter, all the parameters are optional; when the machine has multiple adapters, some of the parameters are required.

#### DRIVERNAME

This is the only parameter required for all configurations. This parameter is essentially an “instance ID”. Each instance of the driver must create a unique instance name, both to satisfy DOS and OS/2 driver requirements, and to make it possible to find the parameters for the instance in the PROTOCOL.INI file.

When the driver initializes, it tries to find previously loaded instances of itself. If none is found, the driver calls itself “E1000$”, and looks for that name in the PROTOCOL.INI file to find its parameters. If one or more instances are found, the driver calls itself “E100x$”, where ‘x’ is one more than the value used by the most recently loaded instance. So, in this scenario, the second driver calls itself “E1002$”, the third calls itself “E1003$”, and so on; there is no driver called "E1001$". Up to 10 drivers can be loaded in a single system in this way.

Syntax: | DRIVERNAME = [E1000$ | E1002$ | etc.]
Example: | DRIVERNAME = E1000$
Default: | None, this is a required parameter.
Normal Behavior: | The driver finds its section in PROTOCOL.INI by matching its instance ID to the value for this parameter.
Possible Errors: | The device driver uses a DOS and OS/2 function to display the name of the driver it is expecting. This function cannot display a ‘$’ character. For this reason, the user may see a message referring to this value with the ‘$’; the user must remember to enter the ‘$’ character as part of the parameter’s value.

#### SPEEDDUPLEX

The parameter disables Auto-Speed-Detect and causes the adapter to function at the speed indicated.

Syntax: | SPEEDDUPLEX = [0 | 1 | 2 | 3]
Example: | SPEEDDUPLEX = 2
Default: | Auto-Speed-Detect
Normal Behavior: | 0 = 10Mbps half duplex 1 = 10Mbps full duplex 2 = 100Mbps half duplex 3 = 100Mbps full duplex
Possible Errors: | If the SPEEDDUPLEX parameter is set to an invalid value: - the parameter is ignored and the default (Auto-Speed-Detect) is used - a message indicates a “Parameter value out of range” error

#### SLOT

This parameter makes it possible for the driver to uniquely identify which of the adapters is to be controlled by the driver. The parameter can be entered in hexadecimal or decimal.

Syntax: | SLOT = [0x0..0x1FFF] SLOT = [0..8191]
Examples: | SLOT = 0x1C SLOT = 28
Default: | The driver will Auto-Configure if possible.
Normal Behavior: | The driver uses the value of the parameter to decide which adapter to control.
Possible Errors: | If only one adapter is installed, and the value does not correctly indicate the adapter slot: - a message indicates that the value does not match the actual configuration - the driver finds the adapter and uses it If more than one adapter is installed, and the value does not correctly indicate an adapter slot: - a message indicates possible slots to use - the driver loads on the next available slot

#### NODE

This parameter sets the Individual Address of the adapter, overriding the value read from the its EEPROM.

Syntax: | NODE = “12 hexadecimal digits” The value must be exactly 12 hexadecimal digits, enclosed in double quotes. The value can not be all zeros. The value can not have the Multicast bit set (LSB of 2nd digit = 1).
Example: | NODE = “00AA00123456”
Default: | Value from EEPROM installed on adapter
Normal Behavior: | The Current Station Address in the NDIS MAC Service-Specific Characteristics (MSSC) table is assigned the value of this parameter. The adapter hardware is programmed to receive frames with the destination address equal to the Current Station Address in the MSSC table. The Permanent Station Address in the MSSC table will be set to reflect the node address read from the adapter’s EEPROM.
Possible Errors: | If any of the rules described above is violated, an error message indicates the rules for forming a proper address, and the driver treats this as a fatal error.

#### CACHEFLUSH

Windows NT bypasses the normal driver “hooks” into the reboot sequence during a “push install” so the driver is unaware of a system boot occurring. Hence the driver may copy incoming frames to host memory during system initialization. This will cause unpredictable behavior (most likely the system will halt). Setting this parameter to any non-zero value enables a disk-cache flush monitor; which is an alternate method of watching for a reboot call. This parameter should not be used under normal circumstances.

| NOTE: This situation is not being corrected.

Syntax: | CACHEFLUSH = [0 | 1]
Example: | CACHEFLUSH = 1
Default: | 0
Normal Behavior: | Use this parameter during a remote installation or “push-install” of Windows NT.
Possible Errors: | Any nonzero value sets this parameter to 1. The driver does not give any outward indication of the value of this parameter.

#### ADVERTISE

This parameter can be used to restrict the speeds and duplexes advertised to a link partner during auto-negotiation. If AutoNeg = 1, this value is used to determine what speed and duplex combinations are advertised to the link partner. This field is treated as a bit mask.

Syntax: | ADVERTISE = [ 1 | 2 | 4 | 8 | 0x20]: 0x01 = 10H 0x02 = 10F 0x04 = 100H 0x08 = 100F 0x20 = 1000F
Example: | ADVERTISE = 1
Default: | 0x2F (all rates are supported)
Normal Behavior: | By default all speed/duplex combinations are advertised.
Possible Errors: | An error message is displayed if the value given is out of range.

#### FLOWCONTROL

This parameter, which refers to IEEE 802.3x flow control, helps prevent packets from being dropped and can improve overall network performance. Specifically, the parameter determines what flow control capabilities the adapter advertises to its link partner when auto negotiation occurs. This setting does NOT force flow control to be used. It only affects the advertised capabilities.

| NOTE: Due to errata in the 82542 silicon the chip is not able to receive PAUSE frames if the ReportTxEarly parameter is set to 1. Thus, if ReportTxEarly =1 and the driver is running on an adapter using this silicon, (such as the PWLA8490) the driver will modify the FlowControl parameter to disable the ability to receive PAUSE frames.
| NOTE: If half-duplex is forced or auto-negotiated, the driver will completely disable flow control.

:

Syntax: | FLOWCONTROL = [ 0 | 1 | 2 | 3 |0xFF]
Example: | FLOWCONTROL = 1
Default: | 3
Normal Behavior: | 0 = Disabled (No flow control capability) 1 = Receive Pause Frames (can receive and respond to PAUSE frames) 2 = Transmit Pause Frames (can send PAUSE frames) 3 = Both Enabled (can send and receive PAUSE frames) 0xFF = Hardware Default.
Possible Errors: | An error message is displayed if the value given is out of range.

#### SMARTPOWERDOWN

This parameter enables the Smart Power Down feature under OS/2. This feature is disabled by default on all devices except where the Device ID = 0x101E. On these devices, this feature is enabled by default.

Enabling this feature causes the software to put the device into a low power (D3) state when the link is disconnected. When the link is reconnected, the device is brought back to the D0 state.

Syntax: | SmartPowerDown = [ 0 | any other value ]
Example: | SmartPowerDown = 1
Default: | 0 except when device ID = 0x101E
Normal Behavior: | 0 = Disabled, any other value = Enabled
Possible Errors: | None

#### APMPOWERDOWN

This parameter enables the driver to put the device into the low power (D3) state on a "suspend" under OS/2. That feature is enabled by default on all NICs; this parameter provides a way to disable it.

Syntax: | APMPowerDown = [ 0 | any other value ]
Example: | APMPowerDown = 0
Default: | 1
Normal Behavior: | 0 = Disabled, any other value = Enabled
Possible Errors: | None

#### USELASTSLOT

This parameter causes the driver to load on the device in the last slot found in the slot scan. The default behavior of the driver is to load on the first adapter found in the slot scan. This parameter forces the driver to load on the last one found instead.

Syntax: | UseLastSlot = [ 0 | any other value ]
Example: | USELASTSLOT = 1
Default: | 0
Normal Behavior: | 0 = Disabled, any other value = Enabled
Possible Errors: | None

#### TXLOOPCOUNT

This parameter controls the number of times the transmit routine loops while waiting for a free transmit buffer. This parameter can affect Transmit performance.

Syntax: | TXLOOPCOUNT = <32-bit value>
Example: | TXLOOPCOUNT = 10000
Default: | 1000
Normal Behavior: | Default
Possible Errors: | None

## DOS ODI Client Driver

This driver is provided solely for the purpose of loading an OS. It is not intended as a high-performance driver. Please limit use to 1-2 frame types.

Location of Drivers:
10/100 Mbit: \DOS\E100BODI.COM
Gigabit: \DOS\E1000ODI.COM (This directory also contains the PROTOCOL.INI file and NET.CFG file for gigabit adapters.)

| NOTE: If connection fails, set the Spanning Tree Protocol (STP) option on the switch to "off".
| NOTE: Novell no longer supports NETX.EXE or the VLM client software. However, as a convenience to Intel customers, a copy of NETX.EXE is provided on the Intel Configuration and Drivers CD. Intel recommends that you use the latest Novell Client32 software.
| NOTE: With dual-port adapters, the first port must be used before the second port.

### NETX General Installation

1. Copy the following files from the \DOS directory of the Intel media to the hard drive (NWCLIENT):

   - LSL.COM

   - E100BODI.COM (10/100 Mbit) or E1000ODI.COM (gigabit)

   - IPXODI.COM

   - NETX.EXE

2. Configure AUTOEXEC.BAT and NET.CFG based on the sample files below. NET.CFG should be in the same directory as the driver.

3. Reboot, and the client should connect to the server.

### VLM General Installation

The driver requires VLM client version 1.21.

1. Run install.exe on the workstation you are configuring.
   For the client version of IntranetWare 4.11, you can find Install.exe on the IntranetWare CD at:

> - \PRODUCTS\VLM\IBM_6\INSTALL.EXE

> - \PRODUCTS\VLMIP\IBM_6\INSTALL.EXE (the TCP/IP client)

> For the server version of IntranetWare 4.11, you can find Install.exe on the IntranetWare CD at:

> - \PUBLIC\CLIENT\DOSWIN
>   This option is not available on NetWare 3.12

> For 4.1 / 3.12 clients, you can find Install.exe on the NetWare Workstation for DOS disk. It must be version 1.21 or greater (supplied with IntranetWare 4.11). To ensure you are using the correct version, right-click Install.exe and then click Properties. Version information appears on the NetWare Version tab.

2. Follow the screen prompts including the following options:

   Prompt | Action
   Locate the directory on the hard drive for the client software | Default: C:\NWCLIENT You can specify another directory.
   Automatically update CONFIG.SYS and AUTOEXEC.BAT files? | Type Y or N
   If you are loading Windows, specify the directory where you would like to load Windows. | User defined
   Configure workstation for back-up by a NetWare server. | User defined

3. Select a network driver and set configuration options. Do NOT select a Driver from the list Novell provides; rather, choose OTHER DRIVER and insert the Intel adapter disk.

4. Select the Intel Adapter.

5. Optionally set:

   - Frame Type

   - Adapter Node Address

   - Force Duplex Mode

   - Line Speed

6. Install copies of the appropriate files to your hard drive and set NET.CFG. This is the final step.

| NOTE: Because some switches link more slowly than others, you may have to allow more time before running VLM. If you run VLM and do not get a valid connection, run vlm -u and then try running vlm again.

### TIPS (DOS ODI)

#### NETX

- In CONFIG.SYS add LASTDRIVE=E.

- In NET.CFG add FIRST NETWORK DRIVE F (or some drive letter after the range of physical devices you've installed) under the NetWare DOS REQUESTER section (indented).

#### VLM

- In CONFIG.SYS add LASTDRIVE=Z.

- In NET.CFG, add FIRST NETWORK DRIVE F under the NetWare DOS REQUESTER section (indented). If F is already assigned, select a drive letter after the range of physical devices you have installed.

- Promiscuous mode support is not supported since ASM does not include a receive monitor stack. If needed, load RXMONSTK.COM (from the VLM client kit) after LSL.COM and before E100BODI.COM or E1000ODI.COM.

- This version of E100BODI.COM or E1000ODI.COM requires VLM client version 1.21 or higher. Attempting to use an older version of the VLM client may cause connection problems, slow response or computer system lock-ups.

### 10/100 Mbit Sample Files

AUTOEXEC.BAT:

>     CD\NWCLIENT
>     LSL
>     E100BODI
>     IPXODI
>     NETX (or VLM optional for NetWare 3.12 or higher)

NET.CFG:

>     LINK DRIVER E100BODI
>     FRAME ETHERNET_802.2 (generally NetWare 3.12 and later servers)
>     ;FRAME ETHERNET_802.3 (generally NetWare 3.11 and earlier)
>     SPEED=100
>     PROTOCOL IPX EO Ethernet_802.2

>     NETWARE DOS REQUESTER
>     FIRST NETWORK DRIVE = F (Used only with the VLM.EXE).
>     PB BUFFERS = 10

### Gigabit Sample Files

AUTOEXEC.BAT:

>     CD\NWCLIENT
>     LSL
>     E1000ODI
>     IPXODI
>     NETX (or VLM optional for NetWare 3.12 or higher)

NET.CFG:

>     LINK DRIVER E1000ODI
>     FRAME ETHERNET_802.2 (generally NetWare 3.12 and later servers)
>     ;FRAME ETHERNET_802.3 (generally NetWare 3.11 and earlier)
>     SPEEDDUPLEX = 3
>     PROTOCOL IPX EO Ethernet_802.2

>     NETWARE DOS REQUESTER
>     FIRST NETWORK DRIVE = F (Used only with the VLM.EXE).
>     PB BUFFERS = 10

> NOTE: SPEEDDUPLEX parameter: 0=10Mbps half-duplex; 1=10Mbps full-duplex; 2=100Mbps half-duplex; 3=100Mbps full-duplex. The SPEEDDUPLEX keyword is only needed when you are forcing the card to a lower speed and duplex. The link partner must also be forced to the same setting.

`Last modified on 7/17/03 10:19a Revision 9`