Can anyone tell me what's causiing these delays
Greg Hines
working OK except I have a delay of about 1 min. before the SCO Box will
except another RSH command.
ie: Do one RSH command, it executes and finishes however I'm not able to
execute another command for about 1 min. The NT4 PC just sits there after
the command is executed and eventually executes after about 1 min.
The delay seems to be on the SCO PC. Any ideas why the delay??
Thanks in advance,
--
Greg
greg...@bigfoot.com.NOSPAM
Remove NOSPAM when replying
Darryl Krasman
>
> I'm executing commands on SCO OSR5 from a WinNT PC using RSH. Everything is
> working OK except I have a delay of about 1 min. before the SCO Box will
> except another RSH command.
>
> ie: Do one RSH command, it executes and finishes however I'm not able to
> execute another command for about 1 min. The NT4 PC just sits there after
> the command is executed and eventually executes after about 1 min.
>
> The delay seems to be on the SCO PC. Any ideas why the delay??
>
> Thanks in advance,
Since that is largely the same question that dozens of folks ask here a
week, I'll wager that the SCO box has it's name resolution messed up and
can't resolve your NT4 name/ip#.
--
Darryl
Ideal Computer Group Inc.
Greg Hines
I somehow do not think so. I would have expected any sort of name/ip
problem to be consistent and not when you only do an RSH command immediately
after another.
Also the problem exists when you use the IP address in the RSH command.
Any other ideas would be helpful.
--
Greg
greg...@bigfoot.com.NOSPAM
Remove NOSPAM when replying
"Darryl Krasman" <dar...@idealgroup.com> wrote in message
news:3AEE0F21...@idealgroup.com...
Brian K. White
"Greg Hines" <greg...@bigfoot.com.NOSPAM> wrote in message
news:9886846...@monster.nlc.net.au...
> Darryl,
>
> I somehow do not think so. I would have expected any sort of name/ip
> problem to be consistent and not when you only do an RSH command
immediately
> after another.
>
> Also the problem exists when you use the IP address in the RSH command.
>
> Any other ideas would be helpful.
well you are right that the delay he's talking about affects other things
(telnet, ftp, etc...) and that it would affect the first attempt and not
just the second. But on the subject of using an IP instead of hostname, that
does not get around the delay Darrel was referring to.
That delay happens any time you try to connect to the sco box, via any of
several protocols, if the sco box has anything at all in /etc/resolv.conf,
and if the IP/hostname you are trying to connect *from* is not resolvable by
the unix box, from the unix box. This means that if the unix box has any
nameservers defined in resolv.conf, and if the ip you are connecting from is
not known to those dns servers (such as all your local, non-routable IP's)
then you will get a delay when trying to connect unless the IP is listed in
/etc/hosts, even if the hostname used in /etc/hosts is bogus, so long as the
IP is listed. IE:
10.0.0.22 dummy22
10.0.0.23 dummy23
10.0.0.24 dummy24
Even though we've established a few reasons why this is probably not the
cause of your delay, it's easy to do, and harmless, and easy to undo (no
reboot, no restarting tcp/ip, effects are immediate) so it's worth trying if
only to find out another thing that it's *not*.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Greg Hines
Thanks for all your comments - it's appreciated. To answer some of your
questions.
/etc/resolv.conf does not even exist on this system and the *correct*
ip/hostname is in /etc/hosts, so there should not be any reason for
resolving delays - Right? Plus dns is not installed on any pc's on the
network, be they windows, sco or AT&T.
It's worth noting the /etc/hosts and $HOME/.rhosts on both the sco and the
AT&T boxes are the same and I don't get these delays on the AT&T box.
This may not sound like much of a problem but the application that runs on
the Windows PC can, put not always, need to RSH commands on the sco box 30
secs aparts. Hence the problem.
I would therefore like to resolve this issue so any further ideas would be
appreciated.
Thanks again,
--
Greg
greg...@bigfoot.com.NOSPAM
Remove NOSPAM when replying
"Brian K. White" <br...@aljex.com> wrote in message
news:PJqH6.105402$C55.9...@news1.rdc1.nj.home.com...
Bill Vermillion
Greg Hines <greg...@bigfoot.com.NOSPAM> wrote:
>Thanks for all your comments - it's appreciated. To answer some of your
>questions.
>/etc/resolv.conf does not even exist on this system and the *correct*
>ip/hostname is in /etc/hosts, so there should not be any reason for
>resolving delays - Right?
Wrong. It's the FAR system that has to verify via a reverse DNS
lookup. I've put my local machine IP's into the far machine to
eliminate this problem.
>It's worth noting the /etc/hosts and $HOME/.rhosts on both the sco
>and the AT&T boxes are the same and I don't get these delays on the
>AT&T box.
There are many different implementations of all these protocols.
It depends on how the system executes them also. Depending on how
the systems are set up - some will NOT let any access if the
authentication is not possible.
So it's really not the difference between SCO and AT&T. You can see
differences in the same OS and the same version, but the results
can be dependant upon the flags passed to the daemons from
the /etc/inetc.conf file, or the flags passed to the program upon
startup if exectued from a startup script.
I see this question more and more on virtually every usenet Unix
based group I visit - not just the SCO list.
>This may not sound like much of a problem but the application that
>runs on the Windows PC can, put not always, need to RSH commands on
>the sco box 30 secs aparts. Hence the problem.
Then put the IP/names of the PC in the /etc/hosts on the SCO
system.
>I would therefore like to resolve this issue so any further ideas
>would be appreciated.
--
Bill Vermillion - bv @ wjv . com
Roberto Zini
>
> Brian,
>
> Thanks for all your comments - it's appreciated. To answer some of your
> questions.
>
> /etc/resolv.conf does not even exist on this system and the *correct*
> ip/hostname is in /etc/hosts, so there should not be any reason for
> resolving delays - Right? Plus dns is not installed on any pc's on the
> network, be they windows, sco or AT&T.
>
> It's worth noting the /etc/hosts and $HOME/.rhosts on both the sco and the
> AT&T boxes are the same and I don't get these delays on the AT&T box.
>
> This may not sound like much of a problem but the application that runs on
> the Windows PC can, put not always, need to RSH commands on the sco box 30
> secs aparts. Hence the problem.
>
> I would therefore like to resolve this issue so any further ideas would be
> appreciated.
>
Howdy !
Sorry for jumping in but did you have a look at the output from the sshd
daemon itself ? As an example, you could set the following option in
the sshd_config file:
SyslogFacility LOCAL1
In /etc/syslog.conf you could put the following:
local1.* /usr/adm/sshdlog
Next, restart sshd, try to connect from remote and see if there
are useful messages in /usr/adm/sshdlog; I know for sure that
sshd tries to reverse-lookup the name of the connecting host
and, if that fails, it should print a line similar to the following
into the log file:
sshd[<number>]: reverse mapping checking getaddrinfo for <name> failed
POSSIBLE BREAKIN ATTEMPT!
I don't think this is the real cause of the problem but I do think
that a quick look at the log is worth trying.
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : r.z...@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Greg Hines
Thanks very much for all your efforts in trying to solve my problem. With
your help and a little more effort and creative thinking from my end I've
eventually worked out the problem.
It appears the problem only exists when using NT with SP6. The problem does
not happen with SP5 and I confirmed this by upgrading and NT/SP5 pc to SP6.
As soon as SP6 was installed the problem returned.
There appears to be something different in the implementation of the TCP/IP
protocol between SP5 and SP6 that *only* effects SCO. The problem, the
delay, did not happen between NT/SP6 and an AT&T machine. Also I had no
delay rsh'ing between AT&T and SCO.
Now that I know the cause it does not really help me as I cannot uninstall
SP6 from all my NT pc's and install SP5.
Microsoft has done it to me again !!
I also noticed the following strange behaviour and if anyone can make sense
of it I'll be real happy to hear from you: -
1. Boot the NT PC.
2. Open a command window and type
rsh <computername> -l <username> <command>
and the command will be executed immediately.
3. Repeat the same command immediately after the first command finishes and
you will get a delay before the command is executed.
4. Repeat the same command, but this time put in the -n argument to direct
the output to null.
rsh <computername> -l <username> -n <command>
and the command will execute immediately.
5. Repeat the command in (4) above, again with the -n argument, immediately
after the previous command completes. No delay! Why??
6. Repeat the original command in (2) above, no -n argument, immediately
after the previous command. No delay.
7. Try this command several times one after the other. No delay!
8. Log off, not shutdown, repeat from (2) above and the delay is back until
you issue a command with the -n argument. This *only* happens in NT4 with
SP6.
Got me stumped!!