home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / infosyst / gopher / 426 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  1.6 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!canterbury.ac.nz!cantua.canterbury.ac.nz!cantsc.canterbury.ac.nz!cctr127
  2. From: cctr127@cantsc.canterbury.ac.nz (Jason Haar)
  3. Newsgroups: comp.infosystems.gopher
  4. Subject: Re: Gopher, Ultrix and netstat
  5. Message-ID: <BuHyKz.6FL@cantua.canterbury.ac.nz>
  6. Date: 13 Sep 92 03:19:47 GMT
  7. References: <1992Sep12.160620.8052@bernina.ethz.ch>
  8. Reply-To: j.haar@csc.canterbury.ac.nz
  9. Organization: University of Canterbury, Christchurch, New Zealand.
  10. Lines: 46
  11. Nntp-Posting-Host: cantsc.canterbury.ac.nz
  12. X-Newsreader: Tin 1.1 PL3
  13.  
  14. karrer@bernina.ethz.ch (Andreas Karrer) writes:
  15. > 
  16. > is this a bug in the TCP implementation that does not properly close a
  17. > TCP connection after a timeout?
  18. > 
  19. > i've seen similar things with nntp connections originating from a
  20. > particular (broken?) newsreader, on an ultrix machine.
  21. > 
  22. > anyway, i think a TCP server should be able to close a TCP connection
  23. > cleanly even with mis-behaving clients.
  24.  
  25. It's a problem with TCP/IP - although some developers claim it's a feature
  26. - not a bug ;-)
  27.  
  28. To kill them off, either:
  29.  
  30. a) reboot ;-))
  31.  
  32. or
  33.  
  34. b) follow this arcane advise I got from a mailing-list (it works at least
  35. under SunOS 4.1.*)
  36.  
  37. do a 'netstat -A'
  38.  
  39. >connection, as evidenced by the output from netstat -A:
  40. >
  41. >ff68000c tcp   0  96  stis.70   192.139.2.152.15669 CLOSING
  42. >
  43. >Apparently, Matt Crawford (matt@oddjob.uchicago.edu) is the expert on
  44. >this, because he immediately sent me the following cryptic, but
  45. >effective, advice:
  46. >
  47. > adb -w /vmunix /dev/kmem
  48. > ff68000c+8/w 0
  49. > $q
  50. >
  51. > then wait up to 2 minutes.
  52.  
  53.  
  54.  
  55. Hope that helps
  56.  
  57. Cheers
  58.  
  59. Jason Haar, Network Consultant
  60.