Date: Fri, 26 Jan 1996 21:48:04 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: terry@lambert.org (Terry Lambert) Cc: hackers@FreeBSD.ORG (FreeBSD-hackers) Subject: Re: NetBUI and/or IPX routing? Message-ID: <199601261948.VAA02595@zibbi.mikom.csir.co.za> In-Reply-To: <199601261838.LAA04952@phaeton.artisoft.com> from "Terry Lambert" at Jan 26, 96 11:38:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
I think you are a bit sidetracked. The original question was if it is
possible to have a Netware server on one side of a router and only IPX
clients on the other side. (No Netware server on that side)
------------ ----------- ----------
| Netware | Net A | FreeBSD | Net B | IPX |
| |-----------| |---------| |
| Server | | Router | | Client |
------------ ----------- ----------
This is possible with Netware 3.11 and DOS and Windose clients. We are
using it here. I don't have a Netware 4.xx server so I don't know if that
will work.
What happens is that the FBSD router will gather the IPX RIP and SAP
information that is broadcast by the server (and others if there are more
than one). When you start a IPX client it will do a SAP GetNearestServer
request (broadcast) which the router will answer. This packet contains the
name and address of the Netware Server. The client will then do a RIP
request to find a router that will route packets to the server address that
it just received. The router will answer it because it will see that it
is the cheapest (only) route to the server. Only then the client will send
a NCP connection request to allocate a connection slot. This is send to
the server. So the router does not have to answer any NCP requests.
John
--
John Hay -- John.Hay@csir.co.za
>
> > 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?199601261948.VAA02595>