Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!usenet.ins.cwru.edu!ysub!temngt23 From: TEMNGT23@ysub.ysu.edu (Lou Anschuetz) Newsgroups: comp.sys.ncr Subject: Re: Finding out if TCP/IP is up Message-ID: <91134.081431TEMNGT23@ysub.ysu.edu> Date: 14 May 91 12:14:31 GMT References: <91130.081040TEMNGT23@ysub.ysu.edu> <1991May13.174301.1651@NCoast.ORG> Organization: Youngstown State University VM system (YSUB) Lines: 62 In article <1991May13.174301.1651@NCoast.ORG>, jeffl@NCoast.ORG (Jeff Leyser) says: > >In post <91130.081040TEMNGT23@ysub.ysu.edu>, Lou Anschuetz > says: >!!I have an NCR Tower 700 with 16MB of memory. All my users come in >!!through the Ethernet board via a terminal server. It is possible >!!for certain dialup users (Commodore 64 in fact) to reboot their >!!machines while still on line. Since this "information" is just >!!passed down the pipeline to the tower, it attempts to handle this >!!by allocating thousands of 2k streams. I am already set at maximum > >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? :-( >!!What I need, therefore, is a way to determine if TCP/IP is up >!!from cron. If it is not I can do a win restart (a little > >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????)? > >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. This may well be the key since the PIDS are still there, it is just that it doesn't serve.... :-( :-( > >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 I get this condition then my batch file executes a "win stop" followed by a "win restart". Unfortunately, the restart seemed not to work, but may have just gotten bumped by line noise (I tried this during an electrical storm :-O). Any revisions to this technique would be appreciated, and any ideas on how to avoid it (hardware or software) would also be appreciated. It is now happening about twice a day, and is rather a nuisance.... Of course, it is impossible to easily have CODAR take a look, since it is not at all predictable. But, shouldn't WIN recognize it's failure and do some internal diagnostics, generate an error (anything)? >Jeff Leyser jeffl@NCoast.ORG Thanks in advance! Lou Anschuetz a very tired system administrator temngt23@ysu.edu