telnet not accessible - redux ?

[Doug O'Leary]

Hey

To restart the story from scratch: I have an old K220 running HPUX 11.00 that someone suddenly needs to access via telnet. ssh works to and from the box so the networking routes are correct. Additionally, I found that even telnet from another box on the same network segment times out, so routing is pretty much out of the picture.

I looked for /var/adm/inetd.sec and found everything in it completely commented.

# grep -v ^# /var/adm/inetd.sec
#

Telnet is not wrapped and is available in /etc/inetd.conf:

# grep telnet /etc/inetd.conf
telnet stream tcp nowait root /usr/lbin/telnetd telnetd

In the prior post, I was having difficulty finding out whether or not the packets were even reaching the host. After failing miserably at getting any level of support from our esteemed network colleagues, I finally found a copy of tcpdump for hpux 11.00. As it turns out, the telnet traffic is actually getting to the box.

tcpdump: listening on lan0
20:13:57.651039 111.222.333.116.61829 > 111.222.333.56.23: S 2924435980:29244359
80(0) win 32768 (DF)
20:14:00.713746 111.222.333.116.61829 > 111.222.333.56.23: S 2924435980:29244359
80(0) win 32768 (DF)
20:14:06.833787 111.222.333.116.61829 > 111.222.333.56.23: S 2924435980:29244359
80(0) win 32768 (DF)
20:14:19.044343 111.222.333.116.61829 > 111.222.333.56.23: S 2924435980:29244359
80(0) win 32768 (DF)
20:14:43.433777 111.222.333.116.61829 > 111.222.333.56.23: S 2924435980:29244359
80(0) win 32768 (DF)

2886 packets received by filter
0 packets dropped by kernel

So, it looks like there is something filtering traffic on that box. Does anyone have a clue where I should be looking next?

Thanks for your time and help.

Doug O'Leary

[Doug O'Leary]

Hey;

I found a site that gives some examples on tracing using nettl/netfmt. I've attached the results of running

nettl -tn 0x30800000 -e all -ks 5M -us 10M | \
netfmt -F -N -n -l -c /tmp/filterfile | tee /tmp/telnet1

minus all the extraneous 'packet filetered out messages'.

I'm not seeing anything in there indicative of a problem - but then, I doubt I would. Any other ideas on what I can/should try?

Thanks.

Doug

[Doug O'Leary]

Hey;

And, one more data point: I took another tcpdump on the system that's having the telnet issue - address ends in 56. host01 is the source of the telnet on the same network as the target system.

# tcpdump -i lan0 -n dst host01 or src host01
tcpdump: listening on lan0
21:58:03.537791 111.222.333.116.55654 > 111.222.333.56.23: S 565732272:565732272
(0) win 32768 (DF)
21:58:06.608707 111.222.333.116.55654 > 111.222.333.56.23: S 565732272:565732272
(0) win 32768 (DF)
21:58:12.728724 111.222.333.116.55654 > 111.222.333.56.23: S 565732272:565732272
(0) win 32768 (DF)
21:58:15.961487 arp who-has 111.222.333.116 (ff:ff:ff:ff:ff:ff) tell 111.222.333
.64
21:58:24.938920 arp who-has 111.222.333.56 (ff:ff:ff:ff:ff:ff) tell 111.222.333.
116
21:58:24.940227 arp reply 111.222.333.56 is-at 0:10:83:96:60:d0
21:58:24.941164 111.222.333.116.55654 > 111.222.333.56.23: S 565732272:565732272
(0) win 32768 (DF)
21:58:49.328797 111.222.333.116.55654 > 111.222.333.56.23: S 565732272:565732272
(0) win 32768 (DF)

6763 packets received by filter
0 packets dropped by kernel


Am I missing it? The 56 host doesn't ever seem to send a packet back to host01, does it? I was thinking I should see both directions with the tcpdump filter "dst host01 or src host01"...

Thanks. That's the last response to my own posts, I promise...

Doug

[Matti_Kurkela · Accepted solution]

That sure looks like a network problem of some sort. The system should normally react to a connection attempt even if telnetd (or even inetd) was disabled: you should see a TCP reset packet as a response in that case.

But there does not seem to be any response at all. Maybe something prevents the incoming packet from being processed further, or perhaps the response packet gets blocked or directed somewhere else.

First, does this system have multiple network interfaces? If it has more than one, what does the routing table look like?

Perhaps the outgoing packets are configured to go through a different interface. That would confuse the system with the telnet client: "Why isn't the system at MAC address A not answering me? And what is this completely different MAC address B that pretends I was opening a connection to it, when clearly I wasn't?"

Your system might also have IPFilter installed and configured to block telnet connections. Please see:

http://docs.hp.com/en/B9901-90029/index.html
(the link seems to still work... for now at least)

MK

[Doug O'Leary]

Hey;

No; just the one interface. I'll look into the filtering. Thanks for the suggestion.

Doug

[Doug O'Leary]

Hey;

ipfilter was the culprit! That was the key bit of information. I was able to disable the filter and get everything working.

Thanks alot for the tip.

Doug O'Leary