millar@rocket.uucp (Jeff Millar) (05/02/91)
I have been following this group and other related groups for about 4-6 months now and still haven't really grasped the way TCP/IP goes together...maybe someone could help me out and refer me to a book, file of explanation, or could explain it here. I probably should mention that currently use FTP software's PC/TCP in conjunction with their "Netware Workstation" product to allow me to be logged into the Netware server and perform TCP/IP operations at the same time. Figuring out IPCUST.SYS, IFCUST.SYS, etc were confusing but got it done in the end...never did figure out all the details though. Some questions follow... - What is NDIS, what is it used for? - When would I use a Clarkson packet driver? - When would I use a BYU what-ever-it-is? - Why does FTP Inc. ship all that public domain software with their product? Gotta go...maybe more later...thanks in advance, jeff -- Jeff Millar millar@rocket.sanders.com
fks@FTP.COM (Frances Selkirk) (05/03/91)
Our WHAT product? Our current methods for Novell compatibility on Ethernet (Token Ring is easy, of course) use the packet drivers for demuxing, and a Netware IPX packet driver shell (BYU for PD, or one of the OEM shells). Did someone actually call this a "Novell Workstation" product? (sigh) For your questions: NDIS is the Network Driver Interface Specification, written by 3Com and Microsoft. The Packet Driver Specification is an earlier specification written by John Romkey at FTP Software, and currently maintained, here, by James Van Bokkelen. Both of these specifications, provide a means to develop drivers with a standard interface. These drivers are then usable by all software written to use that interface. From the viewpoint of the developers of the upper layer software packages, adherence to one of these specifications provides instant compatibility with large numbers of network boards. Both specifications also provide the capability to sort incoming packets between two stacks of different protocol types, sending, in the case of Netware and PC/TCP, IPX packets to the Netware stack, and IP packets to the PC/TCP stack. This is also useful. (A similar specification, ODI, is available from Novell, but it is a commercial, rather than free, specification. This has limited its support considerably.) Whereas support for the packet drivers is largely freeware, or by smaller companies, many large, mainstream board manufacturers have NDIS drivers. Corporations and organisations that require all their software to be supported will often prefer an NDIS solution to a packet driver one. FTP Software provides a module that converts between a program that expects a packet driver, and an NDIS driver. A version of this has been released into the public domain, and is available by anonymous ftp from vax.ftp.com. The Clarkson collection of packet drivers is the largest collection available. They are all freeware, and available by anonymous ftp to omnigate.clarkson.edu (I think that's the current site...). The Clarkson drivers are frequently updated and well maintained. Although the software is not, technically, supported, the collection's maintainer, Russ Nelson is responsive to bug reports. In addition to the Clarkson drivers, FTP Software distributes a large number of packet drivers written by card manufacturers. The BYU shell is a packet driver compatible Netware shell. You would use this if you didn't have another (for instance, Western Digital's) available from your board manufacturer, to run Netware over a packet driver. Brigham Young University sold the rights to their shell to a company (CoCoNet?) over a year ago, but older versions, such as we include, remain publicly distributable. Our software is usually sold for a specific network interface card, but we have a few distributions which are for specific driver specifications, such as the packet driver specification, and the Token Ring ASI specification. Most people who get our "generic" package, have bought it for one of two reasons: either they want to be able to switch among cards, or they want to use the demuxing capabilities of the packet driver or NDIS drivers. With this package, therefore, we try to include most of the additional free software (most of which, I should point out, is freeware, not public domain) that they might want. It's far less hassle to the customer, and it's actually less hassle to us than constantly reciting the ftp sites where these things are available, and sending copies to the (many) users who do not have Internet access. It also encourages familiarity with, and use of, these drivers, which leads to greater demand for them, and thus more driver development, and greater software interoperability. We see this as a Good Thing for the Internet community. Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880 (Happy May!)
jbvb@FTP.COM ("James B. Van Bokkelen") (05/04/91)
- Why does FTP Inc. ship all that public domain software [the Clarkson
Packet Driver collection] with their product?
Ultimately, because John Romkey, Dave Bridgham and I each wrote 7 or 8
different network board drivers - quite enough to get very tired of them;
They're about the most frustrating coding work I've ever done, and the
quality of documentation available from most manufacturers doesn't help.
John wanted to push the responsibility for the hardware driver back to the
board vendor, and make them ship it on a diskette with the diagnostics,
along with every board. Then the user could just use whatever protocol
stack he wanted. IBM had enough clout in the 802.5 world so that *everything*
has an Adapter Support Interface (TOKREUI or LAN Support Program) driver.
Apple had enough to do the same with Appletalk and Ethernet cards for Macs.
However, in the Ethernet world, things aren't so simple. There were probably
a dozen Packet Drivers extant when Microsoft and 3Com first came out with the
Network Device Interface Specification in 1988; they may not have been aware
of the Packet Driver spec, and in any case were pursuing a solution for both
DOS and OS/2 (which the PDS doesn't handle). Limitations in v1 of the NDIS
spec (v2 came out in 1989, but I haven't yet seen a driver conforming to it)
led to continued Packet Driver development, including the freeware collection
centered around Russ Nelson of Clarkson U's skeleton driver. Then Novell,
for reasons which have at least some basis in the intense competition between
Netware and LAN Manager, came out with Open Datalink Interface. The ODI spec
first appeared in draft form in 1988, but the first few drivers didn't ship
till this year.
So, there are now three different ways to talk to Ethernet cards. Almost
every board vendor has an NDIS driver (there are probably more than 100 of
them). I don't know if they exist for Novell cards, but I know they do for
the Excelan product line. Not all of them are easy to lay hands on (some
vendors charge extra, some ship the drivers if you ask for them, some always
include them). Quite a number of vendors have their own Packet Drivers, and
the freeware is available in source form, which makes it easier for vendors
and the academic community to create new ones (there are probably around 75
Packet Drivers all told). ODI is new, and its acceptance is limited because
you have to (last I knew) license the Link Support Layer module from Novell
even if you aren't going to use Netware. There are only about 10 or 15 ODI
drivers available at this time (Novell did them for both their own cards and
3Com's, Interlan has one for the NI5210). As Frances said, we ship the
freeware to make things simpler for the end-user, who is the real victim of
this regrettable confusion.
The Packet Driver spec (v1.09 is current) and both v1 and v2 of the NDIS
spec are available for anonymous ftp from vax.ftp.com. The ODI spec is
only available in printed form from Novell as of this date.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901nelson@sun.soe.clarkson.edu (Russ Nelson) (05/04/91)
In article <MILLAR.91May2110044@sleepy.sanders.com> millar@rocket.uucp (Jeff Millar) writes:
[ John, do you think you should add these to the FAQ file? -russ ]
- What is NDIS, what is it used for?
NDIS stands for "Never Do It Simply", or "Now Don't It Suck", or maybe
"Network Device Interface Specification", or something like that. It's
Yet Another Standard promulgated by that great ignorer of defacto standards,
Microsoft (and I guess 3Com had something to do with it also).
All sarcasm aside, it does basically the same job as the packet drivers.
The technical details are a little different, and you can argue until you're
blue in the face about which is better. As a practical matter, LAN Manager
requires an NDIS driver, so NDIS isn't going away. And I'm a crazy man,
so the packet drivers aren't going away either.
- When would I use a Clarkson packet driver?
Ahem. They're the Clarkson *collection* of packet drivers. We didn't write
them all, in fact we've only done about half. But anyway, you'd use a
packet driver with a packet driver client, like NetCure, or its follow-on
product, the Beholder, or Netwatch (or it's much-improved descendent Lanwatch
from PC-FTP Software), or KA9Q, or PC-NFS, or NCSA Telnet, or CUTCP, or WATTCP,
or ICE-TCP, or B&W (no, not Black&White, but Beame & Whiteside), or Win/TCP
etc....
All of the above have their own built-in drivers, but given that a company
can write *one* packet driver and run with any of the above packages, you
can guess what a company will do...
- When would I use a BYU what-ever-it-is?
You mean the BYU packet driver shell? It's a bit of software that convinces
Novell's IPX to use a packet driver instead of going directly to an Ethernet
card. That gives you two advantages: you can use a card that doesn't
have a Novell driver (that's the null set, just so'd you know), and (more
importantly) you can use TCP/IP while also running Novell.
- Why does FTP Inc. ship all that public domain software
with their product?
They're from MIT, it's in their blood.
Not to mention the fact that the software enhances their product. Oh, and
by the way, the Clarkson collection of packet drivers aren't public domain.
They *are* freely copyable, but copyrighted with the "copyleft". The
copyleft prevents anyone from failing to distribute the source if they
distribute the executables, and it also prevents them from making the
program non-freely copyable.
Well, actually, it doesn't *prevent* them, it just makes it illegal.
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.jbvb@FTP.COM ("James B. Van Bokkelen") (05/06/91)
.... As a practical matter, LAN Manager requires an NDIS driver, so NDIS
isn't going away. And I'm a crazy man, so the packet drivers aren't going
away either.
Regardless of your sanity, which I wouldn't have questioned in any case, you
can't unbind (disconnect) from a v1 NDIS driver except by re-booting. This
means that things like KA9Q and PC-IP whose protocol stack isn't a separate
TSR will never be able to use NDIS directly unless v2 drivers start to appear.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901RAF@CU.NIH.GOV (Roger Fajman) (05/07/91)
> .... As a practical matter, LAN Manager requires an NDIS driver, so NDIS > isn't going away. And I'm a crazy man, so the packet drivers aren't going > away either. > > Regardless of your sanity, which I wouldn't have questioned in any case, you > can't unbind (disconnect) from a v1 NDIS driver except by re-booting. This > means that things like KA9Q and PC-IP whose protocol stack isn't a separate > TSR will never be able to use NDIS directly unless v2 drivers start to appear. 3Com has something they call Demand Protocol Architecture, which allows protocol stacks to be loaded and unloaded in an NDIS environment. Is this something layered on top of NDIS then, so that not all NDIS stacks support it?
jbvb@FTP.COM ("James B. Van Bokkelen") (05/07/91)
3Com has something they call Demand Protocol Architecture, which allows
protocol stacks to be loaded and unloaded in an NDIS environment. Is
this something layered on top of NDIS then, so that not all NDIS stacks
support it?
Yes. It leaves a stub behind to stay bound to the NDIS driver when you
unload the stack, but I don't think they publish the interface. Conceptually
very much like the Packet Driver adapter, which can be used by anyone...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901nestor@hls.com ("Nestor A. Fesas") (05/08/91)
> > > .... As a practical matter, LAN Manager requires an NDIS driver, so NDIS > > isn't going away. And I'm a crazy man, so the packet drivers aren't going > > away either. > > > > Regardless of your sanity, which I wouldn't have questioned in any case, you > > can't unbind (disconnect) from a v1 NDIS driver except by re-booting. This > > means that things like KA9Q and PC-IP whose protocol stack isn't a separate > > TSR will never be able to use NDIS directly unless v2 drivers start to appear. > > 3Com has something they call Demand Protocol Architecture, which allows > protocol stacks to be loaded and unloaded in an NDIS environment. Is > this something layered on top of NDIS then, so that not all NDIS stacks > support it? > I'm not sure how 3Com does it, but we do it in just this fashion. Our ProLINC software was originally designed to operate over a proprietary interface that we call MPD (multiple protocol driver). MPD supports the concept of "unbinding" stacks from the driver. As such, when we produced our MPD to NDIS converter, this functionality was retained. In a nut shell, the MPD binds with the NDIS driver and begins monitoring incoming frames. Upon arrival of a frame, it is handed to the target protocol - if loaded. Otherwise, the MPD returns error code 03h (FRAME_NOT_RECOGNIZED) to the NDIS driver. The driver is then free to pass the frame on to the next protocol. I suspect that the Packet Driver to NDIS converter can do something similar. Maybe someone else can comment further. ............................................................................... Nestor A. Fesas, Jr. Hughes LAN Systems voice: (415) 966-7473 1225 Charleston Road fax: (415) 960-3738 Mountain View, CA 94043 inet: nestor@hls.com Mailstop 7
jbreeden@netcom.COM (John Breeden) (05/08/91)
In article <9105070330.AA05948@alw.nih.gov> RAF@CU.NIH.GOV (Roger Fajman) writes: >3Com has something they call Demand Protocol Architecture, which allows >protocol stacks to be loaded and unloaded in an NDIS environment. Is >this something layered on top of NDIS then, so that not all NDIS stacks >support it? DPA is just an NDIS protocol driver that's loaded as a TSR (which is unloadable) instead of a device driver (which is not unloadable). -- John Robert Breeden, jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."