SEO

Thought I'd pick the brains of those on a higher level than I

I'm not SCO savvy by any means, barely know some basic Unix. Here's what it
boils down to:

Certain IP addresses affixed to Windows boxes take forever to find the login
prompt when telnetting to the SCO box. (forever= 1 minute+ vs. a couple
seconds)
All Windows boxes have IPs assigned. The SCO box is not running DHCP afaik
(I also looked in what I thought was the correct area-it showed IP addresses
but not assigned-either way its scope encompasses the working AND the
problem IPs), nor is DNS.

The \etc\hosts file on the SCO box contained entries of machines/IPs no
longer being used. Not sure why a server's hosts file would have the need
for client machine common names, but that's beside the point here I believe,
since the IPs listed also did not correspond to the fast nor slow machines
in this equation.

Initially the customer suspected the XP machines to be at fault, but as it
turns out he was assigning IPs to these machines above the range that all
others could possibly be using to avoid conflicts. By reassigning an XP box
to a "working" (connects instantly via telnet) IP addy, it shows no delay.
So I am ruling out the OS to be at fault.

Facts:
It is merely the connection to acquire the login prompt that takes
time--working within telnet is NOT an issue.
All clients eventually do connect, they just take "too long".
All clients are on the same subnet/mask as SCO server.
Tracert shows only 1 hop to server on both slow (telnet connection) and
normal machines.
Client machine/OS is irrelevant-I can change IPs on any Windows box to
reproduce the problem-hopefully ruling out cables/connections. (all new
wiring and switch-yes the fast, slow, and SCO machine all run through the
switch)

Questions:
Where else do I look on the SCO box to see defined addresses of clients-for
any purpose?
Would I be better off running DHCP on the SCO box (and changing clients to
autoconfigure) to clear this up? (a bit of overkill for less than 20 IPs
needed)
Silly question, but would DHCP use up that much CPU/resources to affect a
whopping 15 (if even) users connected to it accessing an old SBT warehouse
management application?
Hmmm...just thought of this as I sat here rereading this post. With regards
to licensing, how crazy would it be for the licenses to be tied to IP
addresses and when a request comes in out of range, it takes the server
longer to determine a license is available and hence eventually lets it in?
Okay, just had to ask :P

I think that's all of it. Sorry, I do not know the version of SCO they run.

Any tips on where to look, what other tools/commands to run to help isolate
my problem would be appreciated.

Thank you,

Dave B

Dave wrote:

> Certain IP addresses affixed to Windows boxes take forever to find the login
> prompt when telnetting to the SCO box. (forever= 1 minute+ vs. a couple
> seconds)

<snip>

> Facts:
> It is merely the connection to acquire the login prompt that takes
> time--working within telnet is NOT an issue.
> All clients eventually do connect, they just take "too long".

Classic name-resolution timeout delay. Server is looking up names of
client IP-addresses (for its logs etc) and getting no answer. I'd check
how name-resolution is configured on the SCO box. man resolver. I'd add
dummy entries for DHCP scope to hosts or DNS.
"192.168.1.101 dhcp-pc-001" etc

<more snippage>

> Any tips on where to look, what other tools/commands to run to help isolate
> my problem would be appreciated.

If I felt it necessary to confirm this diagnosis I'd look at the network
traffic. E.g. using Ethereal on the WinXP box via a non-switched hub to
see what DNS Qs are emitted by the Unix box.

--
Ian Wilson.

Hey Ian,

Thanks for the insight. I half understood what you said, and felt I was in
the right area, but I did a search on the "man resolver" you mentioned,
which points to the resolv.conf file I have seen referenced in my other
searches. I do appreciate your answer, and would like to expand it with a
link which I feel would help others who may seek this same answer.

http://www.tek-tips.com/gfaqs.cfm/pid/58/fid/1426

I am not able to implement your suggestion just yet, hopefully tomorrow. I'm
sure it will be the cure. I had already read of the "reverse-DNS" action
performed by the server, guess I didn't follow it's implementation enough to
consider it as high of a culprit since the file I saw appeared to be
referencing machines no on the network. But I understand better now.

Thanks again...we'll see how it goes.


"Ian Wilson" <scobloke2@infotop.co.uk> wrote in message
news:blc4vi$k2d$1@hercules.btinternet.com...
> Dave wrote:
>
> > Certain IP addresses affixed to Windows boxes take forever to find the
login
> > prompt when telnetting to the SCO box. (forever= 1 minute+ vs. a couple
> > seconds)
>
> <snip>
>
> > Facts:
> > It is merely the connection to acquire the login prompt that takes
> > time--working within telnet is NOT an issue.
> > All clients eventually do connect, they just take "too long".
>
> Classic name-resolution timeout delay. Server is looking up names of
> client IP-addresses (for its logs etc) and getting no answer. I'd check
> how name-resolution is configured on the SCO box. man resolver. I'd add
> dummy entries for DHCP scope to hosts or DNS.
> "192.168.1.101 dhcp-pc-001" etc
>
> <more snippage>
>
> > Any tips on where to look, what other tools/commands to run to help
isolate
> > my problem would be appreciated.
>
> If I felt it necessary to confirm this diagnosis I'd look at the network
> traffic. E.g. using Ethereal on the WinXP box via a non-switched hub to
> see what DNS Qs are emitted by the Unix box.
>
> --
> Ian Wilson.
>