Date: Fri, 26 Jan 1996 11:38:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jhay@mikom.csir.co.za (John Hay) Cc: terry@lambert.org, imb@scgt.oz.au, swaits@pr.erau.edu, hackers@FreeBSD.org Subject: Re: NetBUI and/or IPX routing? Message-ID: <199601261838.LAA04952@phaeton.artisoft.com> In-Reply-To: <199601260849.KAA28170@zibbi.mikom.csir.co.za> from "John Hay" at Jan 26, 96 10:49:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601261838.LAA04952>