HP3000-L Archives

July 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Fri, 11 Jul 1997 01:27:28 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
I'm going to break my own guidelines and post something off-topic since
it caused me a good 3 days of grief and a great deal of anxiety...

We have several class-C networks (actually more like 16) but recently
had a serious network problem... some older "retired" PS/2 systems which
were running basic packet driver/IPX/NETX stacks were being used as
print servers in an office and were unable to connect to their server on
another network.  Sounds like a router problem, and since we were
changing router topology, a likely reason.

Then some Windows 3.1 user stations, running similar stacks plus Trumpet
Winsock could not contact their server (netx ps=myserver) also on
another network.  If you removed the 'ps=myserver', they would connect
to some Windows 95 machine, not a Novell server.

The Win95 PC was running "File and Print Sharing for NetWare Networks"
service.  Should be OK, but such is not the case, as we found out after
days of chasing the problem down.

To make matters worse, Win95 clients on the same network could see the
entire network neighborhood, while the 3.1 clients on IPX/NETX could see
nothing except two Win95 machines (both using Novell file/print share).

The problem... NETX issues a "Get Nearest Server (GNS)" request to find
a server to attach to (if no PS= parameter) or to resolve the name to a
Novell network address (if PS= is specified).  Well, if you don't have a
real Novell server on that network, the Win95 machine will eventually
answer the GNS broadcast, but then is unable to do the name resolution.
Router forwarding doesn't work, since GNS requests aren't forwarded as
long as there is an IPX server on that segment (and the Win95 machines
look sufficiently like a Novell server).

The solution is to remove the Win95 sharing service, or in our case, add
a real Novell server (our problem was caused by a dual-interface server
having NIC problems on this segment, so it was unbound, leaving no real
server on that network).

This almost brings closure to the problem with one exception -- if you
have both Novell servers and Win95 sharing machines on the same network,
what prevents the Win95 server from answering the GNS query first?  Our
local cisco SE says probably nothing.  The tech support SE says that
Win95 likely has a delay built-in for GNS responses.  But I still do not
have a definitive answer.

Anyone out there have an authoritative answer to this admittedly
off-topic, cryptic question?  I'd feel much better knowing for sure.

Sorry for the non-3K bandwidth waste, but we have Joe and Denys and some
other Microsoft gurus aboard, so I'm taking my chances.

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2