From ssw@cica.indiana.edu Mon Apr 9 11:15:51 1990 Return-Path: <@clutx.clarkson.edu:ssw@cica.indiana.edu> Date: Mon, 9 Apr 90 09:39:22 EST From: Steve Wallace To: nelson@clutx.clarkson.edu Subject: Re: Telnet & Novell over token ring (a success story) Newsgroups: comp.protocols.tcp-ip.ibmpc References: <784@cica.cica.indiana.edu> 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 kranenbu@s5.cs.rul.nl Thu Apr 26 10:02:58 1990 Return-Path: Path: excelan!ames!uakari.primate.wisc.edu!samsung!uunet!mcsun!hp4nl!rulcvx!rulcs!s5!kranenbu From: kranenbu@s5.cs.rul.nl (Paul Kranenburg) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: Problems with IPXPKT Date: 18 Apr 90 10:40:04 GMT References: <90107.100958BROWN@UCF1VM.BITNET> Sender: news@rulcs.cs.rul.nl Organization: Dept. C. Sc., Leiden, NL Lines: 98 Apparently-To: nelson In article <90107.100958BROWN@UCF1VM.BITNET> Novell LAN Interest Group 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 >BROWN@UCF1VM.BITNET 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 :-). From nelson@sun.soe.clarkson.edu Fri Jul 20 13:28:45 1990 Received: from omnigate.clarkson.edu by pear.ecs.clarkson.edu with SMTP id AA2804 ; Fri, 20 Jul 90 13:28:39 GMT Received: from sun.soe.clarkson.edu by omnigate.clarkson.edu id aa00623; 20 Jul 90 11:46 EDT Received: by sun.soe.clarkson.edu (4.1/SMI-4.0) id AA20911; Fri, 20 Jul 90 09:30:55 EDT Message-Id: <9007201330.AA20911@sun.soe.clarkson.edu> Return-Path: From: Paul Kranenburg Date: Fri, 20 Jul 90 12:12:35 +0200 To: nelson@sun.soe.clarkson.edu Subject: ipxpkt packet driver. Here is the latest version of the IPXPKT packet driver. Major changes since the 6.0 release: - routing support to use Novell bridges (netwide broadcasting and hacks to find out about IPX net addresses). - support for IPX node address with less than 6 significant bytes. (through the `-n ' command line option). - auxiliary program (ipxstat.c) to display route table information and a couple of other statistics (define STAT when compiling the driver to use this option) About 100 people have retrieved various versions from the archive server at our site. Reports have not been overwhelming, so I assume that either the thing is totally useless or else works without to much fuss. Assuming the latter, I think the current version can be included in the next release of the packet driver collection. I will be changing jobs shortly and won't have access to PC's running Novell. So, while I can still pay attention to any comments that may arise, I won't be able to actually test any code changes. Thus, consider this as my last contribution to the IPX driver. Cheers, Paul Kranenburg, Dept. C. Sc., Leiden, NL. PS. The source code will continue to available from `archive-server@cs.leidenuniv.nl'. The version of ipxpkt is now set to 2.