X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.novell
Date:         Wed, 27 Jan 1993 12:54:54 -0600
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject: Re: ODI?

>
>>>FROM:  Paul Anderson  Paul@vax1.iupui.edu
>>>        1) Can the NExxxx cards handle both frame types?
>>>        2) Has any one been sucsessfull in runnig Ethernet_II and Ethernet_80
   2
> .
>>   3
>>>           on the SAME board at the SAME time?
>>>                I can run one or the other but not both.
>>>        3) Could some one please inform Novell that occasionally we really do
>>>           reley on there manuals and that they should include instructions
>>>           that really work?
>>>
>
>>From:         Joe Doupnik <JRD%USU.BITNET@SUVM.SYR.EDU>
>>        While we sympathize with your frustrations, this material is covered
>>by the manuals. Each frame kind activiated for a board produces a virtual
>>board, and is announced as such when starting the network components. Major
>>section   Protocol IPX   is needed if, and only if, there are conflicting
>>choices for frames, and you certainly have that situation. The major heading
>>by itself does precisely nothing; it serves as punctuation for the minor
>>heading (must be indented to qualify as "minor") details. See the BIND sub
>>heading.
>>        The manuals on NET.CFG can certainly be improved, and I have suggested
>>this. In the meanwhile some simple deductions are employed to discover how
>>it works. The "Major" and "minor" heading description is mine, based on how
>>programs expect to see NET.CFG. That is, a program, say IPX, reads NET.CFG
>>looking for major headings, and when the interesting one appears it then
>>reads the minor ones beneath for instructions.
>>        Stray stuff, such as PB buffers= , are major headings and thus must
>>be against the left margin. Never jumble major and minor material.
>>        For more insight on what frame and protocol minor headings do see
>>the MS-DOS Kermit v3.12 documentation files, particularly MSR312.UPD. Kermit
>>can use a major heading  Protocol Kermit  and Bind as a minor heading when
>>it works with ODI.
>>        For a really good time, unquote, try explaining NDIS Protocol.ini
>>to someone. Hint: see my guidance in the dis_pkt9.zip archive. Such fun.
>>        Good luck, and carry on regardless,
>>        Joe D.
>
>Joe,
>
>While Paul's question was not super clear (I work with him), your response
>does not seem to help clear the waters either.  As it would appear that you
>might have the knowledge to help us, I thought I'd give this another try.
>
>We have *NO* problem binding IPX to Ethernet 802.3 and IP to Ethernet
>II.  Have been doing so for over nine months.  And running TELNET/FTP to
>our hearts content.  Paul's lack of proper indentation in his mail message
>has nothing to do with our current problem.
>
>What we need to do, and are trying to do is to bind multiple protocols
>to the same frame.   Well, clearly we need to create two logical boards
>for that same frame type.  Now here's the rub,  we need IPX traffic for
>Novell over 802.3 and IPX traffic over Ethernet II for PathWorks.
>
>Let's talk documentation.  The Novell ODI Workstation documentation
>clearly states "In a DOS Environment, you can bind IPXODI.COM to only
>one network board".  This is from documentation copywrited in 1990.  It
>is hard to believe that there isn't more current material!
>
>The latest of our NET.CFG files follows.  Would you please point out how
>we can bind IPX to 802.3 and Ethernet II using one single NE1000 in the
>Workstation?
>
>NET.CFG follows:
>
>LINK SUPPORT
>        MAX BOARDS      4
>        MAX STACKS      9
>        MEMPOOL         4096
>        BUFFERS         8       1500
>
>Link driver NE1000
>        DMA     5
>        Int     5
>        Mem     D000
>        Port    340
>        Frame   Ethernet_802.3
>        Frame   Ethernet_II
>        Protocol IPX 0 Ethernet_802.3
>        Protocol TCPIP 800 Ethernet_II
>
>Protocol TCPIP
>        IP_ADDRESS 134.68.31.22
>        IP_ROUTER 134.68.31.103
>        IP_NETMASK 255.255.255.0
>        TCP_SOCKETS 8
>        UDP_SOCKETS 8
>        RAW_SOCKETS 1
>        NB_SESSIONS 4
>        NB_COMMANDS 8
>        NB_ADAPTER 0
>        NB_DOMAIN
>        BIND #2
>
>LINK DRIVER NE1000
>        DMA     5
>        INT     5
>        MEM     D000
>        PORT    340
>        Frame           Ethernet_II
>        PROTOCOL        IPX             8137    Ethernet_II
>        PROTOCOL        DRP             6003    Ethernet_II
>        PROTOCOL        NETBIOS         8040    Ethernet_II
>        PROTOCOL        LAST            8041    Ethernet_II
>        PROTOCOL        LAT             6004    Ethernet_II
>        PROTOCOL        MOP             6002    Ethernet_II
>        PROTOCOL        LOOPBACK        9000    Ethernet_II
>
>Protocol IPX
>        BIND #3
>
>Thank you for your help.
>
>        -Peter
>+------------------------------------------------------------------+
>| Peter W. Adams                          peter@falcon.iupui.edu   |
>| Regenstrief Institute for Health Care                            |
>| Indiana University Medical Center                                |
>| Indianapolis, Indiana   46202           voice: (317) 630-7669    |
>+------------------------------------------------------------------+
Peter and the group,
        Ok, I think I understand what you want a little better now,
specifically running IPX over two or more frame kinds. Let me try again.
        IPX, an application from ODI's perspective, finds the first board
offering support unless we direct it to a particular logical board with
a BIND clause. Once it is installed it can't be bound again to a second
logical board. It's sort of like the packet multiplexer problem turned
upside down: which channel would IPX use to send replies? Think of the
problems poor old NETX would have sending stuff down toward the wire.
        The way servers handle this as full routing feeding an internal
network. We lack such a concept in workstations so only one copy of IPX can
be running. Novell could do this, at a cost in memory and speed, but I doubt
they think it worth the expense.
        The obvious solution is to abandon Ethernet_802.3 and use Ethernet_II
for IPX work, but I'm sure you have given that plenty of consideration. Even
so it might be the lesser of evils.
        Binding multiple protocols, each different, to the same frame kind
on the same board is no problem, of course, as we do that all the time with
IPX + TCP/IP. But frame kind is say Ethernet_II and the distinguishing feature
is the protocol ident such as 0800 which the LSL needs to separate the traffic.
If two apps wanted the same frames, meaning the same kind and the same protocol
ident, then one will be rebuffed by ODI. This is a classical net.maddness
situation which has been discussed at length on TCP/IP items.
        The latest NET.CFG info is in both the NW/NFS docs (only $$$!) and
in the ODI specs (only mountains of Postscript technical material). I work
from everything at hand, plus my own code which does the same kind of job
as Novell's programs when reading NET.CFG. The rules keep changing as various
parts of the company add their special clauses; heck, I added mine too.
        Did I get it right this time?
        Joe D.
Newsgroups: bit.listserv.novell