
------------------------------------------------------------------
NOV-NIC2.DOC -- 19980327 -- Email thread on Network Interface Cards
------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Thu, 26 Jun 1997 20:32:08 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Intel EtherExpress PRO/100B configuration

	The Intel EE PRO/100 family of Ethernet adapters has a driver
parameter named TXTHRESHOLD which is very important to change for robust
communications. I'll explain what it is, where a difficulty arises, and
a simple workaround.
	It is the number of 8 byte groups to wait for from above before
starting transmission. It's an early transmission permission grantor.
The values range from 1 to 200, with 200 being 1600B and hence the msg
to wait for the real end of packet before transmitting. The default is
8, wait 64B.
	Alas, early transmission leads to sending packet fragments on
the wire. A case here yesterday and today reveals how bad this can be.
My remote boot roms were very flakey, even on a quiet wire. Investigation
showed fragmented packets from the client saying "send me the next 512
bytes of the boot image" and they were of course not understood. Thus
booting was problematic at best. The same basic lan driver is in the
boot roms as we run in clients and servers, but with no way to adjust
parameters.
	The solution is to add phrase TXTHRESHOLD=200 to the load line
of the driver.
	Alas, inetcfg.nlm does not want to accept it and either rebuffs
our attempts or blithely removes the phrase. And we are not permitted
to edit the sys:etc\netinfo.cfg file holding inetcfg's output commands.
Thus we have to load the drivers manually in autoexec.ncf and remember
to never let inetcfg run.
	Well, there are ways and there are ways.
	My bootrom vendor has been informed, and Intel has been very
helpful in trying to find a solution. But I created a non-boot-rom
solution and it's shown below.
	The file below is e100b.ldi, the description file for the e100b.lan
driver. It has been modified by me to have inetcfg accept the TXTHRESHOLD
phrase, pass it on to the driver at load time, and even add a mini-editorial
via the F1 help message. I've chopped out the repetitous language sections
to save space in this email message, but you should add my help message
$E100B_12 to each language section.
	Joe D.
----------

;DrIvEr DeScRiPtIoN

SyntaxVersion: 1.00
;- Internal Version 1.12

;- File: E100B.LDI
;- Intel EtherExpress(TM) PRO/100B Installation Information File
;- This file handles all EE PRO/100 MODEL B adapters :
;- PRO/100 PCI with TX Physical Layer
;- PRO/100 PCI with T4 Physical Layer
;- PRO/10+ PCI
;- Modified by Joe Doupnik, jrd@cc.usu.edu, Utah State Univ, 26 June 1997
;-  to permit necessary selection of TXTHRESHOLD. Added matching help.

   Driver E100
   {
      Description:      $E100B_1

      Help:             $E100B_2

      File:              E100B.LAN

      Prod:
      PCI.8086.1229.0000.0000.*

						PAR:              2.00


      PROMPT   SLOT    OPTIONAL

      {
	 Help:           $E100B_3
	 Type:           DECIMAL (5)
	 Values:         1 - 65535
	 Default:        UNDEFINED
      }

      PROMPT   SPEED    OPTIONAL

      {
	 Help:           $E100B_4
	 Type:           DECIMAL (3)
	 Values:         0, 10, 100
	 Default:        0
	 Out:            'SPEED=%s'
      }

      PROMPT   FORCEDUPLEX    OPTIONAL

      {
	 Help:           $E100B_5
	 Type:           DECIMAL (1)
	 Values:         0, 1, 2
	 Default:        0
	 Out:            'FORCEDUPLEX=%s'
      }

      PROMPT   IOMAPMODE   OPTIONAL

      {
	 Help:           $E100B_6
	 Type:           DECIMAL (1)
	 Values:         0, 1
	 Default:        0
	 Out:            'IOMAPMODE=%s'
      }

      PROMPT   TXTHRESHOLD   OPTIONAL

      {
	 Help:           $E100B_12
	 Type:           DECIMAL (1)
	 Values:         8 - 200
	 Default:        8
	 Out:            'TXTHRESHOLD=%s'
      }

      FRAME   FrameSelect

      {
	  Help:            $E100B_7

	 CDescription:     $E100B_8
	 Choice:           'Ethernet_802.3'

	 CDescription:     $E100B_9
	 Choice:           'Ethernet_802.2'

	 CDescription:     $E100B_10
	 Choice:           'Ethernet_SNAP'

	 CDescription:     $E100B_11
	 Choice:           'Ethernet_II'

	 Default:          1,2

      }

   }

      Driver E10
   {
      Description:      $E10B_1

      File:              E100B.LAN

      Prod:
      PCI.8086.1229.0000.0000.*


      ParameterVersion: 2.00

      PROMPT   SLOT    OPTIONAL

      {
	 Help:           $E100B_3
	 Type:           DECIMAL (5)
	 Values:         1 - 65535
	 Default:        UNDEFINED
      }


      PROMPT   FORCEDUPLEX    OPTIONAL

      {
	 Help:           $E10B_5
	 Type:           DECIMAL (1)
	 Values:         0, 1, 2
	 Default:        0
	 Out:            'FORCEDUPLEX=%s'
      }

      PROMPT   IOMAPMODE   OPTIONAL

      {
	 Help:           $E100B_6
	 Type:           DECIMAL (1)
	 Values:         0, 1
	 Default:        0
	 Out:            'IOMAPMODE=%s'
      }


      FRAME   FrameSelect

      {
	  Help:            $E100B_7

	 CDescription:     $E100B_8
	 Choice:           'Ethernet_802.3'

	 CDescription:     $E100B_9
	 Choice:           'Ethernet_802.2'

	 CDescription:     $E100B_10
	 Choice:           'Ethernet_SNAP'

	 CDescription:     $E100B_11
	 Choice:           'Ethernet_II'

	 Default:          1,2

      }

   }


DLANG: 4
;English

       $E100B_1 = "Intel EtherExpress(TM) PRO/100B LAN Adapter"

       $E10B_1 = "Intel EtherExpress(TM) PRO/10+ PCI LAN adapter"


       $E100B_2 = "This driver supports the following EtherExpress(TM)
			 PRO/100B family adapters ->\n
			 PCI with TX Physical Layer\n
			 PCI with T4 Physical Layer\n\n"

       $E10B_2 = "This driver supports the following EtherExpress(TM)
			 PRO/10+ PCI adapter\n\n"


       $E100B_3 = "Slot number for the adapter.\n"

       $E100B_4 = "Line speed override for the adapter. Disables auto-\n
			  negotiation. Valid options are 0 (Auto), 10, or 100."

       $E100B_5 =  "Force the operating mode to Full Duplex.\n
			  Valid options are 0 (Auto), 1 (HALF), 2 (FULL)."

       $E10B_5 =  "Force the operating mode to Full Duplex.\n
			  Valid options are 1 (HALF) and 2 (FULL)."


       $E100B_6 =  "Force the driver to use I/O mapped mode.\n
			  The default mode is memory-mapped.\n
			  Valid options are 0 (DEFAULT) or 1."

       $E100B_7 =  "The driver defaults to 802.2 frame format. You
			    may use this default to select from the other 3
			    options => 802.3, Ethernet II and Ethernet SNAP."

       $E100B_8 = "E100B 802.3"

       $E100B_9 = "E100B 802.2"

       $E100B_10 = "E100B SNAP"

       $E100B_11  = "E100B E_II"

       $E100B_12 = "Early Transmission permitted after value times 8 bytes.
			DEFAULT is 8 (64B); optimum is 200 (1600B)
			meaning wait for full a packet (no noticable
			performance penalty). Early transmission can
			generate packet fragments and poor response.
			Recommended value is 200."

LANG: 6
;French

       $E100B_1 = "Intel EtherExpress(TM) PRO/100B LAN Adapter"

       $E10B_1 = "Intel EtherExpress(TM) PRO/10+ PCI LAN adapter"


       $E100B_2 = "This driver supports the following EtherExpress(TM)
			 PRO/100B family adapters ->\n
			 PCI with TX Physical Layer\n
			 PCI with T4 Physical Layer\n\n"

      $E10B_2 = "This driver supports the following EtherExpress(TM)
			 PRO/10+ PCI adapter\n\n"

       $E100B_3 = "Slot number for the adapter.\n"

       $E100B_4 = "Line speed override for the adapter. Disables auto-\n
			  negotiation. Valid options are 0 (Auto), 10, or 100."

       $E100B_5 =  "Force the operating mode to Full Duplex.\n
			  Valid options are 0 (Auto), 1 (HALF), 2 (FULL)."

       $E10B_5 =  "Force the operating mode to Full Duplex.\n
			  Valid options are 1 (HALF) and 2 (FULL)."


       $E100B_6 =  "Force the driver to use I/O mapped mode.\n
			  The default mode is memory-mapped.\n
			  Valid options are 0 (DEFAULT) or 1."

       $E100B_7 =  "The driver defaults to 802.2 frame format. You
			    may use this default to select from the other 3
			    options => 802.3, Ethernet II and Ethernet SNAP."

       $E100B_8 = "E100B 802.3"

       $E100B_9 = "E100B 802.2"

       $E100B_10 = "E100B SNAP"

       $E100B_11  = "E100B E_II"

       $E100B_12 = "Early Transmission permitted after value times 8 bytes.
			DEFAULT is 8 (64B); optimum is 200 (1600B)
			meaning wait for full a packet (no noticable
			performance penalty). Early transmission can
			generate packet fragments and poor response.
			Recommended value is 200."

------------------------------

Date: Thu, 31 Jul 1997 14:25:13 -0400
From: "George Raetzke, Northern Ill. Univ." <graetzke@NIU.EDU>
Subject: Re: Using ATM in Netware file servers

>Has anyone tried using ATM cards in 4.1 or 4.11 file servers. If so what
>brand of card are you using, and what problems (if any) have you had?

I am currently using the Madge Collage ATM adapter in a few of my servers.
So far they seem to be working quite well.  A sales rep from Olicom talked
my boss into testing one of their adapters.  I started to install in, but
the install program was so bad, I yanked it right out and dropped a Madge
in.

The only thing that has bit me so far, is that the VLAN is case sensitive.

------------------------------

Date: Sat, 2 Aug 1997 22:17:03 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Intel Etherexpress Pro/100 (non revision B)

>Does anyone have an experience with the Intel Etherexpress Pro/100
>cards which are not the current rev. B version?
>
>Are there problems or reasons I shouldn't use these in v4.11 servers?
------
	Non-rev B boards come in ISA, EISA, and PCI variants. The PCI
one causes endless trouble here at boot time by clobbering the PCI part
of system memory (>>>>> 1MB) but can be made to work part of the time.
The EISA variant is current production and works pretty well. I have
not touched the ISA equivalent.
	The board of choice from Intel is the rev-B PCI board, based
on performance and better domesticated PCI behavior. At quantity prices
of US$60 it is a bargin.
	Joe D.

------------------------------

Date: Tue, 12 Aug 1997 08:30:46 -0400
From: Shimshon Farkash <shimshon@TECHUNIX.TECHNION.AC.IL>
Subject: Re: win95 and Client32

Please read carefuly the doc "Client32 and 3Com adapters"
at http://ourworld.compuserve.com/homepages/mcox/netware.htm
This is a good advise to every one who used 3Com adapters and Client32.
I had problems and this doc help me to solve them.

------------------------------

Date: Tue, 26 Aug 1997 12:46:00 +0000
From: Jon Hall <jmah@ISVR.SOTON.AC.UK>
Subject: Re: Query about client load order

>Just a short and inconsequential question about the client load order.
>In the VLM client model, the nic driver lies below the link support layer,
>above which lie the protocol components and then the requester. Following
>the physical model then, you would think that the NIC drivers should be
>loaded first, and then the LSL, followed by the protocols and finally the
>VLM components. Why then is the lsl loaded before the NIC drivers?

LSL (despite the name) isn't really a layer as such; it's more like the
glue bonding the layers together (a bad analogy, I know). NICs register
themselves and their capabilities with LSL; protocol stacks interrogate
LSL to find out what NICs are available. This is why LSL has to load
first.

---------

Date: Tue, 26 Aug 1997 10:11:16 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Query about client load order

-------
	That seems logical, until one asks how the various components
rendevous. Scanning memory for signatures, scanning interrupts for signatures
and so on have limitations. The LSL is the manager of ODI and establishes
itself on a "well known" interrupt chain, Int 2F, where other modules can
locate it. Once located each module registers itself with the LSL, as a
lan driver, as a protocol stack, etc, and then modules can ask the LSL
about other modules.
	The actual operations are load the LSL, then the lan drivers, and
then the protocol stacks. The reason for this is the stacks try to attach
(bind) to a lan driver and need them available for inspection. Hence, LSL,
then lan drivers, and finally the stacks.
	ODI is amazingly flexible and clever. One may load and unload
components dynamically, save the LSL, provided there are no bindings
needing support. And one may even use a protocol stack as a fake lan
adapter, as is done with IP Tunneling and NW/IP to make the TCP/IP stack
look like a lan driver to ODI and yet still use a real lan adapter to get
to the wire. I drew a picture of this in the list's FAQ. There can be
layers of "lan adapters" or "protocol stacks" such that packets are
passed along a chain, and this is often used for encrypted traffic as
well as for packet snooping.
	Joe D.

------------------------------

Date: Wed, 8 Oct 1997 09:15:57 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Which NIC ?

>>>For a server, is there a preference between a 3c905-TX 10/100 PCI
>>>Network card and an Intel EtherExpress PRO/100 LAN Adapter?  TIA.
>
>>Both will work. I've looked at both. I went away and spent money
>>on the Intel board and have been pleased. The Intel board has better
>>performance and is more adjustable than the 3Com unit. Also, on a
>>small sampling, 3Com boards have a high dead-after-few-hours-use
>>rate, but this may not be typical. A 3C905 board is basically a 3C509
>>board for a PCI bus.
>>	Joe D.
>
>I believe the Intel EtherExpress PRO/100 LAN Adapter comes in two
>flavours with one specifically designed for servers - and considerably
>more expensive.  Is this the one you are referring to here ?

	I have both versions of the Intel board: Intel EtherExpress PRO/100B
and EtherExpress PRO /Server. The above refers to the 100B client flavor,
less expensive, board. The Server kind is a completely different board and
I have had terrible trouble making it work with the PPro motherboard in one
server, and Intel can't help.
	The Intel EE PRO/100B and 3C905 are both client class adapters. They
don't have much buffering and they still want assistance from the driver to
manage that buffer. The Intel EE PRO/Server has an on-board i960 cpu and
more memory to lighten the burden on the server's cpu. Note: the PCI bus
EE PRO's are not the same as the EISA bus versions.
	What is surprizing in practice is the 100B performs very well in a
server. I see 20% or less server cpu utilization when driving a 100Mbps
wire to full capacity. Despite this I would prefer using the smarter server
board, but that will require a new motherboard with better PCI bus handling.
	Joe D.

------------------------------

Date: Thu, 9 Oct 1997 16:10:19 +0200
From: Hans Nellissen <dbphilos@UNI-DUESSELDORF.DE>
Subject: Re: NIC MAC address code

>	I know the manufacturer codes it's identity in the NIC by
>using assigend serial number blocks  but I can't find any information
>on what code blocks belong to what manufacturers.  Can anyone point me
>to this information.  I thinkthe IEEE administers this but they don't
>say on their public WWW site.  InterNIC doesn't either.

	http://www.cavebear.com/CaveBear/Ethernet/vendor.html

------------------------------

Date: Mon, 3 Nov 1997 17:50:23 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NE2000 10/100 NICs?

>Is there a 10/100 NIC, either ISA or PCI, out there that will still use
>a NE2000 MLID?
>
>We're running networked Win for Workgroups and can't see moving away
>from the NE2000 driver, as I've standardized on NE200 for all our
>machines (450+)...
---------
	You really do not want an NE2000 clone at 100Mbps Ethernet.
Believe me. Technically it is a very poor decision. I would suggest
you would be well advised to bite the conversion bullet firmly and do
a good upgrade job.
	You have heard comments on this list about various fast Ethernet
boards, and the best advice we can offer is to run extensive tests on
many of them to find the kind which fits your needs.
	I work with these things, and now and then even write drivers for
them, so the first paragraph does mean what I said.
	Joe D.

------------------------------

Date: Mon, 1 Dec 1997 08:31:13 -0600
From: Terry Kalister <tkalister@SAMEDAN.COM>
Subject: Re: Token Ring Beaconing

>Have you ever seen a server causing an abend every time the token ring
>beacons?

There is something critically wrong with your token ring network if it is
beconing much. Token ring will deal with most minor ring problems but a
beacon is its last ditch effort to let you know you have major problems. A
beacon removes the station causing the beacon from the ring. Beacons can be
caused from a bad card, ring length too long, bad wiring between stations,
bad patch cable, etc. Put a sniffer on your ring and find out who the
culprit is. If the server is abending, it could be the token ring card in
your server that is beaconing.

---------

Date: Mon, 1 Dec 1997 21:56:45 +0700
From: Garind P <garind@INDO.NET.ID>
Subject: Re: Token Ring Beaconing

If you have client32 with Win95B/OSR2, set the token ring card adapter as
IBM Token ring.  And set the card as AT-bus card, not PnP, without IRQ
interupt using the manufacturer setup program (usually DOS program)

------------------------------

Date: Wed, 10 Dec 1997 16:55:13 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Collisions?

>>I'm running 3.12 on a HP Netserver LC with a 3c5x9 nic.  The
>>send ok single collision count:  7,081,523  The send ok multiple
>>collision count:  2,329,193  ...is this indicitive of a failing
>>NIC or traffic coming from somewhere else?
>
>Does your network seem to be functioning correctly?  When a collision
>happens it causes the NIC's involved to "stop and wait" then try
>retransmitting.  If something is misfiring and causing collision after
>collision then the network will stop working.
>
>I have seen this happen when a thicknet transciever went screwey.  It was
>doing something which either causes a collision or triggered a collision
>and my collison count on the server was climbing exponentially.
-------
	What likely happened was getting the transceiver set wrong and
emitting "heart beat" bursts onto the network. These are 0.9 microsec
(regular Ethernet, divide by 10 for Fast Ethernet) tests of the emergency
collision system, if this were a real collision we would be doing useful
work, at the trailing edge of each packet. It is yet another bright idea
from the IEEE802.3 committee, to ensure the transceiver's collision detection
logic is functioning (on every pkt). They appear to be collisions to listeners
on the net, the net grinds to a halt. Heart beat goes only to an Ethernet
adapter, never the net, and only to those prepared to deal with it.
	Joe D.

------------------------------

Date: Thu, 11 Dec 1997 19:04:56 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Collisions?

>>	What likely happened was getting the transceiver set wrong and
>>emitting "heart beat" bursts onto the network. These are 0.9 microsec
>>(regular Ethernet, divide by 10 for Fast Ethernet) tests of the
>>emergency collision system, if this were a real collision we would
>>be doing useful work, at the trailing edge of each packet. It is yet
>>another bright idea from the IEEE802.3 committee, to ensure the
>>transceiver's collision detection logic is functioning (on every pkt).
>>They appear to be collisions to listeners on the net, the net grinds
>>to a halt. Heart beat goes only to an Ethernet adapter, never the net,
>>and only to those prepared to deal with it.
>>	Joe D.
>
>Joe, I'm confused.  Are you saying that a misconfigured transceiver
>could actually send heartbeat bursts onto the network, as opposed to
>just sending them to the adapter?=20
>
>I didn't know that was possible.  I didn't know there was a definition
>of a what a heartbeat would even be, on the network.
-----------
	Answering two questions in one message.
	Ken's query. Yes, it is indeed possible to get backward, especially
if plugged into a hub's AUI port. Locally this is known as the "DELNI Effect"
after DEC's venerable AUI-ported hub of many years ago (original Ethernet in
a box). This is in the IEEE 802.3 specs if you have purchased a copy. The
heartbeat burst is a tiny collision pulse, intended for compliant receivers
to say "Yup, the detector worked again" but which across the net looks like a
"late collision" jam signal and hence packets most often are dropped like a hot
potato. The heartbeat stuff goes out the AUI port. It is rarely used in this
day and age of reliable equipment.

	Mike's continuing dilemna. The server's ODI driver is able to count
things most drivers don't. They will reveal how many frames were sent with
no competition, after one bump, after several bumps, and those that failed
to go out from excessive retries or failed equipment. Several bumps per try
is quite normal on a busy wire and is not a concern. For those who still
think collisions are some horrible event, this is several hundred percent
collision rate. Total losses are of concern. The counts will go up if there
is traffic, so the more traffic the more bumps total, as common sense would
indicate.
	Naturally, the Ethernet controller chip has to be of the kind which
reveals such statistics because all this bumping stuff is handled by that
big square piece of silicon. It is a natural and essential part of Ethernet's
sharing the medium.
	There are many reasons frames do not get through. Flakey wiring is
one. Inadequate LAN adapters and drivers is another, a common one. Misconfig'd
equipment is another. A broken LAN adapter on the net can emit garbage and
drag things to a crawl. A wild LAN adpater can do the same by saturating
the wire, and the vendor LAN adapter self-test program is normally an
excellent way of making trouble. Use a LAN monitor (say Lanalyzer) to check.
	Weak LAN adapters will begin to fail under Packet Burst stress, and
under intensive SPX back and forth chatter during backups. Weak adapters can
be on client and/or server.
	There's more. Some adapters can emit partial frames when their
transfer of packet bytes from driver to LAN adapter across the system bus
is delayed by competition for the bus. This is termed "DMA underrun" and
is controllable on some adapters. For Intel EtherExpress boards set
TXTHRESHOLD=200 to tell the board not to start transmitting until all packet
bytes have made the bus trip. Each board is different so please check your
details. If PCI bus set the PCI latency to 40 or less clock ticks on all
peripherals, thus reducing bus hogging.
	Some LAN adapters have an "interrupt early" feature upon packet
reception which causes the machine to sit for a millisec or more waiting for
the rest of the frame to arrive. If this feature can be turned off do so,
else change to another brand of board. As I have been told, the feature is
used to support the horrid interrupt latency on NT systems where all the time
is needed to get the receive act together. NW servers and clients do not
need this wasted time.
	A weak wiring plant or a hub beginning to die of old age, and similar,
are hard to spot unless swapping tests are done. Twisted pair stations detect
collisions by hearing data while sending, and that can arise from too much
Near End CrossTalk (NEXT in the jargon), which in turn says fix the wiring
with better qualtiy and better handled stuff. Check that all four wires are
connected properly because mis-pairing generates lots of NEXT.
	I put all of this into the category of Necessary things to know about
real networks but rarely written in texts or managers guides to this and that,
or CNE exams. It's not secret; it is knowing the technology.
	Joe D.

------------------------------

Date: Thu, 18 Dec 1997 08:39:17 -0600
From: Steven Mitzel <stmitzel@SLFC.COM>
Subject: Re: Token Ring Network Card

>At work we have a many, many network cards.  All our IBM token-ring
>network cards (number unknown).  Most of them have the small white
>switches on them. Does anyone how to configure these card, and what
>drivers I should load, in DOS and in Windows 95 ?
>
>I also have some TokenLink III 16.4 (3c619c) to configure also (like
>the about.

I have some IBM 16/4 Token Ring cards with the white switches on them.
They are ISA cards.

If you happen to have the manual "Token-Ring Network 16/4 Adapter
Hardware Library - Guide to Operations" (dark brownish-red book), this
shows all of the settings for each of the switches.  If you do not have
this, I could get you the information for the dip switches.
     1-6   ROM Address
     7-8   IRQ for the card
       9   Primary or Alternate LAN adapter
   10-11   Shared RAM size
      12   Adapter Rate Switch  (ON = 16Mbps; OFF = 4Mbps)


I'm on a NetWare 4.10 network.
These are the settings in my C:\NWLCIENT\STARTNET.BAT file (which is
called from the Autoexec.bat file) for my Windows 3.1 clients:

SET NWLANGUAGE=English
C:\NWCLIENT\LSL.COM
C:\NWCLIENT\LANSUP.COM
C:\NWCLIENT\IPXODI.COM
C:\NWCLIENT\VLM.EXE


For the Windows 95 clients, I use the "IBM Token Ring 4/16Mbs" adapter
right off of the Windows 95 CD.  Nothing in the Autoexec.bat or
Config.sys.

---------

Date: Thu, 18 Dec 1997 11:16:08 -0600
From: Brian Scott <bscott@SYSTEMA.WESTARK.EDU>
Subject: Re: Token Ring Network Card

Well, you are in luck.  All (well almost all) IBM 16/4 Token-Ring
cards that have dip switches, have the same settings.  These settings
are for the switch block with 12 switches.  On the cards with both
STP and UTP ports there are an additional two switches, but they
should be labeled on the card.

Off is with the switch is in the up position ( away from the card ).

Switch 1 to 6 set the ROM address
The two recommended settings are:
CC000  off on on off off on   (primary)
DC000  off on off off off on   (Alternate)
These switches are actually the middle 6 bits of a byte.  The high
bit is always 1 and the low bit is always 0.  Off = 1, On = 0.

Switch 7 and 8 are the IRQ.
IRQ 2 = on on,  IRQ 3 = on off, IRQ 6 = off on, IRQ 7 = off off

Switch 9 is for selecting primary/alternate adapter.
primary = off  ( port A20 )
alternate = on ( port A24 )

Switch 10 and 11 are for the RAM size.
16Kb = off on (recommended)
8Kb = on on,    32Kb = on off,   64Kb = off off

Switch 12 is the speed
16Mbps = off,  4Mbps = on


Drivers:

DOS: either token or cntr2000. We use witch ever is newer at the
time.  We use both the 16 and 32 bit versions of these as needed.

Win95:  I think we use "IBM Token Ring 4/16", but the "IBM Token Ring
(All types)" also works.  Most of the 95 systems we have are now pci,
so we don't have that many ISA adapters in this setup.

Also if you need I have recommened settings for using IBM ISA
Token-Ring cards with Sound Blaster cards ( non pnp ).

On 17 Dec 97 at 16:13, Dave Skinner wrote:

>Hi there.
>
>At work we have a many, many network cards.  All our IBM token-ring
>network cards (number unknown).  Most of them have the small white
>switches on them. Does anyone how to configure these card, and what
>drivers I should load, in DOS and in Windows 95 ????
>
>I also have some TokenLink III 16.4 (3c619c) to configure also (like
>the about.

------------------------------

Date: Fri, 19 Dec 1997 21:46:00 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 3COM 3C509 in server - a no-no?

>This is interesting. Does anyone (probably Joe D.) know the buffer size
>on the 3C590 and 3C905 - which would at least partially explain why the
>590 outperforms the 905 (at least in my experience).
-----------
	No, I have no idea. From years of hard knocks I've decided to
avoid 3Com Ethernet boards as not well designed for my uses.
	There is much more to Ethernet board-life than buffer capacity,
but it is important. It is extremely tightly coupled with the ability
of its driver to keep that silicon buffer emptied. That in turn means
fast transfers across the system bus. PCI is better at this than EISA
which is much better than ISA. There are bus masters and bus masters,
and non-bus masters (shared memory, port i/o), and performance varies
a lot in this area.
	I suggest visiting 3Com's technical areas and get the specs,
for what they will tell you. Careful stressful testing is the real way
of discovering performance.
	Joe D.

------------------------------

Date: Sat, 20 Dec 1997 13:25:23 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Intel EtherExpress PRO/Server Ethernet boards

	This is a short note on local experience with the fancy and expensive
Intel EtherExpress PRO/Server PCI Ethernet boards.
	These units have an on-board i960 processor and 1+MB of packet storage
memory. They run rather warm.
	Until this weekend I was unable to employ the boards because the
INW 4.11 server hosting them would halt solidly when their driver, e100snw,
was loaded. The motherboard was an ASUS XP6NP5 (PPro 200 PCI/ISA, 440FX
PCI chipset). I changed the motherboard to an Intel VS440FX unit, uses same
chips, and the Ethernet boards are working very well indeed thus far. Hence,
the ASUS board was unable to accomodate the sophisticated PCI bridging work
needed with these Ethernet boards. Motherboards are cheap.
	A beware. The Intel motherboard has a Bios which uses part of segment
E000, in addition to the regular segment F000 material. Initially I was
unable to flash update the Bios. Then the light dawned and I swapped out
the current video adapter for one which does not ghost its Bios into E000.
That solved the problem; flash updating succeeded.
	At the moment stress testing is occuring. There are three EE PRO/Server
boards in the server, two driving 100Mbps lans (hubs and clients) and one
driving a 10Mbps lan (for the moment). Using Perform3 to create as much lan
traffic as possible without affecting the SCSI disk farm I find server cpu
utilization to be about 17%. That's driving two 100Mbps lines at full (95%)
capacity and one mere 10Mbps line at the same capacity. The server is loafing.
	Joe D.

---------

Date: Sun, 21 Dec 1997 10:44:35 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Intel EtherExpress PRO/Server Ethernet boards

Regarding the issue of the Intell 100 PCI ethernet cards.

We used them on a few servers, all of which are NOT Intel boards due to
the fact that there was some clash between the board and the cards. This
may have been fixed since then, but Intel support here in Israel agreed
that there was a problem.

The only thing I did not like about the cards, is that they would
"pulse". At very odd times the cards would slow down and then shoot back
up to speed without any visible reason. We did a thoruough check on all
the wires, hubs, memory, boards, the lot and could not solve the issue.
Using the 3Com 100 cards solved the problem completely.

I have seen a few too many problems with Intel cards not working well on
Intel machines but working fine on others, and have come to the
conclusion that Intel is great at boards and pc's, but their card
technology leaves a bit to be desired. It's either that or the fact that
they have departments that don't talk to each other.

Another such example is the Intel EISA 10/100 Ethernet cards. These
cards work well on Intel servers so long as you never put more than one
in a server. The moment you put more than one, the cards intermittently
freeze and after a short while AbEnd the server. Then of course if you
try to flash the cards to update the BIOS, if there is more than one
card, it fakes the flash and doesn't actually do it.

This may of course have been solved since I did this (about half a year
ago), but it has left me with a bit of a bad taste when it comes to
Intel fast NIC's.

------------------------------

Date: Sun, 21 Dec 1997 09:15:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 3COM 3C509 in server - a no-no?

>>for what they will tell you. Careful stressful testing is the real way
>>of discovering performance.
>
>I ran perform3 on this particular network, using 8 PC's on 2 segments, and
>Perform3 could not get started. Lots of disk requests, but no
>reading/writing. What does that tell me?

	Could not get started, etc? I don't understand the comments.
Try     perform3 dummy 12 1 4096 512    on the first client
and     perform3                        on all the others.
Ensure they all are using the same directory (so they use the same sync file),
and the directory is on the file server.
	I stress tested my system yesterday this way, with 42 clients
doing mostly the same cooperative Perform3 and the remainder looping in
iozone.exe. I used  perform3 dummy 300 1 65535 1024   to yield a 5 hour
run.

>I have battled with performance probs on this network, but is much better
>now after some tuning. Stability also much better.
>
>To my original question: would NE2000's do better as a quick fix?

	Depends on what's wrong. NE-2000's are stable slow reliable beasts.
There are some clones of it which are peculiar but most are normal. The
suggestion is find and fix what's wrong rather than tinkering with things
around the edges.
	Joe D.

------------------------------

Date: Sun, 21 Dec 1997 20:07:13 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 3COM NICS and lanalyzer, etc

>Original question was about 3COM nics forwarding info up the ODI stack
>don't remember the details, but I suspect the question deals with
>"promiscuous mode" and LAN ANALYSIS.
>
>Both 3COM and NOVELL have told me the 3COM cards do not work in an analyzer
>for detailed error info.
>
>The reason 3COM gave me is many of the errors are handled on the NIC  by the
>ASICs and not forwarded.
>
>This may be OK for a workstation NIC, but not what you want when attempting
>to forward errors to your analyzer software, so you will need a different
>NIC on the monitoring station.
>
>NE2000  or SMC NICs ( in think INTEL recently bought SMC ) should work.
>I don't know about the INTEL NICs
---------
	The story is only half complete. LZFW and other diagnostic programs
report on send/receive errors and a host of other things which occur
processing packets. These are just counters maintained by the ODI lan driver
and read-out by the interested diagnostic programs. Such counters are cheap
to implement but the Ethernet adapter hardware needs to reveal them and the
driver writer has to look at the hardware to get the indications.
	Many ODI lan drivers do a thorough job of reporting conditions noted
in the silicon, and many include custom statistics as well. From your
comment it appears that 3Com's Ethernet controllers decline to report many
situations.
	Then there is the business of Ethernet multicasting. Ethernet boards
are supposed to support an array of multicast physical addresses (MAC addrs)
but some do and some don't. Applications software needs to load those addresses
into the driver. I recall a vague comment that 3Com chose to support one
multicast address only, but that is probably an inaccurate statement.

	I have had no difficulty using LZFW over NE-2000 clones nor over
the Intel EE PRO/100B boards. I see the sundry errors and can look at
collision fragments byte by byte, etc. In fact I was doing just this a
few minutes ago while stress testing the EE PRO/server boards against the
client style 100B units.
	There are boards whose driver tries to shield users from tinkering,
yet still have hooks to engage/defeat special features. The amount varies
by vendor. The Intel boards have a lot, nearly all undocumented, and 3Com
boards have almost none. That spans the range. These knobs are normally
without documentation and one needs to be a shrewd guesser to know what
they do. I just tamed, I hope, the PRO/server board to not get caught
sending partial frames if the PCI bus is very busy, but I won't know for
sure until tomorrow (tests are running overnight). I had done the same
last spring for the client 100B units.
-----
	Another piece of technical trivia on the Intel EE PRO/server boards
gleaned this evening. When transmitting packet after packet server cpu
utilization registered about 0% (zero). I'm filling a 100Mbps wire with
PBurst groups 22KB and smaller from the server (running Perform3) where the
data origin is still the server's cache memory. There is no interrupt activity
reported by Monitor (INW 4.11)! The on-board i960 cpu of the adapter is
apparently soaking up all the driver workload and doing calls rather than
interrupts to the operating system to move data memory to memory. The server
is doing the NCP work but with a PPro 200 that is quickly accomplished at no
visible cpu load. Thus if I didn't look elsewhere the server could be driving
many 100Mbps Ethernet wires full tilt from cache memory and I wouldn't know
from the Monitor snake or cpu utilization. Thus if a server really has to
push bytes across the wires (say 100Mbps wires) while doing lots of other
things then boards of this class are worth looking into.
	Joe D.

------------------------------

Date: Tue, 23 Dec 1997 00:15:43 UTC
From: Robert Moss <RMOSS@VM.TULSA.CC.OK.US>
Subject: Re: 3COM 3c905 and 3c509

We installed a few of the 3c905 PCI boards when we upgraded the PCs
in our department.  Now, installing an ethernet adapter isn't really
rocket science so I didn't expect to spend more than a few minutes
per machine.  All the PCs were running Win95.

One spotted the new card, installed drivers and ran happily ever
after.  One would spot the card, install the drivers but not see the
network.  This was an all day project and I can't recall what finally
made it work.  The last machine seized tighter than an Indian as soon
as it saw the new card ( tried several to eliminate bad card ).
Finally gave up and went back to the original 3C509 and couldn't get
it to work either.  After several hours I just whopped out FDISK.
Runs fine now.

I should've taken the hint, but I proceeded to put the 3C905 in a
new 4.1 server.  This system would run for a day or two and then,
without any warning or error messages, start kicking off users.
After 5 or 6 minutes the server would hang and require a reboot.
There was never an indication of what the problem might be.  As soon
as I replaced the 3C905 with a trusty old 3C509 the problem went
away.

3COM tech support says they never ever ever heard of a problem with
the 3C905 card and a Novell server.  Right.

------------------------------

Date: Tue, 30 Dec 1997 23:17:03 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Intel EtherExpress PRO/Server Ethernet boards

>The pulsing problem wasn't caused by the Intel boards, but by the Intel
>100 NIC's. As far as my experience goes, the only problem I have with
>Intel on this issue, is that their own NIC's sometimes work better on
>other machines than on their own.
>
>This is a typical situation of what happens when one hand doesn't know
>what the other is doing.
>
>Mike Glassman
>
>> Could you tell me which HUB you were using when you had this pulsing
>> problem?  We are just about to purchase 3 new servers from DELL, and
>> they come w/ these blasted Intel boards.  Up until now, we have used all
>> 3COM boards w/ Synoptic hubs (Great combo)... and I'm worried that we are
>> going to find things like this which will cause me a headache on my network.
>>
>> > The only thing I did not like about the cards, is that they would
>> > "pulse". At very odd times the cards would slow down and then shoot
>> back up to speed without any visible reason. We did a thoruough check on
>> all the wires, hubs, memory, boards, the lot and could not solve the
>> issue.  Using the 3Com 100 cards solved the problem completely.
----------
	The "pulsing" (or should we say surge) problem is most likely tied
to two things. One is the board's trying to space frames based on perceived
network load and spacing of empty time on the wire. The second is the
willingness to send frames which are only partly transferred across the
PCI bus (TX dma underrun). Both "should" go away with very simple changes.
As always with PCI buses, throttle the PCI latency to about 32 bus clock
ticks, to give other peripherals a chance at the bus.
	Below is the top of my own  e100snw.ldi  lan driver info file.
If you use this with  Load inetcfg, Boards, select Options, then there
will be two new options to tweak: TXTHRESHOLD (please set this to 200)
and NOADATAPTIVETHRESHOLD (please set this to 1). EE PRO/100B client boards
get the same treatment except omit the NOADAPTIVETHRESHOLD components.
Client 100B boards in clients accept TXTHRESHOLD=200 on their load e100bodi
command lines.
	All this is likely a continuation of the Intel engineers seeking
ways of implementing Ethernet anti-capture mechanisms, inspired by Mart
Molle's BLAM proposal, but in their own terms. That's just my guess.
	At the risk of some complaints here is the top couple dozen lines
of that file so I won't have to repeat this on the list again. Note, the
Help text should be repeated for each of the languages in e100snw.ldi
(a text file). Omissions made to save mail bandwidth.
	One also needs to be wary of Packet Burst itself because I have
noted it to go unstable in just the "surge" fashion noted when it is pushed
a little too hard and a few frames are dropped. My changes basically remove
the possibilty of frames being dropped from damage upon transmission.
	Joe D.
--------------
Excerpts of Intel file e100snw.ldi, modified by me.

;DrIvEr DeScRiPtIoN

SyntaxVersion: 1.00
;- Internal Version 0.62
;- Changes:
;- 02/05/97 V0.62 : Changed Duplex to ForceDuplex
;-                : Changed ISLVLAN to VLANMODE
;- 01/22/97 V0.60 : Fixed Message $E100SNW_5. Changed DUPLEX to FULL
;- 11/30/96 V0.47 : Original Version. First Transmittal to SWEAT
;- Modified by Joe Doupnik, jrd@cc.usu.edu, Utah State Univ, 20 Dec 1997
;-  to permit necessary selection of TXTHRESHOLD and NOADAPTIVETHRESHOLD.
;-  Added matching help.

;- File: E100SNW.LDI
;- Intel EtherExpress(TM) PRO/100 Server Installation Information File

   Driver E100SNW
   {
      Description:      $E100SNW_1

      Help:             $E100SNW_2

      File:              E100SNW.LAN

      Prod:
      PCI.8086.5200.0000.0000.*

<omitting existing material>

      PROMPT   TXTHRESHOLD   OPTIONAL

      {
	 Help:           $E100SNW_13
	 Type:           DECIMAL (1)
	 Values:         8 - 200
	 Default:        8
	 Out:            'TXTHRESHOLD=%s'
      }

      PROMPT   NOADAPTIVETHRESHOLD   OPTIONAL

      {
	 Help:           $E100SNW_14
	 Type:           DECIMAL (1)
	 Values:         0 - 1
	 Default:        0
	 Out:            'NOADAPTIVETHRESHOLD=%s'
      }


<omitting existing material>

DLANG: 4
;English

       $E100SNW_1 = "Intel EtherExpress(TM) PRO/100 Server Adapter"

       $E100SNW_2 = "This driver supports the EtherExpress(TM) PRO/100 Server
Adapter"

       $E100SNW_3 = "Slot number for the adapter.\n"

       $E100SNW_4 = "Line speed override for the adapter. \n
			  Disables auto-negotiation. \n
			  Valid options are 0 (Auto), 10, or 100."

       $E100SNW_5 =  "Duplex mode override for the adapter.\n
			     User must specify speed when specifying Duplex. \n
			  Valid options are 0 (Auto), 1 (HALF), 2 (FULL)."

       $E100SNW_6 =  "Connector to use for network connection.\n
			  Valid options are 0 (Auto), 1 (TPE), 2 (MII)."

       $E100SNW_7 =  "Selects Vlan Mode for the driver.\n
			  Valid options are 0 (Standard Mode: No VLAN), 1 (ISL
VLAN).\n
			  The default mode is non VLAN mode."

       $E100SNW_8 =  "The driver defaults to 802.2 frame format. You
			    may use this default to select from the other 3
			    options => 802.3, Ethernet II and Ethernet SNAP."

       $E100SNW_9 = "E100SNW 802.3"

       $E100SNW_10= "E100SNW 802.2"

       $E100SNW_11 = "E100SNW SNAP"

       $E100SNW_12  = "E100SNW E_II"

       $E100SNW_13 = "Early Transmission permitted after value times 8 bytes.
		       DEFAULT is 8 (64B); optimum is 200 (1600B)
			meaning wait for full a packet (no noticable
			performance penalty). Early transmission can
			generate packet fragments and poor response.
			Recommended value is 200."

    $E100SNW_14 = "No Adaptive Threshold, default 0 for off. 1 for on.
		   If on (1) use with TXTHRESHOLD=200 to delay transmission
		   until an entire packet has been transferred across the
		   system bus and hence eliminate Tx DMA underruns."


<omitting repetitive material>

------------------------------

Date: Fri, 2 Jan 1998 08:42:16 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Switching to 100Mb

>At the moment I'm running a 10Mb network on 3 X 4.11 servers.  I will
>be soon starting a phase over plan too 100Mb.  I run a public school
>network and this phase over will take probably 3 years with our
>limited funding.
>
>I have a few questions about this upgrade -
>
>I plan on installing Intel EtherExpress 100 server adapters in my 3
>servers.  Each server will also have a standard ne2000 card in it,
>most likely PCI.  At the moment all 3 servers have 2 cards in them, am

	NE-2000's are ISA bus only, not PCI.

>I likely to run into any problems doing this and what are your views
>on the Intel server cards ?

	Please go back over the list's traffic for the past few weeks
and review my comments on the Intel EE PRO/100 Server board. Recall, the
list is archived, and you can click to it by visiting netlab1.usu.edu
and following the signs.
	I use these boards and they are extremely picky about the motherboard.
Given the right motherboard they work terrifically. But the regular client
style EE PRO/100B or now 100+ boards work well too (use more cpu cycles,
but we generally have them to burn). To justify the Server boards (at about
US$550 each, versus under US$70 for the 100B/100+ units) you must have
very heavy traffic and a very busy server.

>All 3 servers are simply used for storage, one will be becoming the
>backup server using Arcserve 6.  The other 2 servers will have the
>agent installed on them aswell.  All 3 servers mainly provide
>multimedia data to users, with huge amounts of digital video.  TCP/IP
>is also running across the network providing internet access, and 2 of
>my servers route the internet packets.  Keeping this all in mind what
>is the best packet size for the network ?  At the moment I have 4202
>byte size packets.

	No, please. Ethernet frames are 1500 bytes of data. This is a
networking basic. Tell the server the max frame size is 1518, to allow
for headers and a tiny amount of bookkeeping.

>At the center of my new network I plan on installing a 3Com Switch
>3000 10/100.  Has anybody had any troubles with this switch and what
>do people think of it.  I'v picked it at this stage, because I have
>heard so many good things about it and that 3Com have already made a
>backbone module for it ready for 1000Mb networks.

	Chasing technology on a limited budget is a risky proposition.
Engineers ask "Do I really need this feature?" before investing in it.
Need != want, and all that jazz.
	Joe D.

------------------------------

Date: Fri, 2 Jan 1998 17:54:45 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Switching to 100Mb

>>Each server will also have a standard ne2000 card in it, most likely PCI.
>
>A local vendor offers "32bit PCI NE2000 cards".  All the NE2000's I've ever
>seen were 16bit ISA cards, as were the clones.  Can a NE2000 clone really
>be 32bit/PCI?
----------
	NE-2000's have a very well defined systems interface. They are ISA,
and they use regular port i/o plus a regular interrupt. There is no, and I do
mean none, advantage of putting these on a PCI bus because, amongst other
reasons, the port i/o for packet data occurs one byte at a time, not even two
which the ISA bus can support for a 16-bit board. NE-2000 drivers must see the
board as such a conventional ISA device.
	When faced with off color "NE-2000" clones I recommend looking in
another direction. Solid standard boards are widely available at good prices
these days, so please avoid the wierd stuff.
	Come enroll in my ODI lan drivers class this term (starts Monday).
USU registered EE juniors only, must speak MS assembly language and C. We run
on what we write, a class motto.
	Joe D.

---------

Date: Fri, 2 Jan 1998 21:12:27 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Switching to 100Mb

>>>	No, please. Ethernet frames are 1500 bytes of data. This is a
>>>networking basic. Tell the server the max frame size is 1518, to allow
>>>for headers and a tiny amount of bookkeeping.
>
>>I thought that if MAXIMUM PHYSICAL PACKET RECEIVE SIZE was set to 4202
>>(which I commonly see), it was simply an upper limit -- smaller packets
>>were created and moved around just fine.  Or am I thinking of the wrong
>>setting?
>
>Well, actually, it reserves memory in accordance with the above seting.
>This can be seen by using Monitor|Resource Utilization|Permanent
>memory|LSL Receive buffers.  (I think that's correct)
-----------
	Precisely. And for that reason one reduces the errant value to
proper size and thereby conserves server memory. We have gone over this
many times, and it is probably in the list's FAQ (no time to look tonight,
deep in a MS Office 97 installation to server mess).
	Joe D.

------------------------------

Date: Mon, 9 Feb 1998 15:37:48 -0000
From: Nick Kelly <nick.kelly@FRASERS.CO.UK>
Subject: Re: 32 and 33 spec ODI. How do you know?

Novell have a utility, DRVSPC.EXE, that will report the ODI spec of a
LAN driver.

This site has a copy:

	ftp://ftp.crimson.de/NOVELL/NWUTIL/

------------------------------

Date: Mon, 23 Feb 1998 21:42:04 -0800
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Binding Help??

>>When you are binding multiple protocol's to a single card
>>(802.2,802.3...) how do you automate the binding so that the
>>autoexec.ncf will run without intervention.  I used INETCFG to set up
>>the cards.  When I bring the server up, the autoexec.ncf stops to ask
>>questions like "Do you want to add another protocol to this card?"...
>
>This can come from several missing commands on the second NIC
>Load command.  For example, if the card loads in SLOT 2, and there isn't
>a SLOT=2 on the second load command it will ask if this card is loading
>a different frame type.  Other missing commands will cause the same
>problem.  So, you need to look at the load command and experiment to
>find out what it is missing.  Once it is complete, it will automatically load.

Make sure all your NIC driver LOAD statements have been moved to
INetCfg.NLM.

I've noticed that older versions of INetCfg.NLM will rarely create
this problem, and the updated version seems to fix it.  A trick to
upgrading INetCfg.NLM to v3.30 is to install the IPX/IP Gateway (you
don't actually have to enable the gateway).  I'm running (the last
time I checked) INetCfg.NLM v3.30e.

------------------------------

Date: Sun, 1 Mar 1998 23:36:28 -0800
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Intel PCI NIC card

>I am having some problems adding an Intel PCI Ethernet NIC to a
>Novell 4.1 server. I keep getting the folowing error. Any thoughts?
>
[snip]
>SERVER-4.10-1586: Loader cannot find public symbol: MSMScanBusInfo
[snip]
>  Module NE3200P.LAN NOT loaded
>
>What exactly is the public symbol stuff?

NE3200P.LAN is designed for a different NIC.  Make sure you are
using the correct .LAN modules for your Intel NIC.  Failing that,
consider the following:

You need patches.  Take a look at the following URLs:

	ODI33F.EXE: ODI 3.31/1.11 Update (recommended)
	http://support.novell.com/cgi-bin/search/patlstfind.cgi?2933514

	intraNetWare Support Pack v4.0 (recommended)
	http://support.novell.com/cgi-bin/search/patlstfind.cgi?2931406

	Common TCPIP.NLM for NW 3.12 and 4.x (recommended)
	http://support.novell.com/cgi-bin/search/patlstfind.cgi?2930326

The important one here is ODI33F.EXE, which will resolve all those
"MSM" related messages.

The Public Symbols are APIs (Application Programming Interfaces)
used by the NLMs and OS to interact with each other.  They "call"
each other with previously agreed upon parameters (arguments).  For
example (simplified), if a user tries to browse a web site hosted on
your server, a hardware interrupt would cause the .LAN driver (and in
turn all the MSM-related NLMs) to call TCPIP.NLM, which in turn would
call HTTP.NLM (or whatever web server you're using).

Newer NLMs sometimes provide more Public Symbols (or subroutines)
that didn't exist in previous versions.

------------------------------

Date: Sat, 7 Mar 1998 00:25:45 +0000
From: Richard Letts <r.j.letts@SALFORD.AC.UK>
Subject: Re: Mysterious MAC Address 0180C2000000

>I think this may help you
>
>The vendor code for 0180C2 is:
>Enance Source Co., Ltd. PC clones.

Erm, I think that would be 00:01:80:c2:xx:yy addresses

Do an altavista search for +0180C2000000 and you'll get several useful
references, includng a 'how it works' guide on the 3com site
in particular:

   Spanning Tree Addressing

   Transparent and source route transparent bridges participate in a
   Spanning Tree domain, which is identified when the destination address
   field of the Spanning Tree packet is the hexadecimal group address
   0180C2000000. Source route bridges participate in a different Spanning
   Tree domain, which is identified when the destination address field of
   the Spanning Tree packet is the hexadecimal bridge functional address
   030000008000. Both addresses are shown in canonical addressing format.

------------------------------

Date: Tue, 17 Mar 1998 10:23:49 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Intel NIC

>Has *ANYONE EVER* had any success with combining an Intel
>EtherExpress PRO/100 NIC and *ANY* version of a Netware Client for
>NT4(server)? I don't think the combination is possible.
-------
	Works here. I bring up NT least often so details are not at my
fingertips, nor am I interested in ferreting out details. Please keep
in mind that PCI bus compatibility plays a large role in these things,
and consequently even your display adapter has a chance of confusing
the system.
	Joe D.

---------

Date: Tue, 17 Mar 1998 11:19:25 -0800
From: Kevin Brackley <Kevin_Brackley@SFPORT.COM>
Subject: Re: Intel NIC

We have about 15 or so NT 4.0 workstations and 2 NT servers (although
stripped down to be nothing more than a workstation) running NWCL 4.11
w/workstation manager, all running Intel Pro 100 (REV B <---really
important) cards.  REV A cards will not work with Client 32 or ODI drivers.

------------------------------

Date: Mon, 23 Mar 1998 20:40:12 -0500
From: Greg Mullane <evilgreg@CONDOR.CIRCA.UFL.EDU>
Subject: Re: Intel NIC

>I've recently had the same problems with a couple
>PC's here. Same situation, have tried 3Com 3C905
>nics and Intel EtherExpress Pro 100 nics too.
>Microsoft client hooks up just fine, but Client-32
>will not see the tree or server. Nothing.

I used to have the same problem, here's the workaround
I use:

Rule #1: Never trust Windows. Don't pick any network
drivers from a list, always use the "Have Disk"
button.

The best way I have found is to add all the network
components during the initial setup of the OS.

For the Intel EtherExpress Pro 100, make sure that you
are using the "Intel 82557-based PCI Ethernet" driver.
It is the only one that works reliably. For the 3COM,
their "3COM Fast EtherLink XL 10/100 MB Ethernet Adapter"
works well in most cases.

Here's the process, starting from the Network Configuration
part of the setup:

1) Remove everything. Card, client, NetBEUI, etc..
2) Add a card using "Have Disk" and pick the right driver.
3) Remove other clients, NetBEUI, IPX (everything else that
popped up after you added the card)
4) Add TCP/IP
5) Add the client using "Have Disk". I usually copy it to
a local directory first as it may not be able to read from a
CD at this point.
6) Configure everything know while you are here (Tree, frame type, etc.)
7) Finish with setup

Works every time, on Intel and 3Com. I've found that
when I don't add the card at this point, it never works
correctly with the client.

------------------------------

Date: Fri, 27 Mar 1998 11:57:07 GMT+1100
From: Rees Griffiths <RGRIFFIT@RNA.BIO.MQ.EDU.AU>
Subject: Re: INTEL Server Card

Some months back I posted to the list with a problem with an INTEL
Etherexpress 100 Server PCI card in a Netware 3.12 server. Thanks to
feedback from list members and some hunting around on the Novell support
site I was able to determine that I needed the following patches

312pt8.exe or later. Its now up to 312ptd.exe
and the new ODI product installation odi33f.exe

I've only this week been able to bring the server down and try out the
above. Works fine.

------------------------------

