------------------------------------------------------------ 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." 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 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 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 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 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 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 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" 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 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 Subject: Re: File Retransmission with Packet Sniffer >>From: Joe Doupnik > >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 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 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 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 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
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 # construction must not have a separation between the number sign (#) and the digit. The # 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. 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 " anywhere in NET.CFG selects a particular board for Kermit. ------------------------------ Date: Wed, 2 Oct 1996 18:23:47 -0600 From: Joe Doupnik 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 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 # 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 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.., and the second board gets logical board numbers above that. Under major heading "Protocol IPX" indent a "BIND #" 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 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 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 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 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 = 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" 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? ------------------------------