I've been on this problem for two days now, and I'm thoroughly humbled and humiliated. I'll take any help or suggestions I can get. Here's the situation:

1) I have a brand-spanking new Penguin server pre-loaded with Red Hat 6.2.

2) The ONLY files I've modified are:
/etc/hosts
/etc/sysconfig/network
/etc/sysconfig/network-scripts/ifcfg-eth0.

3) I've quadruple-checked things like IP addresses and gateways and inetd.conf.

4) I have no problem accessing the new server from my old Linux box. FTP and telnet work just fine. When I try to connect from NT4, however things get weird. I usually get an initial response and the login shows up in /var/log/messages, but echo is extreemly slow and I get dumped within ten seconds or so.

I've been down a few dead-ends so far: It does not appear to be caused by identd (I tried both installing an identd client service on NT and killing it on Linux). I also checked nsswitch.conf to make sure "files" was listed next to "network:" and "hosts:" Obviously, I can ping from NT just fine.

PLEASE HELP!!

This is probably a shot in the dark... but looking at it might give you other ideas. Sometimes Microsoft's default NetBEUI might interfere with some TCP connections. Try removing that if it's installed.

-- L. James

I appreciate the suggestion; I crossed my fingers and tried disabling NetBeui, but to no avail. Below are some lines from /var/log/messages that may shed some light for the Linux literati:

On the older Linux box (aluminum.brooklyn 2.2.13-4mdk #1 Tue Sep 7 18:23:11 CEST 1999 i686) a telnet login from the NT box yields the following "normal" output in /var/log/messages:

Dec 3 22:31:18 aluminum PAM_pwdb[6183]: (login) session opened for user dan by (uid=0)
Dec 3 22:31:19 aluminum -- dan[6183]: LOGIN ON 0 BY dan FROM hydrogen
Dec 3 22:59:54 aluminum PAM_pwdb[6183]: (login) session closed for user dan

On the newer Linux box (redstone.brooklyn 2.2.16-3 #1 Tue Aug 8 17:36:46 PDT 2000 i686) a telnet login from the older Linux box (above) yields the following "normal" output in /var/log/messages:

Dec 3 19:04:07 redstone PAM_pwdb[10066]: (login) session opened for user dan by (uid=0)
Dec 3 19:04:15 redstone PAM_pwdb[10066]: (login) session closed for user dan
Dec 3 19:04:15 redstone inetd[463]: pid 10065: exit status 1

a telnet login from the NT box yields the following abnormal output in /var/log/messages:

Dec 3 19:04:15 redstone inetd[463]: pid 10065: exit status 1

a canceled telnet login from the NT box yields the following abnormal output in /var/log/messages:

Dec 3 19:05:55 redstone telnetd[10096]: ttloop: read: Connection reset by peer
Dec 3 19:05:55 redstone inetd[463]: pid 10096: exit status 1

I noticed that the inetd exit status codes are missing from the older Linux server's log. Maybe that's important?

Check the DNS information for your Windows NT machine. Make sure the IP address matchings the reverse nslookup.

If your ip address for the NT machine is 10.1.2.3, then the command nslookup 10.1.2.3 should show the name of the NT machine. If you to nslookup the name of the NT machien, you should get the IP 10.1.2.3.

-- L. James

Dlindy. Sorry to give you two things that doesn't work. I just reread your first message. You said you thoroughly checked the IP addresses and names and you were able to log on but the access was unreliable. It it were the problem I just described in my last post, your commection would be totally refused and you'd probably not be precented with a login prompt. You especially wouldn't be able to log in.

We'll have to keep looking for other posible causes.

-- L. James

Actually, it's never occurred to me that reverse-DNS would be required for things like telnet and FTP. I only use these behind my NAT-enabled firewall where it should be pretty safe. It does look like it's the authentication that's hanging, though; like it might be trying to do a reverse-DNS lookup and then timing out or something similar.

It looks like there are two ways to go at this point. I could try running a name-server internally (extra overhead I really don't need. host files work fine right now). Or, I could assume the versions of FTP and telnet that come with Red Hat 6.2 have cleaned up security holes to the degree that NT can't connect anymore.

The second option sounds more likely to work to me. If that is the problem, then I'm pretty miffed because telnet and FTP are inherently insecure to begin with. They're the types of services you just want to have work so you can get on with more important stuff. (If security is an issue, I would turn them off completely and use ssh/scp.)

I'll go ahead and try these options, and check the host file entries once again for these two boxes. At least it's something. Let me know if you think of something else. And THANKS for the suggestions.

Although I no longer use telnet I do not think that it needs reverse DNS to work correctly. It is ssh that complains and is real slow to connect if there is no reverse DNS. I connect to my Linux boxes from NT/2000 on occasion so they definitely CAN connect. Are you using the NT telnet client? If so you may want to try CRT which is a very nice program (I use Secure CRT on my 2000 box).

I mostly use putty from NT. It's a great little utility that supports telnet and ssh. I also connect to Sybase running on my Linux machines from NT, not to mention WS-FTP, regular old HTTP browsers etc. I really don't know why these new 6.2 servers are so problematic from NT. I keep thinking there's something stupid I've over-looked.

It's my experience that if you don't have a dns entry for an IP you can telnet in with no problems. But if you have a dns entry, and it's misconfigured, then none of the machines in my netowrk would allow that machine access.

This is the default with my Slackware and SCO box.

I mention to the user that this might not be the problem in their case because there is a reference to actually being connected, whereas I don't think a reverse DNS lookup culprit would never have allow a connection. I believe the syslog entry would report connection refused.

-- L. James

I have used putty in tha past, it's a great little program - it even fits on a floppy. Just a long shot but do you have tcp wrappers configured to allow connections from the ip of the NT box?

Dlindy. You say you're able to connect, but the connection is poor. I've seen another situation simular. I don't know why the Windows 98 machine had suddenly started being slow on the network. But I uninstalled all the network drivers. Rebooted the machine. Then reinstalled the network drivers and it worked fine. I recall reading a fix like this in one of the Microsoft Groups.

This is a pain to have to do, and be sure to remember the IP address, NT Domain and workgroup configuration otherwise this might present a new problem

Also, tell us, are you able to telnet from any other Microsoft machine? Since you say you can telnet from your other Linux machine, it appears to be a Microsoft protocol configuration problem.

By the way, you didn't make a comment about your DNS check.

-- L. James

Jeremy: Please explain about "tcp wrappers configured to allow connections from the ip of the NT box." I'm not sure what that means. (e.g. hosts.allow/deny? identd? inetd?) I'm trying to open things up as much as possible for now just to get it working; there are no entries in either hosts.allow of hosts.deny.

Larry: Havn't tried setting up a local DNS yet, but it's on my list. Also, I don't want to mess with my NT box unless absolutely necessary. (It would take several days just to rebuild my development environments if I screw things up.) And since I can connect to my older Linux servers from NT, I doubt if re-installing the same network drivers would fix the problem.

At this point I'd be surprised it it were not a DNS problem. I can only think of two. The DNS configuration and the network drivers installed on your NT machine.
It should be simple to check the DNS configuration. All you have to do is go to the Linux machine and ask it what is it seeing when you connect. You can do this by typing:

nslookup IP Number (The IP of your NT machine)

nslookup Name (The name that Linux Just gave you if it gave you a name)

I've fixed a lot of problems, but it's hard to go to another step when the first might be the most obvious.

Keep in mind that I did caution you about the NT drivers being a last resort, as it may take a lot of work to get the drivers back. I also saw a case this didn't fix the problem. We acutally had to reinstall the Operating system. Of course Windows 98 isn't as stable as Windows NT, so the reinstalling might not be an issue here at all. But I'm seen numerous occasions where no matter what you did in trying to configure something on the machine, there will be something left that won't change until the OS is reinstalled.

There are many varibles that reinstalling the OS fixes. Sometimes subsequent program modify important system files with their updates and it's hard to find which ones are the culprit.
As you said before, when you find the solution, you'll find that it was really something very simple. Those are the hardest to find.

I've been very anxious to know your nslookup status. Does the reverse match. Everytime I get a message, I pop to it right aways hoping to learn this.

-- L. James

I tried swapping IP's between the older, working Linux server and the new one, but the behavior was identical.

I'm still not understanding how DNS figures into this as telnet doesn't require a reverse-lookup to authenticate. Anyway these machines are on my internal LAN and do not have entries on any name server. Here's what happens with nslookup:

[root@redstone /root]# nslookup 10.1.1.103
Server: ne1.res.dns.psi.net
Address: 38.9.211.2

*** ne1.res.dns.psi.net can't find 10.1.1.103: Non-existent host/domain
[root@redstone /root]#


I'm sure you're right, that it's something simple. Just wish I knew what it was...

It might not be telnet that does the reverse lookup, but the Linux and Unix im ny network will refuse to allow a connection if the reverse IP lookup fails. If there's no DNS record for the IP it won't complain. But if there is a DNS for the IP address and it and name doesn't return that IP address, most of the machines I've looked at will refuse the connection.
From your message, since nslookup doesn't return a name, this most likely isn't the curprit in your case. I was relaying my personal experince with you when I asked you to check that. I always use telnet for most of my applications unless I'm browing the web. I recently added a block of lines to my network and added the PTR records but neglected to add A records. I was with a client and actually had to use Hyperterm to dial in rather than dialup networking to telnet in. Telnet refused the connection until I fixed it.
I know there's a way to turn it off. But I leave in on, and just fix the DNS. I've never purposely configured this. This is the default for the very ancient version 3.2R4.0 of SCO and the and the 7.1 of Slackware.
If I come up with some other things to check I'll pass them on to you.
Since I gave you two or three things that didn't resolve your problem, I understand your apprehension to think removing and reinstalling the drivers would help. I don't know about Windows NT because I've never trouble shooted it. I've set it up a few times for various clients. Was fortunate that I never had a problem with the applications setting up. But if it were Windows 9X I would have already went the route of removing and reinstalling the drivers. That has fixed a Windows 9X networking problem many times. This is an expression of the lack of solidness of Windows 95/98 and may not have carried over to Windws SE, ME, 2000, and NT.

-- L. James