Section 03 NetWare shells & network card drivers (packet drivers, shims, ODI) What are Packet, ODI and NDIS drivers? Packet Drivers, ODI drivers, and NDIS drivers share a common purpose of recognizing packets coming in and distributing them to the appropriate piece of networking software as well as sending pre-built packets. Packet Driver was first on the block once FTP Software realized the difficulty of writing complete drivers for every Ethernet board on the market. It's a short specification that does little more than hand out packets; consequently a Packet Driver is very small (about 2.5K in memory) but highly effective. 3Com/Microsoft came out with the NDIS specification to accomplish the same goal, but with many enhancements. The specification itself is very large and difficult to understand, and the code was the same way. NDIS is most commonly seen on Lan Manager systems (3Com, Microsoft, DEC, AT&T, and so on). Then, most recently, Novell decided to tackle the board variety problem, but by starting from the top and looking down toward the hardware. Their ODI specification is the largest and most elaborate, and yet in many ways is the "best" of the bunch. Both NDIS and ODI drivers are commercial endeavors, but their specifications are public. However, neither NDIS or ODI makes any effort to accommodate alternate ("competing") protocol stacks. This is changing with the appearance of small software converter "shims" which have a Packet Driver interface as the common denominator. Novell's Lan WorkPlace for DOS is a shining example of providing an ODI driver supporting both NetWare and TCP/IP. You can see the pressures here: software vendors want a cheap way of using many boards because drivers are expensive to write, and users want everything, including the ability to run things requiring dual protocol stacks on a single board. The commercial NDIS and ODI drivers should be more solid than the volunteer effort Packet Drivers, and correspondingly harder to get changed when bugs are found. NDIS and ODI drivers need to come from board vendors; Packet Drivers come, normally, from individuals and are distributed via Clarkson University (you may get them by anonymous ftp from omnigate.clarkson.edu ). Currently, Packet Drivers have the widest acceptance and support base. NDIS is probably next and ODI is too new to be counted. It takes considerable time to fully understand a specification and produce an acceptable quality driver. [Thanks to Joe Doupnik for the substance of this answer.] --------------------------------------------------------------------------- What is Burst Mode and where can I get it? Burst mode is a protocol that will allow your server to send larger-than- normal packets in essentially a continuous stream. This will increase throughput when accesing large files. Applications include databases, backups, and similar. You can get Burst mode protocol (PBURST.NLM and BNETX.COM) by purchasing a disk called Windows Workstation Diskette from 800- Netware and asking for Updates and Upgrades. Cost is about $30. --------------------------------------------------------------------------- Where can I get Packet drivers? Crynwr Packet drivers (previously known as Clarkson packet drivers) can be found on Simtel-20 and its mirrors. If you are running Windows, you cannot run standard packet drivers if you desire to run any programs that use the packet driver while in enhanced mode. See Windows section for more details and a workaround. ODIPKT by Dan Lanciani is now two primary versions. The older 1.3 which contains support for PhoneNet and other things, and the newer 2.0 which supports dynamic send/recieve buffers. ftp from: hsdndev.harvard.edu:pub/odipkt. ODITRPKT is based on ODIPKT, and converts token ring packets (token-ring_SNAP to Ethernet class 1) to a format that is recognizable by a majority of tcp/ip software. It can be ftp'd from ftp.uws.edu.au:pub/pc/nupop/odipkt. --------------------------------------------------------------------------- How can I use Packet driver utilities with my Token-Ring card? One must understand that the token ring boards use a different frame type, so standard packet drivers will not work. The second procedure described here also will currently *NOT* support ODI. In short, you will be loading the IBMTOKEN packet driver which will emulate a 3-Com ethernet board, and since you "look" like an ethernet board, the packet types will match up properly. FIRST METHOD: ODITRPKT, the Token-Ring Packet Shim for ODI. The ftp source for oditrpkt is ftp.uws.edu.au:pub/pc/nupop/odipkt. ODITRPKT is a modified version of odipkt so that it would act as a class 1 packet driver for Token-Ring. So far it has been in beta test for several Months. There are a few bugs in beta8 (trumpet and Kermit don't work) but they do work with some other versions. SECOND METHOD: Load the IBM LAN Support Program modules as such: Config.sys: device=dmxa0mod.sys device=dmxc0mod.sys (note: you do not need the dmxt0mod.sys driver) Autoexec.bat: IBMTOKEN 0x60 0 (0x60 is the port number) IPX (version explained below) NETX make SURE that you use the IPX linked with the IBM LAN Support Program Driver v2.60. Version 2.62 will re-initialize the board and wipe out the packet driver!!!! You can probably find V2.60 on the original WSGEN disks that came in the NetWare package. Your ipx should be gen'ed as follows: Novell IPX/SPX v3.10 (911121) (C) Copyright 1985, 1991 Novell Inc. All Rights Reserved. LAN Option: IBM LAN Support Program Driver v2.60 (901031) Hardware Configuration: Self Configurable The setup you will end up with will be something like this: Token-Ring Card | IBM LAN Support Program (dx??????.sys files) | | | Packet Token Ring Driver | (IBMTOKEN) IPX (gen'd for LANSUP) | | | NETX | | | (Charon 4.0, standard logins, and other packet driver programs) If you want, there is also one other alternative, which works, but is a bit more restrictive. Using MS-Kermit 3.12, the latest version, you can go directly through ODI to the network card. The previous setup is still required if you want to use Charon, Trumpet, or any other packet-driver utilities. Some additional topics supplied by someone????: Software Development Joe Doupnik has published commented assembly language sources to directly interface with ODI. Since his TCP/IP code in MS-Kermit is said to base on the (also publicly available) Waterloo TCP sources, it should be possible to get those two together working. Maybe you convince the Waterloo folks to incorporate ODI support into their sources...:-) --------------------------------------------------------------------------- What are the protocol numbers for the NET.CFG? protocol ipx 0000 protocol ip 0800 protocol arp 0806 protocol rarp 8035 --------------------------------------------------------------------------- How can I tell if Packet Burst is running? How much am I improving? Dirk Howard from novell.com tells us: From the NetWare console, type in the command: SET ENABLE PACKET BURST STATISTICS SCREEN = ON Setting this settable parameter on a 3.11 server will result in a screen to which you can switch from the NetWare console screen. Besides the rows of zeros in the lower portion of the screen (which are not meaningful at present), there will appear in the upper left hand portion of the screen two numbers in the format xxx:yyy. The xxx number represents the connection number. Each workstation has a unique connection number. This connection number does not relate to any of the other connection numbers we are familiar with; it is unique to the Burst protocol. The yyy number is a hexadecimal value representing the Burst Gap Time. The value is usually low, around 0Eh. This number changes until it finds its optimal value. It should only take a moment for this number to settle to its final value, if it keeps getting higher and higher, this is evidence of a bug in the current version of the protocol. There will be a separate xxx:yyy for every workstation which is running Burst Mode and is connected to that server. Switching to the Packet Burst Statistics Screen is helpful when no perceptible performance increase is noted - it may be that the client is not actually running Burst Mode. This is usually due to neglecting to add the PB Buffers = [2-10] line to the NET.CFG. --------------------------------------------------------------------------- [HTML 2.0 Checked!] --------------------------------------------------------------------------- Return to the FAQ Index David Rawling - David.Rawling@efs.mq.edu.au