home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / appletal / 2870 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  6.1 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!pacbell.com!att!ucbvax!compuserve.com!72510.553
  2. From: 72510.553@compuserve.com ("Richard V. Ford")
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: Re: Evil Packets
  5. Message-ID: <920722174148_72510.553_DHB66-2@CompuServe.COM>
  6. Date: 22 Jul 92 17:41:49 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 164
  11.  
  12. Sorry for the delay in sending a response...
  13.  
  14. I posted several months ago about a problem with DDP broadcast storms.  The
  15. problem has been tracked down to a known bug in the Rival anti-virus program.
  16. There is a fixed version available if you ask the vendor.  Only machnes 
  17. running the Rival software that have ethernet cards cause the problem.  
  18.  
  19. You can find out if the problem is happening on your network by using a 
  20. protocol analyzer and looking for packets of DDP type=0  with the sequence
  21. 09876543210987654321 in the data portion of the packet.  A trace packet
  22. was included in the original message and is appended below for reference.
  23.  
  24. I've not yet tracked down what network conditions trigger the storm, but the
  25. problem has been resolved by installing the newer version of the software.
  26.  
  27. Log this one in your tech support databases.
  28.  
  29. -Richard
  30.  
  31. ------------------------------------------------------------------------------
  32. Richard Ford
  33. Falcon Microsystems
  34. Landover MD 20785 USA
  35. 301-386-6440 (voice) 341-0187 (fax)
  36.  
  37. Mail: 72510.553@compuserve.com
  38.  
  39.  
  40.  
  41.  
  42.  
  43. *****************************************************************************
  44. original message follows
  45. *****************************************************************************
  46.  
  47. To:      >internet:info-appletalk@andrew.cmu.edu
  48. Subject: Evil Packets
  49.  
  50. Hi - 
  51.  
  52. I'm trying to track down the source of a DDP broadcast storm that takes down
  53. the ethernet on which it occurs.  Any insights from those of you who might have
  54. seen this before would be greatly appreciated.
  55.  
  56. Background:
  57.  
  58. The network topology abstracts to two segments separated by a cisco IGS, one
  59. side with a FastPath5 (KSTAR 9.1) and two VAXes running PacerShare (AppleTalk
  60. Routers), and a QuickMail 2.5 server running on a IIci.  The other side of the
  61. cisco is an ethernet with a dozen Fastpaths, an AppleShare Server, and a
  62. Meeting Maker Server.  The network is exclusively Phase II, and most of the
  63. Fastpaths are FP 4's with upgraded proms and KSTAR 9.1.  Each segment has a
  64. network number range of 1, and a single associated zone name.  Extensive
  65. analysis reveals no routing problems.
  66.  
  67. The problem:
  68.  
  69. For some not-yet-explained reason, random ethernet-connected Mac's will start
  70. streaming packets to address 0.255 (dump appended below) repeatedly at a rate
  71. exceeding 200/sec.  This DDP broadcast storm can only be stopped by powering
  72. off the offending Mac.  During the storm, the ethernet side LED on the
  73. Fastpaths go solid (LED on) and the PBN drops ccounter in RouterCheck increases
  74. dramatically. All routing grinds to a halt (no RTMP's are exchanged) and no
  75. ethernet-connected users see zones.  When the storm is stopped, the network
  76. recovers, one sees a series of AARP's, RTMP's and ZIP's as the routers
  77. converge.  Apparently if a storm is long enough, all the learned routes age out
  78. of the routers.  
  79.  
  80. Raw and decoded versions of the packet are appended to this message.  It was
  81. interesting to ot that DDP type 0 was used (Inside AppleTalk says don't use
  82. type 0), and also the pattern 0,9,8,7,6,5,4,3,2,1,0,9,8,7,6,5,4,3,2,1,0  in the
  83. data portion of the packet (thanks to Tom Evans for noticing the pattern).  I
  84. checked the network with Inter*Poll and no applications are registered as using
  85. socket 67.
  86.  
  87. The source machine:
  88.  
  89. The problem has occured with Macs containing ethernet boards from multiple
  90. manufacturers (both Asante and 3com boards are on the network), and from
  91. multiple CPU types (IIsi, IIci etc...).  Both system 7.0 and 6.0x machines 
  92. have had this happen.  The machine from which the packet in the data capture
  93. started had an Asante board, Asante ethernet drivers, QuickMail 2.5
  94. workstation, Meeting Maker and Status*Mac on it.  The problem pre-dated the
  95. Status*Mac installation.  The problem does not occur at any "fixed" time 
  96. (i.e. bootup, 10 min after bootup etc...) but does happen every day or two, 
  97. sometimes more often.
  98.  
  99. I have looked at the data set closely and also found at least one other machine
  100. sending out packets with DDP type zero, and the 987654321 pattern but have not
  101. yet been able to isolate the software package sending out the packets.  It was
  102. on the LocalTalk side of a Fastpath and sending the packets out every minute or
  103. two.  I have not yet determined whether streaming occurs on LocalTalk Macs, and
  104. whether there is some type of "trigger" packet that comes in from the ethernet
  105. that effects ethernet-connected Mac's.
  106.  
  107. Does there exist a package that can be run on a Mac and list all sockets in
  108. use, both those with registered NBP entities and those without?  This type of
  109. software would simplify determing what network package is sending out the
  110. packets.  Is there an easy way to do this with MacsBug?
  111.  
  112. ---
  113. raw packet
  114. ---
  115.  
  116. Total packets = 1
  117.  
  118.  
  119. Packet #1     Packet size = 64     Timestamp = 16 (ms)
  120. 09 00 07 ff ff ff 00 00 94 04 bb e1 00 21 aa aa    .............!..
  121. 03 08 00 07 80 9b 00 19 11 34 00 00 00 01 ff 38    .........4.....8
  122. 43 43 00 00 00 09 87 65 43 21 09 87 65 43 21 00    CC.....eC!..eC!.
  123. 00 00 00 00 00 00 00 00 00 00 00 00 14 fe 5b b0    ..............[.
  124.  
  125. ---
  126. decoded packet/ NetMinder EN
  127. ---
  128. Packet 1
  129. Size:  64
  130. T (ms)= 16 (4/15/92 4:12:42 PM)
  131. Errors:  None
  132.  
  133.    Ethernet Header
  134. Destination    =ATalk_BCast
  135. Source         Asante04bbe1
  136. Length         $0021
  137.  
  138.    ATalk Phase 2 Header
  139. DSAP           $aa
  140. SSAP           $aa
  141. Control        $03
  142. Protocol       ATalk
  143.  
  144.    Long DDP Header
  145. Length         25 (Hops=0)
  146. Checksum       $1134
  147. Dest Net       0
  148. Src Net        1
  149. Dest Node      255
  150. Src Node       56
  151. Dest Socket    67
  152. Src Socket     67
  153. Type           $0
  154.  
  155.    Packet Data
  156. 00 00 09 87 65 43 21 09    ....eC!.
  157. 87 65 43 21                .eC!
  158.  
  159.    Pad/CRC Bytes
  160. 00 00 00 00 00 00 00 00    ........
  161. 00 00 00 00 00 14 fe 5b    .......[
  162. b0                         .
  163.  
  164. -----
  165.  
  166. Thank's in advance.
  167.  
  168. -Richard
  169.  
  170. Richard Ford
  171. Falcon Microsystems
  172. Landover MD 20785 USA
  173. 301-386-6440 (voice) 341-0187 (fax)
  174.  
  175. Mail: 72510.553@compuserve.com
  176.