home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / novell / 12037 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.0 KB
  1. Path: sparky!uunet!ukma!gatech!emory!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!harvey
  2. From: harvey@indyvax.iupui.edu
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: ODINSUP?
  5. Message-ID: <1993Jan28.152619.276@indyvax.iupui.edu>
  6. Date: 28 Jan 93 15:26:19 -0500
  7. References: <93028.155323P85025@BARILVM.BITNET>
  8. Organization: Indiana University-Purdue University at Indianapolis
  9. Lines: 56
  10.  
  11. In article <93028.155323P85025@BARILVM.BITNET>, Doron Shikmoni <P85025@BARILVM.BITNET> writes:
  12. > I am trying to activate ODINSUP and am having only - ahm - limited
  13. > luck.
  14. >
  15. > I am a former user of normal NDIS stack. What I did is to remove
  16. > the MAC driver for my (SMC) Ethernet NIC, and change the bindings
  17. > to it in PROTOCOL.INI to point at the ODI MLID name. I boot, then
  18. > load:
  19. >
  20. > LSL
  21. > SMC8000
  22. > ODINSUP
  23. > NETBIND
  24. >
  25. > All seems to be coming up fine. I even, just for the heck of it (and
  26. > to test things, of course..), left DIS_PKT in the NDIS stack. I ran
  27. > CUTCP on to of this tall pile - and it worked.
  28. >
  29. > That is the good news.
  30. >
  31. > The bad news is, that my "real" NDIS client, which is IBM's PC/3270
  32. > running on top of LAN Support Program V1.23, just won't play ball.
  33. > It does work (via DXME0MOD) with the older setup; it just won't connect
  34. > in the new setup. Says something about connection failure (COMM 686).
  35. >[rest deleted]
  36.  
  37. Protocol stacks that use an ODI driver typically register the packet types
  38. they want to see with the LSL.  For example, IPXODI will ask to see IPX
  39. packets.  A TCP/IP stack might want to see only IP, ARP, and RARP packets.
  40. Protocol stacks that do this are called "bound protocol stacks."
  41.  
  42. Most "shim" interfaces don't register for particular packet types.  There
  43. are two special ways to register a protocol stack with the LSL in ODI:
  44.  
  45. o   Prescan protocol stacks, or "show me ALL the packets and then pass
  46.     them on to anyone else who wants them."  This is handy for implementing
  47.     something like protocol analyzer application without disturbing the
  48.     other protocol stacks that are running on the machine.
  49.  
  50. o   Default protocol stacks, or "give me all the packets that nobody else
  51.     wants."  This is the ideal way to register a shim, because overhead in
  52.     the shim is avoided if the packet is one for a protocol that is already
  53.     being handled by a native ODI stack.
  54.  
  55. However, the LSL allows only one application or shim to register for each
  56. of these special types for a given logical board.  Thus if you are already
  57. running one shim (DIS_PKT), trying to load another (ODINSUP) will fail.
  58.  
  59. One way around the problem is to stack the shims.  For example, load a packet
  60. driver that talks directly to your interface, then PDETHER to provide ODI
  61. support, and then ODINSUP to provide NDIS support.  It's ugly, but it works.
  62. If it was my machine I'd try to eliminate the need for one or more shims
  63. by using software that talks directly to your favorite kind of driver.
  64. --
  65. James Harvey    IUPUI/OIT Technical Support/VMS & Networks
  66. harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
  67.