Hi Toasters,
I'm bringing up a new 3020 filer where the Admin Host (unix) is on a separate subnet. I didn't have port connectivity to the subnet past a router and had the network guy open up the access-list. Afterward, I was able to mount "vol0" but I can't do a:
filer->traceroute admin-host
Nor does "rsh filer version" work from the admin host, I'm getting the following on the filer's messages file:
Mon Feb 11 19:24:58 GMT [rshd_0:info]: couldn't connect second port on admin-host@domain.com
I'm thinking networks didn't open *all* ports between filer subnet and admin hosts subnet. I'm verifying with them now.
I did configure ssh keys on the admin host (solaris 10) and am getting this upon ssh'ing into the filer:
Mon Feb 11 19:43:16 GMT [openssh.invalid.channel.req:warning]: SSH client (SSH-2.0-Sun_SSH_1.1) from {admin-host ip supressed} sent unsupported channel request (10, env)
I'm beginning my NOW research, but was hoping somebody has already seen this.
Thanks
-Rob
Admin Host: Solaris 10 Filer: DOT 7.2.3
Hi Robert
filer->traceroute admin-host
Nor does "rsh filer version" work from the admin host, I'm getting the following on the filer's messages file:
Mon Feb 11 19:24:58 GMT [rshd_0:info]: couldn't connect second port on admin-host@domain.com
I'm thinking networks didn't open *all* ports between filer subnet and admin hosts subnet. I'm verifying with them now.
For the traceroute issue it does indeed sound as if the router is dropping ICMP ECHO packets. The way RShell works is that the filer has to create a connection from any random port back to the client. In networks where NAT is in use or firewalling this can often pose a problem. It may be that the network admin needs to allow connections from the filer.
I did configure ssh keys on the admin host (solaris 10) and am getting this upon ssh'ing into the filer:
Mon Feb 11 19:43:16 GMT [openssh.invalid.channel.req:warning]: SSH client (SSH-2.0-Sun_SSH_1.1) from {admin-host ip supressed} sent unsupported channel request (10, env)
I have seen this error too on occasion, but because it has always worked I never paid too much attention to it. I believe this happens when an X-client requests to tunnel X traffic, a service which the filer does not run; but maybe others can confirm this.
Kind regards Kenneth Heal Databasement BV The Netherlands
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Hi Toasters,
I'm bringing up a new 3020 filer where the Admin Host (unix) is on a separate subnet. I didn't have port connectivity to the subnet past a router and had the network guy open up the access-list. Afterward, I was able to mount "vol0" but I can't do a:
filer->traceroute admin-host
Nor does "rsh filer version" work from the admin host, I'm getting the following on the filer's messages file:
Mon Feb 11 19:24:58 GMT [rshd_0:info]: couldn't connect second port on admin-host@domain.com
I'm thinking networks didn't open *all* ports between filer subnet and admin hosts subnet. I'm verifying with them now.
The rsh protocol has a nasty little feature where the rsh server makes a connection back to the rsh client. (Kind of like ftp when not it passive mode). So your problem is that the admin host (or intervening firewall) isn't allowing the filer to initiate a connection to the admin host. Rsh does not use a standard TCP port number for this back connection. The rsh client just uses an arbitrary available port number and tells the rsh server the port number as part of the rsh handshake.
You need to allow the filer to connect to any TCP port on the admin host.
Why two TCP connections? The first is used for stdin and stdout and the second for stderr.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Kenneth Heal -
Robert K. Borowicz -
Stephen C. Losen