king@vrdxhq.verdix.com (Greg King) (02/20/91)
Can anyone tell me if Netware supports the NDIS interface spec or the packet driver spec? Also what are the basic differences between Netware 286 and Netware 386? Are different drivers required? Much Thanks in Advance, Greg King Verdix Corporation 14130-A Sullyfied Circle Chantilly, VA 22021 703-378-7600 x288 king@verdix.com
jrd@cc.usu.edu (02/26/91)
In article <46945@vrdxhq.verdix.com>, king@vrdxhq.verdix.com (Greg King) writes: > Can anyone tell me if Netware supports the NDIS interface spec or > the packet driver spec? Also what are the basic differences between > Netware 286 and Netware 386? Are different drivers required? > > Much Thanks in Advance, > > Greg King > Verdix Corporation > 14130-A Sullyfied Circle > Chantilly, VA 22021 > 703-378-7600 x288 > > king@verdix.com > Greg, Novell supports neither Packet Drivers nor NDIS. They do support their own Open Data-Link Interface (ODI, sometimes ODLI) which provides similar protocol multiplexing capabilities. That makes three "standards" these days. The specifications for ODI are available from Novell for a fee, and they form a substantially thick stack of paper. Is it possible to convert one to the other? Yes, it is, with some loss naturally, but those solutions (called "shims") are basically experimental and not for production use. NW/286 and NW/386 (or using the new machine independent name of NetWare 3.11) are completely different animals under the skin so drivers do not carry across at all. Workstations continue to work with old and new shells (backward compatibility) on both vintages of servers. If given a choice between NetWare 2.x and 3.x then choose 3.x if finances allow (particularly when a long term view is taken). My view is that 3.x is worth the money and then some for large groups of users. Joe D.
mjhammel@Kepler.dell.com (Michael J. Hammel) (03/02/91)
In article <1991Feb25.192415.46941@cc.usu.edu>, jrd@cc.usu.edu writes: > Novell supports neither Packet Drivers nor NDIS. They do support > their own Open Data-Link Interface (ODI, sometimes ODLI) which provides > similar protocol multiplexing capabilities. That makes three "standards" > these days. The specifications for ODI are available from Novell for a fee, > and they form a substantially thick stack of paper. Is it possible to > convert one to the other? Yes, it is, with some loss naturally, but those > solutions (called "shims") are basically experimental and not for production > use. Ok, now I know where the ODI spec is. How about the NDIS spec? I have the packet driver spec. Someone here at work wants to know how the three are related and I really don't know at this point. Are all three Data Link Level protocols? Are there RFCs, ISO Refs, or other accepted standards reports for any of these (ie have they been adopted by any of the standards organizations)? I use the packet drivers with various applications. Who has NDIS applications? ODI? Has anyone implemented NDIS over packet-drivers? Vice-versa? Thanks net! Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Recycle. Just do it."
keith@ca.excelan.com (Keith Brown) (03/06/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc., San Jose, Califonia References: <46945@vrdxhq.verdix.com> Date: Fri, 22 Feb 1991 22:19:57 GMT In article <46945@vrdxhq.verdix.com> king@vrdxhq.verdix.com (Greg King) writes: >Can anyone tell me if Netware supports the NDIS interface spec or >the packet driver spec? Technically we support niether, although in reality NetWare client DOS workstations can be set up to make use of either type of driver. The method for setting up an IPX.COM to use packet drivers is pretty famous (infamous?) but if, like me, you've slept through the last thousand or so postings on the subject then send me some mail and I'll tell you how. I believe FTP software have a packet driver to NDIS converter TSR so that would be the (a?) way to run NetWare client software over NDIS. Our architecture for running multiple protocols at both the client and server side is the Open Datalink Interface (ODI). Many people are under the impression that we are in some way "competing" with both NDIS and the packet driver spec. We're not! The ODI and it's associated API really sits above the simple "send a packet, receive a packet" APIs of both NDIS and the packet drivers. The ODI understands medias and encapsulation methodologies and shields overlying protocols from having to worry about what type of network they are running on. It actually makes perfect sense to build ODI drivers for the NDIS "board" and the packet driver "board". The ODI adds value atop them! Although such drivers may soon exist, we are encouraging board vendors to write "hard wired" ODI drivers. 50 vendors recently attended our first training course on the subject of writing such drivers. Like British Rail, we are getting there :-) >Also what are the basic differences between >Netware 286 and Netware 386? Are different drivers required? > At the server yes. NetWare 386 (now NetWare v3.11) drivers have the ODI architecture. They support multiple overlying protocols on numerous underlying medias using many encapsulation methodologies concurrently (clever stuff this ODI!). NetWare 286 server drivers are not ODI. At DOS workstations there is no difference between NetWare 386 and 286 drivers. You will need to use our ODI drivers at the client if you wish to communicate with NetWare 386 servers over one of our newer supported encapsulations (eg, IPX over Ethernet SNAP) but if your running things ye olde traditional way, you can use ODI drivers, hard wired drivers, packet drivers, NDIS drivers or any other type of driver you can find that can get IPX packets onto a piece of cable! Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
romkey@asylum.SF.CA.US (John Romkey) (03/07/91)
keith@ca.excelan.com (Keith Brown) writes: >Our architecture for running multiple protocols at both the client and >server side is the Open Datalink Interface (ODI). Many people are under the >impression that we are in some way "competing" with both NDIS and the >packet driver spec. We're not! The ODI and it's associated API really >sits above the simple "send a packet, receive a packet" APIs of both NDIS >and the packet drivers. The ODI understands medias and encapsulation >methodologies and shields overlying protocols from having to worry about >what type of network they are running on. It actually makes perfect sense >to build ODI drivers for the NDIS "board" and the packet driver "board". >The ODI adds value atop them! From what I understand, ODI doesn't provide any logical (IP, for instance) to physical (MAC) address translation. If it doesn't, then any protocol stacks running above it still have to do this and know about the physical media they reside on. In that case, ODI's only real difference is that it builds media headers. Without the address translation, I don't think you can really claim that it's media-independent, as some protocols like IP will still have to provide media dependent code in them. -- - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141
donp@na.excelan.com (don provan) (03/07/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <1991Feb22.221957.18674@novell.com> <13782@asylum.SF.CA.US> Date: Wed, 6 Mar 1991 20:14:31 GMT In article <13782@asylum.SF.CA.US> romkey@asylum.SF.CA.US (John Romkey) writes: >From what I understand, ODI doesn't provide any logical (IP, for instance) to >physical (MAC) address translation. If it doesn't, then any protocol stacks >running above it still have to do this and know about the physical media they >reside on. In that case, ODI's only real difference is that it builds media >headers. Without the address translation, I don't think you can really claim >that it's media-independent, as some protocols like IP will still have to >provide media dependent code in them. The existence of ARP shows that IP itself isn't media-independent, so of course complete media-independence for an IP implementation is not possible. Other protocols, however, such as CLNP, XNS, and IPX, require no media specific address mapping because they pass media addresses around at the network layer. Here, ODI has an overwhelming advantage because these protocols can, in fact, be completely media-independent. In other words, IP's use of logical addresses is not typical. Even if it were, there's a significant difference between identification of the medium and knowledge of the medium. ARP itself is interesting for a few reasons: 1. Address mapping really *is* the only media specific information required. 2. Address mapping is a rare event, so the media specific code isn't invoked for each packet. 3. ARP is common across several media. IP with ARP really *is* basically media-independent for a wide range of media. (I'm assuming, of course, that ARP implementations tend to ignore ARP's hardware type field, and i can't imagine why they wouldn't.) Anyway, Keith's main point still stands: ODI and packet drivers are complementary solutions to different problems, not competing interfaces at odds with each other. don provan donp@novell.com
fks@vaxeline.ftp.com (Frances Selkirk) (03/08/91)
The NDIS specification is available by anonymous ftp to vax.ftp.com. Look in pub. On the same machine, in pub/packet.driver/pubdom/ndis, is our packet driver-ndis interface, for using applications written for packet driver over an ndis driver. -- Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) (03/08/91)
In article <1991Mar6.201431.18839@novell.com> donp@na.excelan.com (don provan) writes: >The existence of ARP shows that IP itself isn't media-independent, so >of course complete media-independence for an IP implementation is not >possible. Other protocols, however, such as CLNP, XNS, and IPX, ^^^^ >require no media specific address mapping because they pass media >addresses around at the network layer. Here, ODI has an overwhelming >advantage because these protocols can, in fact, be completely >media-independent. > >In other words, IP's use of logical addresses is not typical. I don't think it is true that CLNP passes media addresses around at the network layer. Or more specifically, if your CLNP implementation assumes that a useful MAC address is encoded in the NSAP I think you are going to be unhappy with it. GOSIP-format NSAPs do include a 6 byte System ID, but it is not a a requirement that this contain a MAC address. Hosts which autoconfigure their NSAPs may put a MAC address in there to guarantee the generation of a unique number (this is why the field is 6 bytes), but you can't assume that all hosts have done this. And even if you could, multihomed hosts (with more than one interface but perhaps just one NSAP) would still break the assumption that you can use the address for sending. ES-IS (which is sort of an ARP-replacement rolled in with a gateway discovery protocol) is used to do media-dependent address mapping for CLNP, in a way which is quite analogous to ARP and IP. I'm not really sure that the list of protocols which use logical addresses is limited to IP and CLNP, either (SNA seems to, though in a way which certainly has no analogy to IP). What is "typical" may depend a lot on the particular set of protocols you consider. Dennis Ferguson
leo@unipalm.uucp (E.J. Leoni-Smith) (03/14/91)
I was surprised that no one else came up with the 3COM product Netware for 3+ open or something like that. Its an IPX<=>NDIS converter. Works well (with 3com drivers, probs with WD) to allow you to run Netware over NDIS. You have to fudge the installation to make it appear that you have LanMan installed tho.... Unloadable IPX and NET3 too.. But VERY expensive in small doses. OK for large site licences. Don't mail me about it - we tested it and it it works. Talk to 3COM P.S. Last time I checked you couldn't run the FTP packet+NDIS with the BYU IPX=packet driver code. So that might not be the route out.
RBYAML@ROHVM1.BITNET (Aengus Lawlor) (03/21/91)
In article <1337@vaxeline.ftp.com>, fks@vaxeline.ftp.com (Frances Selkirk) says: >The NDIS specification is available by anonymous ftp to vax.ftp.com. >Look in pub. On the same machine, in pub/packet.driver/pubdom/ndis, is >our packet driver-ndis interface, for using applications written for >packet driver over an ndis driver. >-- >Frances Kirk Selkirk info@ftp.com (617) 246-0900 >FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880 I downloaded the files, but the docs are a bit sparse. Can anyone give me some pointers on what should be in my PROTOCOL.INI file? I have 3Com 3C503 cards (EtherLink II) and the docs refer me to Chapter 7 in the 3+Open LAN Manager Technical Reference for further info. I don't have LAN Manager, but anticipate getting Pathworks (PCSA V4.0) soon which works over NDIS. I would like to get my current setup working with NDIS (Packet driver for NCSA Telnet and BYU Novell), so that adding Pathworks will be simplified somewhat. While I'm at it, does anyone have any ideas about Windows 3.0 and NDIS, and whether W3 apps are going to be able to talk to NDIS, or will that require new drivers, or something like PKTINT that comes with QVTNET. (Does any of this make sense?) -- RBYAML@ROHMHAAS.COM Aengus Lawlor RBYAML@ROHVM1.BITNET (who used to be ALAWLOR@DIT.IE)
P85025@BARILVM.BITNET (Doron Shikmoni) (03/24/91)
In article <91079.125644RBYAML@ROHVM1.BITNET>, Aengus Lawlor <RBYAML@ROHVM1.BITNET> says: >I downloaded the files, but the docs are a bit sparse. Can anyone give me >some pointers on what should be in my PROTOCOL.INI file? I have 3Com 3C503 >cards (EtherLink II) and the docs refer me to Chapter 7 in the 3+Open LAN >Manager Technical Reference for further info. The following addition into PROTOCOL.INI works for me: ; ------------------ FTP Software Packet Driver Protocol -------------------- [PKTDRV] DriverName = PKTDRV bindings = WDMAC Intvec = 0x60 ; --------------------------- Where WDMAC is the name of the MAC level driver portion of your protocol.ini (for me it's the WD MAC level), and 0x60 in the INTVEC is the packet driver interrupt number. >I don't have LAN Manager, but anticipate getting Pathworks (PCSA V4.0) soon >which works over NDIS. I would like to get my current setup working with >NDIS (Packet driver for NCSA Telnet and BYU Novell), so that adding Pathworks >will be simplified somewhat. Now here's the problem. BYU Novell will not work with the NDIS_PKT driver (bug in one of the parties...), so the whole building collapses... (BTW, has anyone been doing anything about that, or at least took a look at the problems there?). Hope this helps Doron
tcs@mailer.jhuapl.edu (Carl Schelin) (03/27/91)
In article <91079.125644RBYAML@ROHVM1.BITNET>, RBYAML@ROHVM1.BITNET (Aengus Lawlor) says: >I downloaded the files, but the docs are a bit sparse. Can anyone give me >some pointers on what should be in my PROTOCOL.INI file? I have 3Com 3C503 >cards (EtherLink II) and the docs refer me to Chapter 7 in the 3+Open LAN >Manager Technical Reference for further info. > Here, try this for your Protocol.Ini file. It works for me. ---------- ;**************************** ;** Etherlink II (3c503) ** ;**************************** [ELNKII] drivername = elnkii$ interrupt = 3 default ioaddress = 0x310 default xmitbufs = 1 ?? transceiver = 1 only if you're using an external transceiver. ;************************ ;** PROTOCOLS ** ;************************ [PKTDRV] DRIVERNAME = PKTDRV BINDINGS = ELNKII points to [ELNKII] INTVEC = 0X60 ----- Remove the comments after each of the lines. Carl Schelin tcs@mailer.jhuapl.edu