X-mailer:     Pegasus Mail v2.3 (R2).
Newsgroups: bit.listserv.novell
Date:         Fri, 31 Jul 1992 10:13:57 EST
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Stephen McCloud <CCSDM@CCLAN.INDSTATE.EDU>
Subject:      RE: Charon and smc card
X-To:         NOVELL@SUVM.SYR.EDU

ODIPKT.QA is Questions and Answers About ODIPKT. I'll let James
Harvey give the FTP address to the list.



                     Questions and Answers About ODIPKT


Q:  What is ODIPKT?

A:  ODIPKT provides a packet-driver API over Novell's Open Data-link
    Interface (ODI).  It is loaded after LSL.COM and whatever network-
    adapter-specific ODI MLID you are using.  It allows protocol
stacks
    that require ODI (e.g., the ODI implementation of Novell NetWare's
    IPX protocol stack) and protocol stacks that require a packet-
driver
    interface to share a single network adapter.  For example, it
allows
    Novell's IPXODI.COM to share an adapter with CUTCP TN3270 or NCSA
    Telnet.

    ODIPKT version 1.1 understands Ethernet, token-ring, and ARCnet
frame
    types.  Ethernet and Token Ring frames are passed unchanged to
    applications.  ARCnet frames are converted internally to Ethernet.
    Some practical considerations to note here are:

    o   Since frame conversion is *not* done for token-ring, packet-
driver
        applications will require specific knowledge of token-ring to
        operate in token-ring environments.  Please note that most
"freeware"
        packet-driver applications do not.  Thus, for example, you
cannot
        use ODIPKT to run CUTCP TN270 v2.2D over a token-ring
interface.

    o   Since conversion *is* done for ARCnet, packet-driver
applications
        do not need to have specific knowledge of ARCnet to use the
packet
        driver interface.


Q:  Why would I want to use ODI drivers and ODIPKT, when I can use a
    network-adapter-specific packet-driver, and one of the freeware
    WSGEN/SHGENed IPX drivers that use the packet-driver API (the BYU
or
    Intel PDIPX version) to accomplish the same thing?

A:  There are several reasons.  Basically it depends on how important
    Novell NetWare support is at your site.

    o   Novell has made it clear that ODI is their future direction
for
        sharing network adapters between protocol stacks.  IPX.OBJ and
        WSGEN/SHGENed drivers may no longer be supported at some time
in
        the future.

    o   If you are using an ODI driver, your IPX stack depends only on
        TSRs supplied by Novell (LSL.COM and IPXODI.COM) and the
adapter
        vendor (the adapter-specific ODI MLID).  The vendor will
usually
        provide support for their MLID, and Novell supports LSL and
IPXODI.

    o   In general, you will get better NetWare IPX throughput running
        IPXODI over an ODI driver than running PDIPX through a packet
        driver.  Of course, if you have to run TCP/IP through a
interface
        converter like ODIPKT, TCP/IP throughput will suffer compared
to
        running it through a packet driver that talks directly with
the
        hardware.  If you are most concerned about NetWare throughput,
        this tradeoff will tend to favor ODI since TCP/IP tends to
handle
        throughput inefficiencies well anyway.

    o   For a typical adapter (3C523), the ODI/ODIPKT combination
requires
        only about 3K more memory.

    Your experience may vary, especially if NetWare support is of only
    secondary importance for you.  Source code is available for all
of the
    Crynwr collection of packet drivers, and you can purchase support
for
    the Crynwr collection of packet drivers from Crynwr Software.
However,
    at the time of this writing support and source code for the
freeware
    IPX drivers that use packet drivers is not available.


Q:  How do I load ODIPKT?

A:  ODIPKT can be loaded anytime after the adapter-specific ODI MLID.
    For example, assuming you have a 3C523 adapter:

    LSL
    3C523
    ODIPKT 0 96
    IPXODI
    NETX

    In this case, your packet driver applications should use software
    interrupt hex 60 (which is 96 in decimal).

    For a 386 with extended memory, HIMEM.SYS and EMM386.SYS loaded,
and
    Microsoft Windows (use WINPKT to allow the packet-driver API to
work
    properly with Microsoft Windows):

    LOADHIGH LSL
    LOADHIGH 3C523
    LOADHIGH ODIPKT 0 97
    LOADHIGH WINPKT 0x60 0x61
    LOADHIGH IPXODI
    LOADHIGH NETX

    In this case, your packet driver applications should use software
    interrupt hex 60.  This allows WINPKT to make the packet driver
API
    work properly with Microsoft Windows.  Note that WINPKT is simply
a
    packet driver "application" that loads as a TSR (before Windows)
    and interfaces to the real packet driver API (ODIPKT) using
software
    interrupt hex 61 (which is 97 in decimal).  See "Questions and
Answers
    About WINPKT" for details.

    Depending on what other drivers and TSRs you are loading and what
    memory management software you are running, you may end up with
more
    free conventional memory by loading only IPXODI and NETX high (and
    perhaps LSL also if you are allocating additional buffer space for
    the network software).


Q:  What changes will I have to make to my NET.CFG file?

A:  Any frame and protocol types that ODIPKT will use must be entered
in
    NET.CFG.  A typical NET.CFG for IPXODI using Novell's "raw-802.3"
framing,
    and a TCP/IP stack using ODIPKT and Ethernet II (DIX) framing
would look
    like:

    Show Dots = On

    Link Driver 3C523
        Frame Ethernet_II
        Frame Ethernet_802.3
        Protocol IPX 0 Ethernet_802.3
        Protocol IP 800 Ethnernet_II
        Protocol ARP 806 Ethnernet_II
        Protocol RARP 8035 Ethnernet_II

    An ODI driver creates a "logical interface" for each frame type.
    In this example, Ethernet II is listed first, because when we
loaded
    ODIPKT we specified for it to used the first virtual interface
(the
    first argument is "0" in the command "ODIPKT 0 96").

    If your NetWare server is "ECONFIGed" (viz., it uses Ethernet II
framing
    instead of Novell's "raw-802.3" framing), then the NET.CFG file
should
    look like:

    Show Dots = On

    Link Driver 3C523
        Frame Ethernet_II
        Protocol IPX 8137 Ethernet_II
        Protocol IP 800 Ethnernet_II
        Protocol ARP 806 Ethnernet_II
        Protocol RARP 8035 Ethnernet_II


Q:  Are there any known incompatibilities between ODIPKT and other
DOS TSRs?

A:  If you are running the DOS version of AfterDark (AD-DOS.COM),
don't
    load it until after you load ODIPKT.


Q:  Where can I obtain ODIPKT?

A:  ODIPKT was written by Dan Lanciani at Harvard University.  It is
    available by anonymous ftp at hsdndev.harvard.edu (128.103.202.40)
    in the directory /pub/odipkt.


Author:       James A. Harvey
Last updated: June 29, 1992
Organization: Indiana University-Purdue University at Indianapolis
Department:   Office of Integrated Technologies, Technical Support
Services


(   Stephen McCloud                       ccsdm@cclan.indstate.edu   )
 )                                                                  (
(   Computing Services and Facilities                                )
 )  Indiana State University                           cclan/ccsdm  (
(   Terre Haute IN 47809                            (812) 237-3793   )
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU