Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!usenet.ins.cwru.edu!ncoast!jeffl From: jeffl@NCoast.ORG (Jeff Leyser) Newsgroups: comp.sys.ncr Subject: Re: Finding out if TCP/IP is up Message-ID: <1991May15.142242.3193@NCoast.ORG> Date: 15 May 91 14:22:42 GMT References: <91130.081040TEMNGT23@ysub.ysu.edu> <1991May13.174301.1651@NCoast.ORG> <91134.081431TEMNGT23@ysub.ysu.edu> Organization: North Coast Public Access Un*x (ncoast) Lines: 66 In post <91134.081431TEMNGT23@ysub.ysu.edu>, Lou Anschuetz says: !!In article <1991May13.174301.1651@NCoast.ORG>, jeffl@NCoast.ORG (Jeff Leyser) !!says: !!> !!>In post <91130.081040TEMNGT23@ysub.ysu.edu>, Lou Anschuetz !!> says: !!> [Wierd stuff causing WIN-TCP to crash] !!>First off, I don't understand this at all. What "information" is being !!>sent down what "line?" !!Basically, every bit of machine code that the machine is executing !!is sent out through their modem, comes in through my modem, passes !!silently through the terminal server and into the ethernet board on !!the tower. So, the tower sees every bit of machine code the PC on !!the other end executes. Neat, huh? :-( Sounds like the real long term solution is to shoot the people using these machines! ;^) !!>!! [ How to tell if WIN-TCP is down ] !!> !!>Several things, depending on how WIN crashed: !!> !!>A) Grep through a ps -aef and look for tcplisten, inetinit, and listen !!>(if you have listen configured to run at all) !!tcplisten and inetinit are still listed as active PIDS when this !!occurs. What is listen (I didn't see that anywhere in the manual????)? Listen is used to, ummm, listen for services not known to tcplisten. Two popular services that use listen are UUCP over TCP, and RFS. !!>B) Look at the output of an ifconfig. Maybe WIN is marking the !!>interface as down. !!I guess I don't know how to do that. Any help would be appreciated. /usr/etc/ifconfig [en0|lo0] Where en0 is the first ethernet board, and lo0 is the loopback. !!>C) run a netstat in the background, with it's output going to a file. !!>check the file for data. If there is no data after a reasonable time, !!>kill the netstat, and assume WIN is hosed. !!I think I found a slightly easier way since netstat always creates !!/tmp/netstatdata, even if it isn't collecting any data :-( !!My approach is to use ping and if I get "100% packet loss" to !!myself (yep, I can't get to me either through the loopback - why - !!I don't know). If all the processes are still up, but you can't ping through loopback or through ethernet, it's a good bet your STREAMS drivers are screwed up. This would also jibe with your remark about WIN-TCP requesting a whole bunch of STREAMS buffers. Two things you can check -- see if the process inetinit is alive and well. This process maintains the STREAMS drivers. However, it is possible to have the processes running, and the drivers messed up. DO NOT SIMPLY RESTART THE PROCESS. You _MUST_ stop and start all of WIN_TCP. If inetinit is up, and things still don't work, do what you are already doing -- ping the loopback. (Ping sends ICMP packets requesting an echo. If you can't echo to yourself, either the "send" isn't going down to the loop, or the loop can't give ping the "recieve." In either case, the drivers are screwed up.) However, all of this is nothing more than a patch. You really need to _educate_ the users who are causing the crash. Teach them what not to do, and tell them all the problems they are causing. Otherwise, you'll be chasing your tail on this one for a long, long time. -- Jeff Leyser jeffl@NCoast.ORG