home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / lans / ethernet / 1535 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  2.6 KB
  1. Path: sparky!uunet!olivea!decwrl!elroy.jpl.nasa.gov!ncar!mrbean.scd.ucar.edu!hyder
  2. From: hyder@mrbean.scd.ucar.edu (Paul Hyder)
  3. Newsgroups: comp.dcom.lans.ethernet
  4. Subject: Re: Early and Late Collision
  5. Message-ID: <1992Jul31.155839.15676@ncar.ucar.edu>
  6. Date: 31 Jul 92 15:58:39 GMT
  7. References: <1992Jul30.003641.22901@news.iastate.edu> <1992Jul30.224300.14298@ncar.ucar.edu> <nvhgb2k@rhyolite.wpd.sgi.com>
  8. Sender: news@ncar.ucar.edu (USENET Maintenance)
  9. Organization: Scientific Computing Divison/NCAR Boulder, CO
  10. Lines: 42
  11.  
  12. >> > On many hosts it is impossible to capture long collisions, only a few
  13. >> > hosts even bother to tell you about them.  You need something like
  14. >> > a LANalyzer to capture the packets.  It is important to know how far
  15. >> > into the packet the collision was, close values point to cable length
  16. >> > and longer ones other problems.
  17. >> 
  18. >> 
  19. >> How can you capture a late collision?  What will you see but the jumble
  20. >> of two simultaneous transmissions?  The bad guy will be the one whose
  21. >> first bit is in trashed by the later bits of the innocent guy.  The
  22. >> easily capturable MAC header will be that of the innocent guy.
  23. >> 
  24. >> 
  25. >> Does the LANalyzer or anything else have enough electronics to try to
  26. >> peel some of the bits apart by assuming the two clocks are different?
  27. >> Or does it compare the signal at several different points on the
  28. >> network, and thereby figure out the bad guy's bits?
  29.  
  30. <sigh, another broken promise.  ... just figure I lied.>
  31.  
  32. Slight difference in the meaning of "capture" is the key here.  All
  33. one can easily do is snag a copy of whatever garbled mess was on
  34. the net.  I don't know of any magic to strip it logically back apart.
  35.  
  36. Late collisions occur far enough into a transmission that you can
  37. often extract the address info and sometimes get clear to the protocol
  38. headers.  As is indicated in the query, you can't tell who or what is
  39. doing the stomping but you can tell who had one of the packets that
  40. will be dropped >AND< how far into the packet the collision occured.
  41. In crisis cases samples taken at various points on the net might give
  42. a set of hosts to start checking.  [Moving around has never worked for
  43. me but then I've also never had the problem end up being a cable that
  44. was too long.]
  45.  
  46. Most enet chipsets discard bad packets (CRC, late collision, etc) so
  47. you can't actually look at them on a host via utilities like tcpdump.
  48. Custom HW in lan monitors captures most bad packets, sometimes all
  49. you get is jumbled bits that can only loosely be called a packet.
  50. Much of the time there are helpful readable bits at the beginning.
  51.  
  52.     Paul Hyder
  53.     NCAR
  54.