
------------------------------------------------------------
NOV-NCFG.DOC -- 19970401 -- Email thread on Net.cfg settings
------------------------------------------------------------

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




From: Henno Keers
Subject: Another NET.CFG tune-up!

Link Support (*)
	Max Boards 1
	Buffers 6 1536
;
Link Driver SMC8000 (**)
	Int ???
	Port ???
	Mem ???
	Frame Ethernet_II
	Protocol Ipx 8137 Ethernet_II
;
Protocol IPXODI (***)
	Bind SMC8000
	SPX Connections         = 60
	SPX Abort Timeout       = 4000
	SPX Listen Timeout      = 2500
	IPX Sockets             = 40
	IPX Retry Timeout       = 35
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = NDS,BIND (****)
	Name context            = 'cpi_alex'
	Network Printers        = 9
	Local Printers          = 0
	Show Dots               = on
	Connections             = 8 (*****)
	Average Name Length     = 8 (******)
	Max Tasks               = 50
	Checksum                = 0 (*******)
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 6
	Cache Writes            = On
	Pb Buffers              = 1
	Pburst Write Window Size= 32
	Pburst Read Window Size = 32
	LIP Start Size          = 1500
	True Commit             = Off
	Print Buffer Size       = 16
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Preferred Server        = CPISERV
	Long Machine Type       = IBM_PC
	Dos Name                = MSDOS

Comments:
(*)  Using another protocol stack besides IPXODI? TCP/IP? ODIPKT shim?
Otherwise you can remove "Link Support" since IPXODI does not use it.

(2*) Don't trust software set NIC's and MLID's to get the correct hardware
settings, _always_ use the values in the net.cfg.

(3*) Settings here are for Pserver, RPrinter and other SPX applications,
your normal apps don't need them.

(4*) You forgot to specify the NDS.VLM to be used besides the BIND.VLM.

(5*) If you have more than 8 attached NetWare 4.x servers, increase this.

(6*) This length also effects on OU's combined with server names...tune...

(7*) You are using Ethernet_II (good!), so you _can_ use checksums, you
might want to employ it in mission critical situations.

Greetings...Henno.

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

From: Henno Keers
Subject: NET.CFG for a Pserver

In the above net.cfg I see a Link Support major heading which is not
needed since IPXODI does not need it. My Pserver setup uses the
following net.cfg:

;
;   Net.cfg for Henno's PServer
;
Link Driver Ge16dod
    Int 5
    Port 320
    Frame Ethernet_802.3
    Protocol IPX 0000 Ethernet_802.3
;
Protocol IPXODI
    Bind Ge16dod
    SPX Connections     = 70
    SPX Abort Timeout   = 4000
    SPX Listen Timeout  = 2500
;
NetWare DOS Requester

[rest of this section deleted]

My rprinter stations use the following section:

Protocol IPXODI
    Bind 3C5X9
    SPX Connections         = 60
    SPX Abort Timeout       = 4000
    SPX Listen Timeout      = 2500
    IPX Sockets             = 40
    IPX Retry Timeout       = 35

Greetings...
Henno.

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

Date: Fri, 24 Nov 1995 23:14:00 MET
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Reachout and VLM 1.20A conflict Reported

>As for VLM 1.20A,  I want to report a conflict with Reachout 5.0 for
>Windows (RO5UP.EXE update) running in WFW 3.11 (WFWFILES.EXE update)
>and using QEMM 7.5 (5/12/95 release) as the memory manager.  Reachout
>will work if I do not load VLM.EXE /Mx.  My WFW network setyup is
>configured with IPX Transport and NetBIOS as the default WFW transport
>protocol and NetBEUI as the secondary transport protocol.  You need
>a routable protocol such as IPX, or TCP/IP for that matter, if you plan
>to route WFW over a router, since NetBEUI is a non-routable protocol,
>but that's for another memo.

Have you tried PB BUFFERS = 0 in NET.CFG?

I had strange problems with logging in and applications until
I did this little work around (has something to do with BIOSes that
don't handle the real-time clock as they should do).

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

Date: Wed, 17 Jan 1996 08:21:24 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: getting Bindery mode without typing LOGIN {username} /B

> How can you change the NET.CFG to login in BINDERY MODE on a 4.1 server
> using VLMs.I can only access BINDERY MODE by typing  "LOGIN {username} /B

In file net.cfg:

NetWare DOS Requester
    NetWare Protocol = BIND

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

Date: Thu, 18 Jan 1996 18:13:44 UT
From: Dave Kearns <DKearns@MSN.COM>
Subject: Re: NET.CFG example using PPP

>Does anyone use PPP to connect to a NetWare server?  I'd like to see a
>sample of the NET.CFG if possible.  Could someone supply it?

Here's an excerpt from a recent column in NetWare Solutions which might
help:

Using both SLIP and PPP

With dial-up connection to the internet expanding geometrically, and people
beginning to use more than one internet provider, we sometimes have to
support multiple protocols - one at a time - in a user's NET.CFG file.
Here's a typical NET.CFG used to support both SLIP and PPP with Novell's
LAN Workplace for DOS TCPIP stack.

As it is listed, it is configured to use SLIP:

NET.CFG

	Link Support
	Buffers   8    1500
	MemPool    4096
	Max Stacks 8
	Max Boards 8

	Link Driver SLIP_PPP
		INT        4
		PORT       3F8
		Frame      PPP

	Link Driver CPQETHNW
		Frame Ethernet_II
		Frame Ethernet_SNAP
		Frame Ethernet_802.2
		Frame Ethernet_802.3
		Protocol IPX 0 Ethernet_802.3  -- this should be indented

	Protocol TCPIP
		PATH LANG_CFG   C:\lwp\LANG
		PATH SCRIPT     C:\lwp\SCRIPT
		PATH PROFILE    C:\lwp\PROFILE
		PATH LWP_CFG    C:\lwp\HSTACC
		PATH TCP_CFG    C:\LWP\TCP

		TCP_SOCKETS     16
		UDP_SOCKETS     16

		ip_address      xxx.xxx.xxx.xxx LAN_CONNECTION
		ip_netmask      255.0.0.0       LAN_CONNECTION
		ip_router       xxx.xxx.xxx.yyy LAN_CONNECTION
		Bind CPQETHNW 1 ETHERNET_II     LAN_CONNECTION

		ip_address      zzz.zzz.zzz.zzz DialNet
		ip_netmask      255.255.255.0   DialNet
		ip_router       0.0.0.0         DialNet
	       ; Bind SLIP_PPP 1 PPP             DialNet
		Bind SLIP_PPP 1 SLIP            DialNet

The IP addresses used were removed to protect the innocent. If you are to
use both a LAN and SLIP/PPP connection, the two IP network  numbers MUST
be different.

In order to switch the above configuration from SLIP to PPP, Uncomment the
Bind command on the SLIP_PPP 1 PPP line, and comment out the last line.

Even if you are using SLIP connections, the frame type for the SLIP_PPP
driver MUST still be PPP in order for the Windows dialer to work.

Note that I did not specify a Default Router for the SLIP/PPP connection
as my Internet service provider has a Default Gateway setting on their
routers. Check with your ISP to see how you should set this.

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

Date: Mon, 6 May 1996 19:45:06 -0400
From: John Navarro <jnavarro@MCGRAW-HILL.COM>
Subject: Re: Packet Burst

I have seen similar problems with slow machines (386dx 33 and down) with
"PB BUFFERS" set too high.  Trim down the setting to about 2, and go up
from there.  I discovered this problem during the introduction of an
ethernet switch.

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

Date: Tue, 7 May 1996 01:22:23 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Packet Burst

>I have seen similar problems with slow machines (386dx 33 and down) with
>"PB BUFFERS" set too high.  Trim down the setting to about 2, and go up
>from there.  I discovered this problem during the introduction of an
>ethernet switch.

PB BUFFERS is a switch; it has the values '0' (off) or not-zero (on)
the amount of data bursted is set by other parameters (which escape me
at the moment.)

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

Date: Mon, 6 May 1996 20:52:47 -0400
From: John Navarro <jnavarro@MCGRAW-HILL.COM>
Subject: Re[2]: Packet Burst

Richard,

You are correct.  I've gotta stop and think some times!  What I did was
start with small window sizes and go up until problems began happening.
One segment was so congested that these problems didn't appear until the
ethernet switch was introduced.  The parameters to adjust are
PBURST READ WINDOW SIZE   and   PBURST WRITE WINDOWS SIZE.

Thanks for the correction.

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

Date: Tue, 28 May 1996 14:47:13 -0600
From: Brian Scott <BSCOTT@SYSTEMA.WESTARK.EDU>
Subject: Re: Reply to Get Nearest Server Problem.

I think this discussion has started moving from the original posting
so here it is:

From: "Alan P. Belliveau" <bellivea@CTRON.COM>
  I'm having a bit of a problem with some workstations. I have 2
  1000 user 4.1 servers. SERVER A has REPLY TO GET NEAREST SERVER =
  OFF. I'm trying to get my workstations to attach to SERVER B. The
  workstations are still attaching to SERVER A on bootup. I don't
  know why. Can anyone shed any light?

>From Dyna Text - Client for DOS/Win Tech. Ref.:
  NOTE: If both PREFERRED TREE (for NetWare Directory Services) and
  PREFERRED SERVER (for bindery services) are specified, then the
  first protocol to successfully attach is used, such as NetWare
  Directory Services or Bindery services.

>From Dyna Test - Client for DOS/Win Users Guide:
  NOTE: Do not use both the Preferred Server and Preferred Tree
  parameters simultaneously. The second parameter will override the
  first.

Not sure which is the truth and which is just BS, but the point is
the same.  Don't use both Preferred server and Preferred Tree in your
net.cfg.  In my case this was the problem, I had "Preferred Tree" in
my net.cfg.  When removed the "Preferred Server" parameter worked as
it should.

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

Date: Thu, 6 Jun 1996 15:59:31 +1000
From: David Lane <D.LANE@MAIL.NAVMAT.NAVY.GOV.AU>
Subject: Preferred Server Vs Preferred Tree

For all those for whom this is still an issue (personally I don't use
Preferred Server on 4.1 servers), try this in net.cfg:

1.  Remove reference to preferred tree (this will almost always make an
attachment before a preferred server statement).

2.  Insert a preferred server = statement but do not include the
quotation marks around the server name.

I have used this to attach to 3.1x and 4.1 servers on same segment
and through routers without problems.

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

Date: Tue, 18 Jun 1996 15:52:30 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: File Retransmission with Packet Sniffer

>>From: Joe Doupnik <JRD@CC.USU.EDU>
>
>OK, I'll bite.  At the risk of asking a stupid question, What's so bad
>about a 3C509?  I read through the harware and NIC threads of the FAQ and
>did not find anything conclusive.  If this does turn out to be the
>problem, then I'm up the proverbial creek, since we have an installed
>base of over 1000 PC's about 60/40 split between 3C509/3C503.

	What's wrong with the 3C509 board are a couple of strategic
things. Upon packet reception it interrupts to the board driver as
soon as a handful of bytes have arrived, well before the rest of the
frame has arrived and thus also before the frame CRC check has been
applied. That means the driver is taking over with interrupts OFF at
this point, it needs to get a buffer from the protocol stack, it cannot
tell how large a buffer is needed so the stack has to provide the largest
possible, and then it needs to sit and wait (ints still off) for the
entire frame to arrive. Once arrived the frame is copied to the buffer,
the board is cleaned up for the next frame, and the driver returns
operations to normal. A full length Ethernet frame is 1500 bytes, or
1.5 millisec at 10Mbps; that is a looong time to keep interrupts off and
the system locked up.
	Secondly, the Ethernet board buffer has been too small by far
so there was almost no elasticity in the system for a stream of back to
back packets. 3Com finally doubled the size but it is still small.
	Taken together these things mean the machine must pay careful
attention to the board to get packets removed asap to prevent overruns.
It gets blocked for long intervals from that premature interrupt. It
must allocate full length buffers whereas just-right-sized buffers
(from waiting until the frame has fully arrived) makes much better use
of space. It may well go through all this for a damaged frame, and have
to then back off that buffer allocation and appologize to the protocol
stack, and that takes time too.
	Did you notice 3Com's comments on serial port speeds? Wonder
what that is all about? See that long interval of interrupts off and
premature interrupt stuff above.
	That "parallel tasking" stuff is a stupid design, in my opinion.
	Here's another, on the outgoing side. Intel Etherexpress 100/10
boards (I don't know if 3Com does the same) can transmit a piece of a
frame if packet material arrives in clumps but not fast enough to keep
up with the wire. Rather than waiting until all the packet bytes are
ready and then sending a frame, it fires off bytes onto the wire as they
arrive. Result: runt fragments on the wire. To stop this I had to configure
the board to wait until all the bytes were available, just as any rational
board wishes. Software timers (equals S L O W) on one end or the other must
fire to recover from the lost frame. Another stupid design, and I'm
speaking as an Electrical Engineer.
	Adding a suggestion on a point you did not cover. PCI bus master
boards are normally configurable (via the PCI Bios) on how long they can
continue to use the PCI bus after competition arrives. 32 clock ticks is
nice and moderate, 80 is being a greedy pig. Too long and things get out
of kilter in a machine. Be conservative, get off the bus when asked. The
same applies to EISA bus controllers, for the benefit of other readers.
SCSI controllers are items to watch.

>The sniffer indicates that the problem is occuring at the application
>layer rather than at the physical layer, so would the NIC have anything to
>do with this?  Each time I boot up the station, I get 83 instances of File
>retransmissions, no more, no less.

	I don't know what the Sniffer is saying, lacking a Sniffer here.
You should look below at your net.cfg and see that you have IPX checksums
turned off. That means damaged packets (and there are plenty around) will
not be recognized as such by IPX and above, and when they penetrate the
stack then "interesting things" happen. We can't use IPX checksums with
Ethernet_802.3 frames, so use Ethernet_II and turn on IPX checksums.


>>	It means your net can't stand the traffic.
>Single server to single workstation?

	Yes, of course. Just put frames on the wire quickly, period.

>>	The first place to change things is that 3C509 board. Ditch it in
>>favor of a non-"parallel tasking" unit such as a plain jane NE-2000 clone.
>>The second place is the 3C579 board, but I know nothing about it; same
>>suggestion.
>
>Thats 3C595, 3COM's PCI bus-mastering 10/100 Fast Ethernet card.  We're
>looking at getting these for all of our servers since we will be
>installing ethernet switches with 100Mb ports before the fall term starts,
>so I'd like to connect the servers at 100Mb.  Since this is also a
>parallel tasking card, would that make it suspect?  If so, whats a
>reasonable replacement?

	Is it the same controller chip as the 3C509? If so you now know
a little more about the situation.

>>	Recall that PBurst puts lots of back to back packets on the wire,
>> and the receiver can fumble them.
>
>I tried this with Pburst unloaded on the server, and the results were very
>similiar in terms of File Retransmissions.
>
>>	None of this has anything to do with a particular protocol since
>> it's hardware level stuff that is causing the problem (most likely). But
>> your datacomms guy has the right instincts.
>
>As mentioned above, the sniffer says "application layer" problem, not
>physical.

	But that doesn't tell me much, aside from possible IPX damage.
Anyone else have clues to offer here?

>>	Then have a very careful look at your Pburst settings in net.cfg
>>so that you don't ask for more information than can be buffered by the
>>board. That's PBurst read window and PBurst write window, with the number
>>being the number of KB outstanding (make it less than 8 to stay within
>>normal board buffer constraints).
>
>Ok, I tried turning it down both to 8 and to 5 and neither seemed to
>make any difference.

	Take your Ethernet board's buffer capacity, divide by 1.5KB per
Ethernet packet, allow for one outgoing packet, and that's the largest
amount of Pburst traffic one ought to use. Smaller buffers mean more
chance of overruns, so use shorter bursts. Broadcast traffic impacts
things too, for obvious reasons.
	Let's look at your net.cfg below.
	PB buffers= is a boolean, 0 meaning no PBurst activity, anything
else means allow PBurst. That's why changing from 8 to 5 had no effect.
	PB read/write window are the number of KB allowed in a burst, and
you have them set to 64. 64 = 64KB >> your Ethernet board's buffer
capacity. See the Sniffer for a decoding of what your site's PBurst
traffic stream looks like.
	Here is a clipping of my net.cfg for a NE-3200 bus mastering EISA
bus Ethernet adapter:

NetWare DOS Requester
	PB buffers=1
	PBurst read window 6
	PBurst write window 6
	checksum=on             ; off speeds up high quality links


>Here's my NET.CFG file as it was originally.  Should I set the PBurst read
>and write windows down to 8 (or below?) even though there seems to be no
>difference?  Have I missed something really obvious here?  This is my
>first attempt at using VLM's so I admit that I'm a bit fuzzy on some of
>the options even after going though the on-line docs.

The three lines below go under major heading NETX rather than against
the left margin as major headings themselves.

>SHOW DOTS ON
>PREFERRED SERVER=NORWAY
>FILE HANDLES=150
>
>Link Driver 3C5X9
>	FRAME Ethernet_802.3
>
>PROTOCOL IPX
>	IPX PACKET SIZE LIMIT 1500

	Why bother with the line above?

>	IPX RETRY COUNT 10
>
>NetWare DOS Requester
>	FIRST NETWORK DRIVE = F
>	NETWARE PROTOCOL = NDS BIND
>	AUTO RETRY=10
>	BIND RECONNECT=ON
>	CACHE BUFFERS=40
>	CACHE WRITES=ON

	If you cache locally then all bets are off about data integrity.
I turn off local caches.

>	CHECKSUM=0

	Not a good thing, above

>	LARGE INTERNET PACKET=ON
>	LOAD LOW CONN=ON
>	LOAD LOW IPXNCP=ON
>
>	PB BUFFERS=8
>
>	PRINT BUFFER SIZE=256
>	SIGNATURE LEVEL=0
>	PBURST READ WINDOW SIZE=64
>	PBURST WRITE WINDOW SIZE=64

	See comments in the running text

>	MESSAGE TIMEOUT=10000

	Joe D.

---------

Date: Wed, 19 Jun 1996 09:52:34 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: File Retransmission with Packet Sniffer

>>>NetWare DOS Requester
>>>	FIRST NETWORK DRIVE = F
>>>	NETWARE PROTOCOL = NDS BIND
>>>	AUTO RETRY=10
>>>	BIND RECONNECT=ON
>>>	CACHE BUFFERS=40
>>>	CACHE WRITES=ON
>>
>>	If you cache locally then all bets are off about data integrity.
>>I turn off local caches.
>
>Joe, can you expand on this statement? Good or bad?

	Material in client cache is just sitting in memory as a bunch of
outgoing bytes, without (I believe but have no facts to substantiate)
checksums. Thus anything on the PC can crunch bytes in that memory area and
no one would know. Such wild pointers are not uncommon. Plus, the cache
really needs to be synchronized with the master copy on the file server,
and NetWare Client32 tries to do that with selective locking. I don't
trust data sitting around unprotected as this stuff is, and I don't fully
trust the interlocking between client and server on who owns what when.

>I've been banging away on the same problem that John presents for several
>weeks now, with little success. My ipx side currently runs about 10% file
>retransmissions & loops on request. I don't even want to TALK about the IP
>side, the web, and connections to remote sites...

	Well, there are lots of things which could go wrong and, as you
indicate, the various drivers in the client plus server link are certainly
prime suspects. 10% failure rate is very very high compared to normal
operations, even though the system continues to run, and given the lack
of strength in IPX + NCP protocol stacks (fewer checks mean things run
faster, and also means server crashes from unexpected events, etc, but
it runs faster while it runs...) I'd say that a high error rate is asking
the system to mess up big time.
	As suggested previously, turn on IPX checksumming as a safety
measure. (For other readers: it can't be done with Ethernet_802.3 frames.)
	We will have to wait for your deeper investigations.
	Joe D.

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

Date: Wed, 3 Jul 1996 12:06:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Multiple Protocol in NET.CFG file

>Does anyone know how (or whether it is possible) to bind IPX to
>mulitple protocols?  We are changing IPX protocol bindings soon (due

	Well, picking nits, the term is frames rather than protocols, even
	if Novell has overburdened the word "protocol" in net.cfg.

	The answer is no. IPX attaches to one and only one frame and hence
	one IPX network number because clients are unable to route IPX
	(routing is needed when comms pathway alternatives are present).

	The suggestion is just change client net.cfg files, reboot them,
	and in two minutes the switch is completed. Then unbind the
	[old] frame kind on the server.

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

Date: Wed, 10 Jul 1996 13:17:58 +0200
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Advice re Net.cfg settings

>I wonder if someone could comment on the following Net.cfg file
>settings.
>
>NET.CFG
>
>Link Driver 3C503
>	PORT 300
>	FRAME Ethernet_802.2
>	INT 3
>
>NetWare DOS Requester
>	FIRST NETWORK DRIVE = F
>	USE DEFAULTS = OFF
>	VLM = CONN.VLM
>	VLM = IPXNCP.VLM
>	VLM = TRAN.VLM
>	VLM = SECURITY.VLM
>;	VLM = NDS.VLM
>	VLM = BIND.VLM
>	VLM = NWP.VLM
>	VLM = FIO.VLM
>	VLM = GENERAL.VLM
>	VLM = REDIR.VLM
>	VLM = PRINT.VLM
>	VLM = NETX.VLM
>
>Protocol IPXODI
>	Bind 3C503
>	SPX Connections = 5
>	IPX Sockets = 20
>
>This file is present on all workstations within the company where I
>work. Are the following settings sufficient? Furthermore are these
>settings required for all workstations especially those running
>Rprinter i.e. Print Buffer size,Print Header and Print Tail?

It sure can use some tweaking, see a tweaked example below and read
the data to be found in the FAQ and accompaning documents.

>All users run Windows and MSOffice applications from their local hard
>disk and save their data files on the File server.

I would run applications from the server, hence giving you the
possibility to maintain them and make backups.

I would ditch the 3c503 card, it is a slow 8 bit thingy from the
past. I adjusted the read/write window to what the 3c503 can handle.

;   New NET.CFG
;
Link Driver 3C503
	INT 3
	PORT 300
	FRAME Ethernet_802.2
;
Protocol IPXODI
	Bind 3C503
	SPX Connections = 5
	IPX Sockets = 20
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = BIND
	Load Low CONN           = On
	Load Low REDIR          = On
	Load Low IPXNCP         = On
	Load Low NETX           = On
	Connections             = 8
	Average Name Length     = 8
	Max Tasks               = 50
	Checksum                = 0
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 8
	Cache Writes            = On
	Pb Buffers              = 1
	Pburst Write Window Size= 6
	Pburst Read Window Size = 6
	LIP Start Size          = 1500
	True Commit             = Off
	Local Printers          = 0
	Network Printers        = 3
	Print Buffer Size       = 16
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Show Dots               = On
	Preferred Server        = ????
	Long Machine Type       = IBM_PC
	Dos Name                = MSDOS
;

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

Date: Fri, 27 Sep 1996 14:33:07 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Ethernet frames, net.cfg, cont'd

	Here's a little more detail on net.cfg internals. I used to have
a blow by blow writeup of how net.cfg was read, but it's now buried.
Some points to look for are the indented Frame lines are interpreted
differently than the indented Protocol lines, surprizingly but true.
And the indented Protocol lines work with names of protocols, such as
IPX/IP etc; those names must be spelled exactly the way the protocol
stacks want to see them. The protocol descriminator number, such as 8137,
must match the frame kind for that protocol because the LSL and MSM parts
of ODI use it to direct packets to the right places.
	The indented protocol lines represent a triplet which must be just
right in all parts. The flush left (major division) Protocol lines start
section headings for use by the named "protocol" which actually means by the
named protocol stack/program, and spelled as that stack wants to see them.
Flush left and indented protocol sections are unrelated, even though the
word "protocol" appears in both.
	The text below is the shortened version of affairs, part of the
MS-DOS Kermit distribution material, and I've shortened it more for this
message. Even so it makes excellent bedtime reading material.
	Joe D.
--------------
(1.2) ODI DRIVERS

ODI is Novell's Open Datalink Inteface, providing a uniform way for the
application to talk to the network board, independent of which networking
method it uses: Ethernet, Token Ring, etc.  MS-DOS Kermit supports this method
directly.  That is, it talks directly to the ODI driver.

Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of
Ethernet frames: DIX/Blue-Book/Ethernet_II, Token Ring, Arcnet, and PCLan
broadband.  No extra protocol "shim" is needed, but you must have ODI drivers
from Novell or your network board vendor.

The mechanics are roughly the same as for packet drivers.  The driver
configuration, however, is done differently.  Rather than feeding command-line
parameters to the driver, a file called NET.CFG is created to give certain
information not only to the driver, but also to the applications that use it.

ODI drivers generally come on a diskette packaged with your network board.
Novell supplied drivers and ODI components are available from Compuserve
and across the Internet from ftp.novell.com and its official mirror sites:

  BNUG FTP server, bnug.proteon.com [128.185.17.201]
	(now bnug.harvard.edu [128.103.85.201])
  University of Groningen, ftp.rug.nl [129.125.4.15]
  University of Salford, ftp.salford.ac.uk [146.87.0.201]
  Utah State University, netlab2.usu.edu [129.123.1.44],
   netlab1.usu.edu [129.123.1.43]
  Lincoln University, tui.lincoln.ac.nz [138.75.80.3]
  National Research Council (Canada), novell.nrc.ca [132.246.160.4]

Example Ethernet NET.CFG file, using VLMs in this case

; File NET.CFG for NW 4.0 and for VLMs
; Don't forget to say  lastdrive=z  in config.sys!

Netware dos requester
	<details omitted here>

Netx
	show dots=on

;# Below this line material is the same as for NetWare 3.x and for NETX

protocol KERMIT
	bind ne2000

Link Support
	Buffers 6 1600
	MemPool 2048

Link Driver NE2000
	INT 5
	PORT 360
	FRAME   Ethernet_II
	Protocol IPX    8137    Ethernet_II
	Protocol IP     0800    Ethernet_II
	Protocol ARP    0806    Ethernet_II
	Protocol RARP   8035    Ethernet_II

Please notice several things about this file. Items must be spelled as shown,
indented items must be indented (with a tab for SMC drivers), and flush left
items must be flush left. There is no, none, zero, creativity permitted in
this material, and that applies especially to the indented protocol lines.
IP is not IPX, so don't get them mixed up.  Please type carefully.

Ethernet clients must use Ethernet_II frames for TCP/IP work (IP, ARP, and
RARP).  Token Ring clients will use TOKEN-RING_SNAP for the frame kind with
IP, ARP, and RARP.  The protocol ident values are the same as above.

LINK DRIVER TOKEN
	INT 3
	FRAME TOKEN-RING
	FRAME TOKEN-RING_SNAP
	PROTOCOL IPX  E0   TOKEN-RING
	Protocol IP   0800 TOKEN-RING_SNAP
	Protocol ARP  0806 TOKEN-RING_SNAP
	Protocol RARP 8035 TOKEN-RING_SNAP

Arcnet clients will use NOVELL_RX-NET for the frame kind, and the protocol
ident values will be D4 for IP, D5 for ARP, and D6 for RARP, rather than 0800
etc, as per RFC-1201.

LINK DRIVER SMCARCWS
	INT 3
	PORT 300
	MEM D0000
	Frame NOVELL_RX-NET
	Protocol IPX  FA NOVELL_RX-NET
	Protocol IP   D4 NOVELL_RX-NET
	Protocol ARP  D5 NOVELL_RX-NET
	Protocol RARP D6 NOVELL_RX-NET

Which board will Kermit (or IPX or other application) use if two or more boards
are available? Although one would think the board could be selected by placing
the Protocol IP, etc, lines under the desired Link Driver section, such is not
the case; those lines tell LSL the frame kind to associate with the protocol
(say IP) but not the board.  The frame lines are associated with particular
boards, however.  By default, the application chooses "the first board"
offering a suitable frame, regardless of whether or not the Protocol IP, etc,
lines are present for that board. "First" refers not to the contents of NET.CFG
but to the order in which board drivers are loaded at DOS level.  So the
indented protocol lines tell ODI which frame a protocol needs, and a TYPE to
use for recognizing packets, but the lines do not identify a particular board.

To target a particular board, a separate main section is used in NET.CFG.  The
section starts with the word Protocol against the left margin and has Bind
indented beneath it, like this -

	Protocol Kermit              Identifies Kermit section of NET.CFG
		bind SMCPLUS         Bind to SMCPLUS board driver

When a board name is used more than once then the alternative form is to use
a board number in place of the name:

	Protocol Kermit
		bind #2              Bind to the board loaded second

Kermit considers the text in these sections to be case-insensitive.  The
#<digit> construction must not have a separation between the number sign (#)
and the digit. The #<digit> case is normally used when two or more boards share
the same driver and thus are not distinguishable by name alone.  Note that
IPXODI now can use only the #number form.
	<omissions>
If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the
first loaded board, SMCPLUS, in the absence of a "bind" command.  Putting the
section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG
selects a particular board for Kermit.

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

Date: Wed, 2 Oct 1996 18:23:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 802.2 -Reply

>>I am being sent to a place where the Novell server is using 802.2, my
>>question is On the client side in the net.cfg aside from stating frame
>>ethernet_802.2
>>do I need a statemet;
>>	;protocol ipx 00 ethernet_802.3
>>	;Protocol ipx 8137 ethernet_ii
>>	protocol ipx ???? ethernet_802.2
>>what is the protocol number for 802.2 What is the hex protocol id for 802.2.
>>I have looked thru the nw online manual but cannot find it.
>
>You don't need a hex id for it.  For example, here's part of my net.cfg:
>
>Link Driver EPROODI
>	port #1 300
>	frame ETHERNET_802.2
>	frame ETHERNET_II
>	protocol IP   000000000800 ETHERNET_II
>	protocol ARP  000000000806 ETHERNET_II
>	protocol RARP 000000008035 ETHERNET_II
>
>Protocol IPX
>	Bind 1
>
---------
	Let me explain a little, and answer the question.
	The number which appears in indented lines
	protocol NAME NUMBER frame-kind
is a 16-bit hexadecimal value (four written characters), and it goes
into/is read from frames on the wire such that items are delivered to
the NAME stack rather than some other protocol stack. This protocol
identifier is the controller of a software switch at each end which links
protocol stacks to boards and their drivers. Click the switch to the wrong
position on either end and things don't work.

	For IPX the NUMBER goes like this (is in many Novell docs):

	Protocol IPX    8137    Ethernet_II, Ethernet_SNAP, Token-Ring_snap
	Protocol IPX    0000    Ethernet_802.3
	Protocol IPX    00E0    Ethernet_802.2, Token-Ring
	Protocol IPX    00FA    Novell_RX-NET (Arcnet)

	That means the NUMBER is four hex digits, with leading zeros being
optional (but best to state anyway). The NUMBER associates a protocol stack
(say IPX) with a kind of frame on the wire (say Ethernet_II).
	By way of contrast, on Ethernet IP is 0800 Ethernet_II, ARP is
0806 Ethernet_II, RARP is 8035 Ethernet_II, and LAT is 6004 Ethernet_II.
On Arcnet the values are IP 00D4, ARP 00D5, RARP 00D6, all on Novell_RX-NET.

	Someone at Novell decided that the average user would never get
this straight, given the paucity of readable documentation explaining why,
and they let ODI components quietly insert the equivalent of the above
indented Protocol IPX line into the ODI machinations. Lan WorkPlace for DOS
does its own dynamic internal addition for IP and ARP. Alas, the variety of
media often requires a new identifier, and that means such code ends up
carrying around the whole table. (Beneath the covers another set of
indentifiers are used to make the relation and that table is very difficult
to find, but then you don't need it unless you are writing ODI compatible
code; my list is 28 items long so far).
	Joe D.

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

Date: Tue, 5 Nov 1996 10:25:33 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: New name space stuff

>In net.cfg, how do I distinguish between two identical NICs? I have
>two 3c59x cards in my LX Pro in (according to INETCFG) slot 1 & slot 202.
>Novell talk about slot settings but in reference to EISA (my cards are
>PCI). Is slot now relevant to PCI?

	One BIND's #<number>  where number is the logical board. Logical
boards are counted from 1, as the first loaded adapter first mentioned
frame kind, then the same adapter and next frame kind, etc through the
next adapater and its frame kinds.
	Thus the INDENTED line
	BIND #2
would bind that particular protocol object to the second logical board,
counting frame kinds within adapters. Note that ODIPKT makes a mistake and
counts from 0.
	Joe D.

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

Date: Tue, 5 Nov 1996 17:02:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: updated on 2 NIC question

>Sorry...I should've been more clear: occasionally, I need my server to be a
>(very expensive) workstation. Our server room is in another building & I'm
>always forgetting to bring everything I need. So, during setup, it's helpful
>if I can get to the network to copy drivers to the new server's DOS
>partition. The problem is that I'm not sure how to configure the net.cfg to
>distinguish between my two identical PCI NICs.
----------
	They have different hardware settings, right? So you load the
driver twice, once for each board. The first board loaded gets logical
board numbers 1..<qty of frames under its heading>, and the second board
gets logical board numbers above that. Under major heading "Protocol IPX"
indent a "BIND #<digits>" clause to pick one frame from one board. That's
what I tried to explain last time I responded to this question. Look at
the screen as you do the loading by hand.
	Joe D.

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

Date: Tue, 3 Dec 1996 10:55:48 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Pburst at 64kbps

>I have been testing a 64kbps WAN link by copying several files from a
>workstation on one end of the link to a server on the other end.
>
>I noticed that pburst did not fare well in this situation (many
>missing pieces that had to be resent).  In fact, at one point, it got
>into a loop where one missing piece was being continually re-requested
>and dropped, hanging the copy operation.
>
>When I disable pburst, the files appear to copy fine, albiet slowly.
>
>Why does pburst do so poorly over this link while a non-burst copy
>(apparently) does fine?
-----------
	I should bring this one to class. It is a classical situation of
inadequate end to end flow control, with a limited WAN link in the middle,
and the inherent difficulty of end nodes negotiating a suitably small burst
length because they have no direct knowlege of the weak link in the middle.
	If your WAN link is a couple of comms black boxes plus Telco wire
then look at the manuals on those boxes and find their buffer capacity. Set
Pburst to stay within that buffer capacity (after allowance for competing
traffic). The controls are lines Pburst read window= and Pburst write
window= in net.cfg. The number is garbled in Novell docs and I interpret it
to be the number of full length frames (576 bytes each when crossing an IPX
router), though it can also be interpreted as the number of kilobytes in a
burst. There is a third parameter in net.cfg, lip start size= which tells
Pburst the longest frame length to try across the link; units is bytes.
	I might add that TCP does handle this situation by design. It's
called congestion control and avoidance, and congestion here is too many
packets queued for transmission across the slow link. It observes the link
by testing it and then adapting to the link capacity dynamically as traffic
load changes; there is no negotiation between clueless end nodes.
	Were I designing the comms black boxes I'd provide "back pressure"
on local senders when the transmission buffer fills, by causing a fake
collision or a full duplex Ethernet busy signal (preamble bits going on and
on as per Richard Steven's suggestion). Etherswitches have exactly the same
problem, but at higher speeds, when many inputs compete for time on the
same output port.
	All in all, some very basic networking concepts are involved here.
We will see them again on the final, so now is a good time to ask questions...
	Joe D.

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

Date: Mon, 27 Jan 1997 14:43:16 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NET.CFG question

>>Link Support
>>	Buffers 8 1500
>>	MemPool 4096
>>
>>Link Driver 3C90X
>>	FRAME ETHERNET_802.2
>>	FRAME ETHERNET_II
>	protocol IPX 0 Ethernet_802.2
>	protocol IP 0 Ethernet_II

	Errors here. IP in Ethernet_II frames is protocol TYPE 0800, meaning
		     Protcol IP 0800 Ethernet_II
	Add also     Protocol ARP 0806 Ethernet_II
		     Protocol RARP 8035 Ethernet_II

>>
>>Netware DOS requester
>>	first network drive = G
>	name context = ".???"

	The lines above do not belong in the middle of lan driver material.

>Protocol IPXODI
>	bind 1
	The proper syntax is BIND #digit  such as BIND #1.
	There is no need for BIND when there is no alternative, and
	the above has precluded alternatives.
	Joe D.

>>>
>>>Protocol TCPIP
>>	bind 2
>>>	PATH SCRIPT     c:\apps\lwp4.1\script
>>>	PATH PROFILE    c:\apps\lwp4.1\profile
>>>	PATH LWP_CFG    c:\apps\lwp4.1\hstacc
>>>	PATH TCP_CFG    c:\APPS\lwp4.1\TCP
>>	ip_router x.x.x.x
>>	ip_netmask 255.255.255.0
>>	ip_address x.x.x.x

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


Date: Mon, 27 Jan 1997 20:31:34 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Client32 for Win95 error

>We have experienced the same problems on token-ring with client32 and
>have a fix.  I was hoping to write this up with packet traces and
>everything, but since others are suffering...
>
>Or problems were with the IBM Token-Ring Adapter and IBM Auto LAN
>Streamer PCI on a 4MB (don't ask) ring communicating with a well
>patched NW 3.12 server.  We patched all the client junk and had no
>luck.
>
>When we attached a LANAlayzer to the ring the problem was
>*immediately* apparent.  There were errors in packet size
>negotiation during the writes to the server. The client and server
>were negotiating a Large Internet Packet exchange and arrived a
>packet size of about 8KB.  This of course is too big for token-ring.
>We saw packets reportng missing data, the client and server would
>renogitate packet size and again choose a stupidly large size and
>fail.  This foolishness goes on forever.
>
>We weren't sure why LIP was involved when the client and server were
>on the same wire, but we turned LIP off and the problem was fixed on
>most of the machines.  The IBM Token-Ring Adapter equipped PCs (PS/2
>Modell 77s with MCA) needed the latest Client 32 update as well as
>they would still barf on some large file copies.
>
>I'd add the packet traces, but they are at work on a local disk and I
>am not there.  Stay tuned...
----------
	There is a more elegant and rational solution. In STARTUP.NCF add
	SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE=  number of bytes
and that should stop the overly long attempts. The lan driver ought to have
done this anyway, but some writers read the fine print better than others.
One can achieve some cleanups in net.cfg too, but telling ODI to start
Long Packet tests at a 4KB size:
	NetWare DOS Requester
		lip start size= number of bytes such as 4200 for Token Ring
				or 1500 for Ethernet_II

This eliminates trying very long packets irregardless of the ability of
the media to carry them.
	Joe D.

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

Date: Mon, 10 Feb 1997 17:02:54 EST
From: Philip Chase <pbc@VPHA.HEALTH.UFL.EDU>
Subject: Re: No F drive after attaching to server

>When the laptop connects to the server and before a user logs in to the
>network, how is the Login directory mapped to a letter?
>
>And how can I make my first network drive be F instead of D when running
>VLM?  (I couldn't do it by changing lastdrive=z  because it is loading
>the VLM and removing the offending module.

The file netcfg.txt in vlmkt2.exe mentions new parameters.  You might be
interested in this part:

  FIRST NETWORK DRIVE = <none>       A         Z         GENERAL.VLM
							 NETX.VLM

  NOTE: If FIRST NETWORK DRIVE is not specified, it will default
	to the first available drive letter.

Make sure you put this under the header "netware dos requester".  Best to
read about the other parameters as well.  There are many valuable ones that
arrived with the VLMs.

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

Date: Tue, 1 Apr 1997 11:05:51 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Maximum number of server attachment

>We have some users who wish to attach to more than 8 novell server at one
>time.  I have tried netx, vlm and client 32, all of which only allow me
>to make 8 attachments.  Is there anyway that I can incease the number of
>server attachment ?  All of our servers are netware 3.12 and our clients
>are running NETX.

There are two issues here.  First, the client...

NETX has a static connection table, with room for 8 connections.
No options there.

With VLM's, you can put a line "connections=x" in the "Netware DOS
Requester" section of your NET.CFG.  'x' can be from 2 to 50.

Client32 doesn't have a setting for maximum connections, it's completely
dependent upon the memory you have.

The second issue is most likely the one into which you're running.  VLM's
and Client32 are backwards compatable, to a degree, with the NETX shell.
When a program uses an older shell-oriented function call to attach to a
server, it uses the static connection table instead of the full connection
features of the client, so you'll never get more than 8 connections.

So, how are these people trying to attach?

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

