Date: Fri, 11 Aug 95 14:32:23 MDT From: terry@cs.weber.edu (Terry Lambert) To: paul@freebsd.org Cc: questions@freebsd.org Subject: Re: Netware gateway. Message-ID: <9508112032.AA08265@cs.weber.edu> In-Reply-To: <199508111424.PAA18121@server.netcraft.co.uk> from "Paul Richards" at Aug 11, 95 03:24:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, here's a problem I've been mulling over for quite a while and
> I'm not getting anywhere with it.
>
> I need to connect a Novell Netware network to the internet through
> a single dial-up account (Demon in the UK). I evaluated a product
> called Novix, which you load as an NLM onto the Netware server. I don't
> know the details of how it does it but I think basically it
> tunnels tcp/ip connections across spx/ipx so that you can run
> winsock clients on you windows boxes and they talk to the Novix NLM
> on the Netware server and then Novix talks SLIP across the modem to
> the ISP. The big advantage of all this is that only the Novix
> server needs an ip address, the windows clients don't so the single ip
> address allocated to the dial-up box is all that's needed.
This is called "tunneling". Here is the equivalent process on a
UNIX box not using an NLM on the Novell side:
,----------------. ,-------------. ,----------------.
| NetWare client | | UNIX system | | NetWare server |
`----------------' `-------------' `----------------'
| | ^
NCP over NDIS/ODI process |
| | NCP over IPX
V v |
,------------------. ,-------------------. ,----------------.
| Tunneling driver | | Tunneling process | | Server IPX/ODI |
`------------------' `-------------------' `----------------'
| ^ | ^
| | IPX |
| TCP/IP | |
v | `---------------'
,-----------------. ,-------------.
| SLIP/PPP attach | | SLIP server |
`-----------------' `-------------'
| ^
| |
| |
v |
,-------------. ,-------------.
| Async modem |----->| Async modem |
`-------------' `-------------'
> Anyway, Novix's asynchronous NLM sucks big time and is totally
> incapable of keeping a dial-up connection alive and even if it does
> it can get into a real mess and drop packets everywhere. Since FreeBSD
> is known to work well in dial-up scenarious it would be great if I
> could use a FreeBSD box to talk to the ISP and have Novix talk across
> the LAN to the FreeBSD box. So, Novix is the SPX/IPX gateway to the
> tcp/ip LAN and FreeBSD is the gateway to the internet.
Unfortunately, I don't know what negotiation the client piece (the
tunneling driver in the picture above) does in terms of negotiating
the connection for NOVIX. Probably it negotiates the connection end
to end via the SLIP connection on the dialup box, which means that
there is probably some protocol encapsulation control messages which
you wouldn't be able to handle on its behalf.
Most likely, the request/response nature of NCP and the NOVIX code not
identifying itself as a router (thereby dropping the IPX MTU to 512)
is probably what is screwing you on performance.
That, and most high speed modems don't do line turnaround very quickly;
without a sliding window, you will need to turn the connection around
on a per packet basis. The real bandwidth available on a so-called
"high speed modem" is generally much smaller than you'd expect based
on the advertised rates it supports, or even normal TCP/SLIP connection,
which are sliding window in nature.
There are other tricks that you could do with the request packets to
make sure that you didn't generate excess line traffic during the latency
interval (in general, you'll need to do this because of the expotential
back off and the retry frequency causing multiple duplicate IPX requests
and responses). The packet drops I don't understand unless you are
(incorrectly) counting the retransmits on the client and server side
as if they were dropped packets.
I would recommend against an NLM in any case, unless it were very, very
carefully engineered, since the non-preemptive tasking model on the
server implies a serious server slowdown on a long delay link if
they keep the processor until the encapsulation ACK has occurred.
Probably there is even a better design available, but it would assume
an external router with an internal net number (ie: a NetWare 3.11 type
routing environment). Each incoming connection to the "local" IPX
net would seem like a locally attached external net to the internal
router and the external "cards". In effect, each incoming SLIP
connection would be treated either as if it were on its own external
net by itself, or as if it were on the internal net.
The effect here would be that you would then be required to maintain
SAP traffic for the gateway system to proxy-answer (forward/bridge)
SAP requests. This could either be done through a special case
protocol architecture violation on the SLIP serving box (GetNearestServer
is not supposed to be bridged) or by the router lying and identifying
a bridged server as the nearest server in its response. This second
is more painful, since it requires the router/bridge to have NCP internal
knowledge (not a good thing).
> There's a problem. I need to use fake ip addresses on the
> internal side of the FreeBSD box since there's only a single valid ip
> address allocated. I've thought about using socks on the FreeBSD box so that
> the fake internal ip addresses are never seen. Basically, I'm not sure this
> will work with Novix and I'm touting for experiences of solving this
> setup in general, i.e. connecting Netware networks to the internet across
> a dial-up connection where you've only had a single ip address allocated.
I don't really understand this is a requirement.
> Using FreeBSD would be nice, but spending bucks on a packaged
> solution would do me fine at this point but I'd really like to hear
> from people with known working solutions since I was told Novix was a
> really good "solution" but that didn't turn out to be the case.
The Novell "soloution" in this case is LANWorkplace NCP over IP. In
reality, this is, once again, protocol encapsulated IPX packets; there
is no true NCP-over-IP implementation. The deencapsulation is hidden
on the server side.
In this case, you use the SLIP capability of the LANWorkplace product to
get onto a TCP/IP net with a NetWare server running NetWare TCP/IP and
straddling the local (IPX) net and the non-local (TCP/IP) net. You
bind the TCP/IP stack to the card attached to the TCP/IP net and running
the SLIP server. What the SLIP server is is really irrelevant, as long
as the LANWorkplace can get into it: it could be a BSD box or a
Livingston Portmaster, etc.
This is a bit of an expensive soloution, both on the TCP/IP for the
server and for the LANWorkplace on a per client basis. It's really
up in the air whether this would be more expensive than using the BSD
IPX stack and writing your own software for the client (overall about
two weeks work on the client, assuming a full Level 2 MSDN membership
so that you'll have the MS DDK and the sample NDIS driver code.
I don't know if the all Novell arrangement would eliminate the excess
and duplicate traffic or not; I think that to do it you'd have to be
sneaky and clever at the same time. The soloution is rather non-obvious
and rests solely on the client side of things, and I don't know if they
were as sneaky as I would have been. It too relies on some knowledge
of NCP to work.
Regards,
Terry Lambert
terry@cs.weber.edu
---
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?9508112032.AA08265>