Re: rsh and rcp problems between Solaris and FreeBSD

From: Matthew Seaman (m.seaman_at_infracaninophile.co.uk)
Date: 12/31/03

  • Next message: stan: "Re: hard drive test" 
    Date: Wed, 31 Dec 2003 16:22:14 +0000
To: John Von Essen <essenz@bjork.quonix.net>

    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

  • Next message: stan: "Re: hard drive test"

    Relevant Pages