Conference helix::vaxeln

    Is rsh using UDP?  If the answer is yes, then a reason for failure may
    be because you do not have an ARP entry for the remote system in the
    VAXELN arp cache.  When a UDP or TCP message is sent, VAXELN IP looks
    to see if there is an ARP entry in the ARP cache for the remote system.
    If there isn't, the UDP or TCP message is discarded and an ARP exchange
    attempt occurs.  TCP will recover from this because TCP re-transmits
    messages that haven't been acknowleged within a specific period of
    time.  However, UDP does not guarantee that data is received by the
    remote system; so no re-transmission occurs.  The VAXELN application could
    create a permanent ARP entry for the remote system.  There other solutions.
    
    If rsh is using TCP, then I can't explain why rsh is not working as
    expected.
    
    Regards,
    -Steve-

Hey Steve,

Joe gave the CSC a call on this one too.  Found that his customer got
this application from Fisher-Rosemount.  Back in 1993, FRSI contacted us
about emulating rsh client services on ELN since we don't provide ready-made
services for this like we do for ftp-client.  From my notes, they were using
TCP (create socket, connect to remote socket, send, close).  But they may
have changed their algorithm since then to use UDP.  If so, you've got a good
point on the arp issue, as you frequently do :-)

Someone from FRSI will onsite with Joe tomorrow.  I've told him to have
an ether sniffer handy.  


Alan

Hi Steve, 

Joe and I have reviewed the lan traces in the situation where FRSI's rsh 
emulation on VAXELN works and when it doesn't.  FRSI's rsh emulation 
works when doing an rsh command to a Digital UNIX box, to an HPux box,
and to a PC with a TCP stack.  The failure case is to a specific OpenVMS Alpha
box running UCX  V4.1.  (They have other sites with no failures to an
OpenVMS box with UCX.)  In a nutshell, the VAXELN side is sending a
TCP reset packet after the rsh data has completed.  It sounds like this
could be a normal sequence of events as a result of the ELN side doing
a socket shutdown.  

My question is, what abnormal circumstances could result in the VAXELN
side issuing a TCP reset?  These are ones I have from some notes:

- reached maximum outstanding queued returns (for TCP input)
- socket closure (normal)
- connection refused
- no buffer space available (i.e., need to increase system pool)
- connection reset by peer
- if SYN is set when segment exceeds window

Are there others?  I am sending to Joe my latest inet_utils2 which includes
the additional TCP V2 stats which should tell him the last CCB exit reason.
It's possible the UCX side isn't handling something properly.

Thanks for your time!

Alan

Hi Alan,

	I don't have the time at the moment to go thru TCP to determine
exactly under what cases a RESET will be sent to a remote peer.  If you feel
that it is neccessary after reading this mail to understand all of the reasons
why a RESET can be sent, I'll look thru the code.

	It sounds to me like VAXELNs TCP is working ok.  What it sounds like 
is that UCX is not delivering data received before the RESET to the
application.  For the sites which do work with UCX, are the sites using a
later version of UCX? If the answer is yes, how about having the site upgrade
the version of UCX. 

	If the data that you expect to have delivered to the remote VMS system 
has been sent AND acknowleged (by the VMS side) then even if VAXELN sends a
RESET, I would expect that VMS would deliver and process the data before 
processing the RESET.  I don't think there is a VAXELN problem here given your
description of what you found with message tracing.

Regards,
-Steve-

    This problem is also being discussed in LASSIE::UCX note 4950.  
    I have caught traces of rsh from Digital Unix and VMS systems to an
    Alpha running UCX. In those cases, the intiator of the rsh waits until
    the target has returned a FIN before terminating the connection with
    another FIN.  Is a RESET an acceptable way of terminating a connection?
    
    

    re: .-1 Should RESET be used.
    
    	A good question, but I'm not sure that it should make a difference.
    I still think that the application should be able to process the data
    which was transmitted and acknowleged before the RESET was sent.
    
    	I would not be suprised to find that the RSH worked if a FIN was sent
    to terminate the connection instead of a RESET.  It would be difficult,
    at best, to modify VAXELN at this point to terminate with a FIN instead
    of the RESET.
    
    	BTW: The note you referenced is really note 5490 in LASSIE::UCX,
    right?