Chip 1994 February/CHIP0294.ISO/digital/magazin/trumpet/pktdrvs/ipxpkt.not/text0000.txt

Text File | 1992-08-04 | 6.0 KB | 121 lines

FYI, if you want to use both Novell and the token ring packet
driver, you must first load the packet driver and then Novell's
IPX driver.  It seems that IPX tries to take over the card.

Steven Wallace

From [e-mail] Thu Apr 26 10:02:58 1990
Return-Path: <nelson>
Path: excelan!ames!uakari.primate.wisc.edu!samsung!uunet!mcsun!hp4nl!rulcvx!rulcs!s5!kranenbu
From: [e-mail] (Paul Kranenburg)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Problems with IPXPKT
Date: 18 Apr 90 10:40:04 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Dept. C. Sc., Leiden, NL
Lines: 98
Apparently-To: nelson

In article <[e-mail]> Novell LAN Interest Group <NOVELL@SUVM> writes:
>Howdy!
>
>I'm having problems getting the IPX packet driver  (fresh from Clarkson) to
>work across Novell bridges (which are really routers).  From the code it's
>apparent that this wasn't in the packet driver's design.  I would like to
>know if anyone has plans to incorporate code in the driver to do this, or
>if anyone knows how to get to more than one Novell subnet without allocating
>an IP router per network.
>
>Thanx in advance,
>Bill Brown
>University of Central Florida Computer Services
>[e-mail]

Support for routing through Novell bridges was considered for inclusion
in IPXPKT but not (yet) implemented because it got no top-priority on my
list of *things to do* (in fact, there is a procedure called `route', not
worthy of its name, which was meant to do the job. As things are now, it
merely copies the destination address into the immediate address field,
rendering only local net connectivity).

Here is a brief account on the history of the IPX packet driver:

With the prevous release of the Clarkson packet drivers came a tokenring-
driver (`ibmtoken') which I wanted to use to give access to users on our
token-ring PC-network to our network of workstations (mostly Suns) and
>from there to the backbone campus-ethernet, by means of NCSA Telnet and/or
Phil Karn's KA9Q TCP/IP program. After some twiddling I got this to work
using a PC-AT as router between the TR-cable and the local ethernet.
There were two drawbacks: firstly, TCP/IP and Novell could not be resident
on the same computer simultaneously, requiring a reboot when switching
applications and secondly, some Novell applications on other machines
(mostly those using overlays) liked to drop their server connections
when the `ibmtoken'-packet driver was active on the net. I am not a TR
or Novell guru (and I don't intend to become one), so I have until this
day no clue what caused this (though I think I noticed a correlation between
broadcasting by the TCP/IP programs (ARP) and the destructive Novell behaviour).

Proposals to experiment with IPX-drivers configured to use the packet driver
interface fell on deaf ears with the management responsible for the PC-network
as did my suggestion to switch to an all TCP/IP network. Thus, I changed tactics:
If you can't beat them, join them. So I set out to write some code to get IP
packets transported by IPX.

There were several things to ponder: Am I going to consider the
various segments of cable now comprising the PC-network as one IP-subnet
or should they be seperate subnets with IP-routers in between?
Should the interface be a (FTP) packet driver? If so, what type should
the packet driver be?

The unavailability of dedicated IP-routers (PC's running PCroute or KA9Q,
that is) at this site might well force a decision on the first question in
favour of a single IP-subnet. As for the second question: a packet driver
seems the easiest and most universal way to go. Remains the decision as to the
class and type of the packet driver. All TCP/IP implementations I have experi-
mented with (NCSA, KA9Q, PCroute) do understand Blue book Ethernet class.
Unfortunately, making them understand other, say IEEE 802.x, classes, not
only involves making changes to their packet driver interfaces, but also to
the handling and caching of ARP and RARP requests. While I might be able to
that for KA9Q (used as gateway for the moment), my understanding of the inter-
nals of NCSA (which is the preferred "user" program for remote logins) is too
minimal to guarantee anything useful in the near future.

For these reasons, I have decided (for the time being) to write a packet driver
that simulates an (Blue book) Ethernet interface. Furthermore, due to lack
of IP-fragmentation handling in NCSA Telnet, simulating full-size (1500) ether-
net packets was necessary. Admittedly, having an application prepare full-fledged
ethernet packets only to take them apart again to get them through an interface
which is only capable of handling 436 bytes packets is complete bollucks **).
Agreed, doing fragmentation and reassembly at the packet driver level
violates proper engineering standards. But at least I can get things to work
without modifying a bunch of TCP/IP code.

Given all this, I regard the current IPXPKT driver as a temporary measure to
overcome currently existing limitations. As soon as a version of NCSA with
IP-fragmentation handling comes out, the current version of the IPXPKT driver
can be tossed aside and thoughts can be given to make make the driver com-
pliant with RFC 1032 and also to establish a proper packet driver class and
type.

Please, feel free to give any comments on the matter.

In the mean time, here are some questions about IPX to which I'd like to know
the answers, to be able to build a routing table in the packet driver:

- how can one determine one's own IPX network number
- how can one determine IPX network numbers which are reachable through IPX bridges
- how can one broadcast on a given (non-local) subnet, or
- how can one broadcast on all attached subnets


Cheers,
-- Paul Kranenburg, Dept. C. Sc., Leiden University, NL.


**) I don't know how to spell this nor even the precise semantics, but I'm sure
you get the idea :-).