jenst@cernvax.cern.ch (Jens Trier Rasmussen) (03/05/90)
I have a small problem with mail11v3, its use of DECnet information and
its status messages to sendmail.
When mail11v3 tries to send a VMSmail message to a DECnet-VAX node, where
DECnet has been shut down it gives, after some time, the message the status:
(Deferred: Remote MAIL object at node not responding)
When I use the command ncp show node node the only visible information is
that the number under the delay heading increases like this:
Node Volatile Summary as of Mon Mar 5 15:40:05 MET 1990
Node State Active Delay Circuit Next Node
Links
node 0 26 arouter
Then I maded a small program which uses the dnet_conn routine to setup
the link to the node. This program exits immediatly with the message :
Connect failed, Node unreachable
After that the ncp command gave the information as above, except that the
delay had decreased !
When I tried to use mail11v3 again to mail to the node it also existed
immediately and the message got the status:
(Deferred: Remote node node unreachable)
Any clues ?? I'm using DECnet-Ultrix 3.0 on a RISC machine and Ultrix
Workstation Software 2.1.
cheers
Jens Trier Rasmussen
CERN-CN/CS
jenst@cernvax.cern.chmichaud@decvax.dec.com (Jeff Michaud) (03/06/90)
> When mail11v3 tries to send a VMSmail message to a DECnet-VAX node, where > (Deferred: Remote MAIL object at node not responding) > ......... > When I tried to use mail11v3 again to mail to the node it also existed > (Deferred: Remote node node unreachable) The error text means exactly what it says. It means that the remote node acknowleged our connect request for the mail-11 object (#27), but that it never accepted the connection, and the outgoing connection timer expired. Ie. Connect request => <= Connect Ack <= Connect Confirm (or Disconnect Init) We never got the last message. both errors, "object not responding" and "node unreachable" are non-fatal conditions. sendmail will continue to retry until it finally gives up after a time (default 3 days), or a fatal error is detected by mail11v3 (like "remote node is unknown", "no such user at remote node", ....). When nodes are in a state of flux (ie. rebooting, shuting down, etc...) error conditions like "object not responding" are common. /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
jenst@cernvax.UUCP (Jens Trier Rasmussen) (03/06/90)
In article <8929@shlump.nac.dec.com>, michaud@decvax.dec.com (Jeff Michaud) writes: > The error text means exactly what it says. It means that > the remote node acknowleged our connect request for the > mail-11 object (#27), but that it never accepted the > connection, and the outgoing connection timer expired. Ie. How can the remote node acknowledge the connect request when it doesn't run DECnet at all and hasn't been doing it for 10 minutes or so ? (This happens both when the remote node is a VAX/VMS and a Ultrix RISC system). Jens Trier Rasmussen CERN-CN/CS jenst@cernvax.cern.ch
michaud@decvax.dec.com (Jeff Michaud) (03/07/90)
> How can the remote node acknowledge the connect request when it doesn't > run DECnet at all and hasn't been doing it for 10 minutes or so ? > (This happens both when the remote node is a VAX/VMS and a Ultrix RISC > system). I may of mixed up the definition of that errno with the case where we don't get any response at all from the remote node after having sent out the connect request several times. Normally what happens when there are routers around, if the remote node is unreachable, and we send the routing packet out marked with "return to sender" (which we do on the connect request packet), then the router for the remote node will send the packet back and we know the remote node is unreachable. However there is a period of time between which a node goes down and the router for that node knows that the node has gone down. This depends on the frequency of the hello messages the node sends to the router. It's still non-fatal and has to be expected of nodes that are in a state of transition. /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/