🚀 go-pugleaf

In article <93028.155323P85025@BARILVM.BITNET>, Doron Shikmoni <P85025@BARILVM.BITNET> writes:
> I am trying to activate ODINSUP and am having only - ahm - limited
> luck.
>
> I am a former user of normal NDIS stack. What I did is to remove
> the MAC driver for my (SMC) Ethernet NIC, and change the bindings
> to it in PROTOCOL.INI to point at the ODI MLID name. I boot, then
> load:
>
> LSL
> SMC8000
> ODINSUP
> NETBIND
>
> All seems to be coming up fine. I even, just for the heck of it (and
> to test things, of course..), left DIS_PKT in the NDIS stack. I ran
> CUTCP on to of this tall pile - and it worked.
>
> That is the good news.
>
> The bad news is, that my "real" NDIS client, which is IBM's PC/3270
> running on top of LAN Support Program V1.23, just won't play ball.
> It does work (via DXME0MOD) with the older setup; it just won't connect
> in the new setup. Says something about connection failure (COMM 686).
>[rest deleted]

Protocol stacks that use an ODI driver typically register the packet types
they want to see with the LSL.  For example, IPXODI will ask to see IPX
packets.  A TCP/IP stack might want to see only IP, ARP, and RARP packets.
Protocol stacks that do this are called "bound protocol stacks."

Most "shim" interfaces don't register for particular packet types.  There
are two special ways to register a protocol stack with the LSL in ODI:

o   Prescan protocol stacks, or "show me ALL the packets and then pass
    them on to anyone else who wants them."  This is handy for implementing
    something like protocol analyzer application without disturbing the
    other protocol stacks that are running on the machine.

o   Default protocol stacks, or "give me all the packets that nobody else
    wants."  This is the ideal way to register a shim, because overhead in
    the shim is avoided if the packet is one for a protocol that is already
    being handled by a native ODI stack.

However, the LSL allows only one application or shim to register for each
of these special types for a given logical board.  Thus if you are already
running one shim (DIS_PKT), trying to load another (ODINSUP) will fail.

One way around the problem is to stack the shims.  For example, load a packet
driver that talks directly to your interface, then PDETHER to provide ODI
support, and then ODINSUP to provide NDIS support.  It's ugly, but it works.
If it was my machine I'd try to eliminate the need for one or more shims
by using software that talks directly to your favorite kind of driver.
--
James Harvey    IUPUI/OIT Technical Support/VMS & Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax