The problem:
I installed the Solaris 8 recommended patch cluster 117350-11 over 108528-15 before the Christmas break. The server is a SunFire V100. Here is the situation:

Before the patch install, there was a working cron job that did daily, weekly, and monthly backups of the V100 filesystems over the network to a tape device.
Here is a extract from the log file when it worked BEFORE:

Dumping /dev/rdsk/c0t2d0s0 (apples:/) to oranges:/dev/rmt/5mn

After the patch install, here is a extract of the same log:

DUMP: NEEDS ATTENTION: Cannot open `oranges:/dev/rmt/5mn'. Do you want to retry the open?: ("yes" or "no") DUMP: The ENTIRE dump is aborted.

I found out that telnet from apples to oranges DOES NOT work. When I type "telnet oranges", the "Trying 123.45.67.89" message is displayed, but no connection is established.

When I telnet from oranges to apples, it works.

What I checked:

Here is the netstat -nr info on the patched system apples:

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
123.45.253.72 123.45.253.74 (apples) U 1 2261 dmfe0
224.0.0.0 123.45.253.74 (apples) U 1 0 dmfe0
default 123.45.253.73 (peach) UG 1 16613

/etc/defaultrouter 123.45.253.73

Here is the netstat -nr info from oranges (Ultra 1):

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
123.45.94.0 123.45.94.36 (oranges) U 1 12322 le0
224.0.0.0 123.45.94.36 (oranges) U 1 0 le0
default 134.51.94.1 (grapes) UG 1 17538

/etc/defaultrouter 134.51.94.1

I don't have /etc/hosts.deny or /etc/hosts.allow in either apples or oranges. I do have a /etc/hosts.equiv on oranges, which has the apples host in it:

/etc/hosts.equiv apples

but no /etc/hosts.equiv file in apples.

I searched the forums, but couldn't find any posts where a patch caused telnet to stop working.

So, the BIG question is:

Why does telnet work one-way, but not the other way?

Let me know if you need any other info.

Thanks

Could you telnet before the patch? Do you really KNOW that you could telnet? Think about it - you are trying to figure out why your backup isn't working, not if telnet is working. Telnet may not have worked before.

Why does telnet work one way but not the other? Because one server doesn't allow it. First check the date on your /etc/inetd.conf file - see if it was changed by during the date you did the patch. Check your /etc/inetd.conf file on the server that does and the server that doesn't. Look for "telnet stream tcp" line - see if it starts with a # sign. If so, then it's commented out and won't work (probably a good thing).

Ufsdumps to a remote server usually use the /etc/hosts.equiv or /.rhosts files for allowing access - has nothing to do with telnet. Check the dates of those files and try to find out if and when they changed. I doubt the patch had anything to do with changing them.

Looks like the problem is resolved regarding the ufsdump issue. It was explained to me using very techie jargon, but the network admin that I spoke to made a few changes to a "policy setting", checked that rsh from apples worked ok, and pronounced it "fixed". He told me to run the ufsdump (which is now working) and let him know in the morning if the logs show successful dumps.

This should close the thread out, but I'm left wondering "What would cause the rsh to stop working after the patch?" I'll have to look further into the patch docs to see if rsh is affected.

Thanks RTM for the help. I know more about /etc/hosts.equiv and /.rhosts to know that those two files were correctly populated with the apple host name on oranges to know that it should have worked.

Forgot to say that you are right, RTM, in that telnet never worked from apples. apples is a gateway for access to another company's domain (we do sub-contract work and need access to their data). Any of our workstations can get to apples, but apples cannot get to our domain.

Thanks again... :-)