Re: Cannot connect with Telnet client, other TCP/IP clients

Thanks Jim.
(And John, the QAUTOCFG is 1 and the QAUTOVRT is 200)

The route list is pretty simple since I have only the local host and this one Ethernet adapter defined:

Route Subnet Next Route
Opt Destination Mask Hop Available
127.0.0.0 255.0.0.0 *DIRECT *YES
192.168.200.0 255.255.255.0 *DIRECT *YES
224.0.0.0 240.0.0.0 *DIRECT *YES
224.0.0.0 240.0.0.0 *DIRECT *YES
*DFTROUTE *NONE 192.168.200.2 *YES

I would have *expected* a route like this to be present as well:
192.168.200.0 255.255.255.0 192.168.200.2 *YES

I DO see that route on the 520 and I would have expected the routing logic to send all 192.168.200.0 traffic to the 192.168.200.2 host because it was on the same subnet. Not sure what *DIRECT means but I assume that it thinks all the hosts for 192.168.200.0 are local and don't need to go out the gateway. I am beginning to think that something is wrong deep in the bowels of TCP/IP. Perhaps an IPV6 issue (I have seen some of that in other areas but not on the i).

As an interesting side note: When I deleted the original interface, route and then line and recreated them, I got a "failed" status when I first attempted to start the interface. The job log said that there was another adapter that already had that IP address (there wasn't). Turns out that the controller and device that was created when line started didn't get deleted along with the line. I originally played with an alternate addresses thinking I had a duplicate on the network and it turns out it was the "old" descriptions carried by the original line.

Perhaps I'll give IBM a ring and see what they think.

Pete Helgren
Value Added Software, Inc
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 8/1/2012 5:14 AM, Jim Oberholtzer wrote:

Pete;

Yesterday I had very similar difficulties at a client. Differences are
this is P6, HMC console, and LPARs but I don't think that's a factor
since you were able to get in with the LAN console. Routing on this box
is correct, although that could be a problem for you as well. We just
restarted the telnet server and it started working without having to
recreate anything. We have experienced similar problems with the SMTP
server as well. I'm starting to wonder if there is a fault somewhere
deep in TCP. We have a PMR open and are working it actively however
every time we try to trace it, we do not see a failure.

We were planning on getting all the most recent PTFs/Groups etc hoping
there was a problem that was fixed but it seems you have debunked that
theory. That system is not that far back in PTFs anyway but it never
hurts to hope...

In the mean time try a telnet server restart. Have you tried NETSTAT
to see if the route is valid?

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects