On Wed, Dec 31, 2003 at 10:08:03AM -0500, John Von Essen wrote: > I can do two rsh's back to back with no problems, its the third (and 4th > and so on) that hang. > > On the FreeBSD side, after the first rsh, netstat shows: > > tcp4 0 0 mx100.851 embryo.bluebell..1021 > TIME_WAIT > tcp4 0 0 mx100.shell embryo.bluebell..1022 > TIME_WAIT > > Those connections stay around for awhile, about 30 seconds. Only when they > disappear does the next rsh work.
OK. Some progress. This rules out problems due to limitations in the
number of possible connections you can have open at any one time -- if
the limit is just two, then there would be a lot more things
complaining than just rcp(1). And you'ld have to try exceedingly hard
to get a FBSD system that limited.
Hmmm... What flags are you invoking inetd(8) with on the FreeBSD
side? Specifically are you using any of these (quoting from the
manual page):
-c maximum
Specify the default maximum number of simultaneous invocations of
each service; the default is unlimited. May be overridden on a
per-service basis with the "max-child" parameter.
-C rate
Specify the default maximum number of times a service can be
invoked from a single IP address in one minute; the default is
unlimited. May be overridden on a per-service basis with the
"max-connections-per-ip-per-minute" parameter.
-R rate
Specify the maximum number of times a service can be invoked in
one minute; the default is 256. A rate of 0 allows an unlimited
number of invocations.
-s maximum
Specify the default maximum number of simultaneous invocations of
each service from a single IP address; the default is unlimited.
May be overridden on a per-service basis with the "max-child-per-
ip" parameter.
The symptoms you describe could be caused eg. by running with '-s 2'
in the inetd flags (you're getting two socket connections per rsh or
rcp invocation because a second channel is opened to carry the stderr
from the invoked command, but that doesn't count towards inetd's
connection limits).
The default for all of these is unlimited (ie. inetd_flags="-wW") and
there aren't any per-service limits on the rsh (shell) service in the
default inetd.conf. I generally use:
inetd_flags="-wWl -R 1024 -c 128 -a ${hostname}"
in my /etc/rc.conf on internet facing machines where I run inetd(8) --
if this is a purely internal machine (which it certainly should be if
you're using rsh(1) on it) then I wouldn't bother with any sort of
connection rate-limiting, at least for the time being.
Hmmm... As well -- what's the output of:
% sysctl net.inet.tcp.delayed_ack
You might try setting that to zero to turn off delayed ack. That's
where the system will wait for about a minute before sending an ACK in
order to try and coalesce it with a data packet. Usually that's a win
performance-wise. See tcp(4). There's also the RFC1644 support you
might want to try toggling: see ttcp(4) -- I'm unable to find any
definitive statement on the net about Solaris support for this, so no
idea if it will actually help or not.
> As for the rcp, I was missing a trailing slash, apparently rcp -r syntax
> between Solaris and FreeBSD is a little different. So the rcp's work, but
> that take just as long as the rsh calls.
That's one problem down then. Good.
> As for name resolution, the Solaris box uses dns, and so does FreeBSD.
> Both have some entries in the hosts file.
That's good too. Rules out some more areas which could be causing the
trouble.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
pgp00000.pgp
Description: PGP signature
