From owner-freebsd-hackers Fri Jan 26 10:42:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16999 for hackers-outgoing; Fri, 26 Jan 1996 10:42:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA16992 for ; Fri, 26 Jan 1996 10:42:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA04952; Fri, 26 Jan 1996 11:38:53 -0700 From: Terry Lambert Message-Id: <199601261838.LAA04952@phaeton.artisoft.com> Subject: Re: NetBUI and/or IPX routing? To: jhay@mikom.csir.co.za (John Hay) Date: Fri, 26 Jan 1996 11:38:53 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, swaits@pr.erau.edu, hackers@FreeBSD.org In-Reply-To: <199601260849.KAA28170@zibbi.mikom.csir.co.za> from "John Hay" at Jan 26, 96 10:49:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > IPXrouted will answer SAP and RIP requests, so you won't have problems if > you have a server on one net and hosts (IPX) on the other. The handling of > SAP and RIP requests is described in the "IPX Router Specification" that is > available from Novell. One SAP broadcast is made every 55 seconds for each service a server has available. It is possible to rebroadcast SAP packets without problems, up to a hop count of 16. The GetNearestServer request is a broadcast NCP. It is used by client machines starting up to locate a server on the local wire. For a proxy response, this would be the machine in the local bindery (SAP broadcast information is stored as tempory bindery objects in the local server's bindery -- under 4.x, this is done with bindery emulation as a local to each server NDS object). When a server responds to a GetNearestServer, the client receiving the response attaches to that server's "login" directory. The danger here is that a simple brouter does not export file system services and therefore will not have a login directory. This is the problem with the "Puzzle systems" code, since it is a full server, but since it is an unlicensed implementation, it does not have nlist/slist/login to be used by a client, unless you copy the programs from a genuine Novell server somewhere else at your site (in tacit violation of the license). The problem in the case of a proxy response is that your "router" must rebroadcast the "GetNearestServer" NCP, *or* it must be capable of making a proxy response the the NCP broadcast in such a way as the AttachServer used by the client will attach to the server being proxied rather than the machine doing the proxy response. This is complicated by the fact that I can request service ID's (for instance, I could request "Novell Virtual Terminal" or NVT servers respond, rather than file servers). It is difficult and dangerous to respond to the GetNearestServer NCP broadcast as a proxy ("dangerous" as in "unlikely to work without screwing something up later on"). The biggest problem is with "remote reset" (remote boot), since such a situation rarely has a "preferred server" designated -- it will always want the nearest server. The "Preferred server" facility operates by attaching the server that responded to the GetNearestServer, opening the bindery, and iterating the servers until the preferred server is found, then attaching that server instead. I don't know if proxy response works or not; given its complexity, I doubt it -- and it is not a simple matter of bit-twiddling to make it work if it does not. I'll be happy (and amazed) to be corrected by anyone who has it working for clients on the other side of a FreeBSD or Linux box. I suspect that this would be dramatically more difficult in a 4.x network with 3.x compatability turned off, since such a setup has no SAP broadcasts to speak of. Instead, the services are inserted into the NDS tree and accessed from there. Propagation is by way of tree skulking, and even starting with X.500, I doubt an NDS pull-model tree could be implemented by a third party for you to be able to proxy such a response. I know two people who don't work for Novell who could maybe do it; one works at Caldera, and one works maybe 20 feet from me here at Artisoft -- both are ex Novell and both worked on Novell's NDS source code while there). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.