From: 72510.553@compuserve.com ("Richard V. Ford")
Newsgroups: comp.protocols.appletalk
Subject: Re: Evil Packets
Date: 22 Jul 92 17:41:49 GMT
Distribution: world
Organization: The Internet

Sorry for the delay in sending a response...

I posted several months ago about a problem with DDP broadcast storms.  The
problem has been tracked down to a known bug in the Rival anti-virus program.
There is a fixed version available if you ask the vendor.  Only machnes 
running the Rival software that have ethernet cards cause the problem.  

You can find out if the problem is happening on your network by using a 
protocol analyzer and looking for packets of DDP type=0  with the sequence
09876543210987654321 in the data portion of the packet.  A trace packet
was included in the original message and is appended below for reference.

I've not yet tracked down what network conditions trigger the storm, but the
problem has been resolved by installing the newer version of the software.

Log this one in your tech support databases.

-Richard

------------------------------------------------------------------------------
Richard Ford
Falcon Microsystems
Landover MD 20785 USA
301-386-6440 (voice) 341-0187 (fax)

Mail: 72510.553@compuserve.com





*****************************************************************************
original message follows
*****************************************************************************

To:      >internet:info-appletalk@andrew.cmu.edu
Subject: Evil Packets

Hi - 

I'm trying to track down the source of a DDP broadcast storm that takes down
the ethernet on which it occurs.  Any insights from those of you who might have
seen this before would be greatly appreciated.

Background:

The network topology abstracts to two segments separated by a cisco IGS, one
side with a FastPath5 (KSTAR 9.1) and two VAXes running PacerShare (AppleTalk
Routers), and a QuickMail 2.5 server running on a IIci.  The other side of the
cisco is an ethernet with a dozen Fastpaths, an AppleShare Server, and a
Meeting Maker Server.  The network is exclusively Phase II, and most of the
Fastpaths are FP 4's with upgraded proms and KSTAR 9.1.  Each segment has a
network number range of 1, and a single associated zone name.  Extensive
analysis reveals no routing problems.

The problem:

For some not-yet-explained reason, random ethernet-connected Mac's will start
streaming packets to address 0.255 (dump appended below) repeatedly at a rate
exceeding 200/sec.  This DDP broadcast storm can only be stopped by powering
off the offending Mac.  During the storm, the ethernet side LED on the
Fastpaths go solid (LED on) and the PBN drops ccounter in RouterCheck increases
dramatically. All routing grinds to a halt (no RTMP's are exchanged) and no
ethernet-connected users see zones.  When the storm is stopped, the network
recovers, one sees a series of AARP's, RTMP's and ZIP's as the routers
converge.  Apparently if a storm is long enough, all the learned routes age out
of the routers.  

Raw and decoded versions of the packet are appended to this message.  It was
interesting to ot that DDP type 0 was used (Inside AppleTalk says don't use
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
data portion of the packet (thanks to Tom Evans for noticing the pattern).  I
checked the network with Inter*Poll and no applications are registered as using
socket 67.

The source machine:

The problem has occured with Macs containing ethernet boards from multiple
manufacturers (both Asante and 3com boards are on the network), and from
multiple CPU types (IIsi, IIci etc...).  Both system 7.0 and 6.0x machines 
have had this happen.  The machine from which the packet in the data capture
started had an Asante board, Asante ethernet drivers, QuickMail 2.5
workstation, Meeting Maker and Status*Mac on it.  The problem pre-dated the
Status*Mac installation.  The problem does not occur at any "fixed" time 
(i.e. bootup, 10 min after bootup etc...) but does happen every day or two, 
sometimes more often.

I have looked at the data set closely and also found at least one other machine
sending out packets with DDP type zero, and the 987654321 pattern but have not
yet been able to isolate the software package sending out the packets.  It was
on the LocalTalk side of a Fastpath and sending the packets out every minute or
two.  I have not yet determined whether streaming occurs on LocalTalk Macs, and
whether there is some type of "trigger" packet that comes in from the ethernet
that effects ethernet-connected Mac's.

Does there exist a package that can be run on a Mac and list all sockets in
use, both those with registered NBP entities and those without?  This type of
software would simplify determing what network package is sending out the
packets.  Is there an easy way to do this with MacsBug?

---
raw packet
---

Total packets = 1


Packet #1     Packet size = 64     Timestamp = 16 (ms)
09 00 07 ff ff ff 00 00 94 04 bb e1 00 21 aa aa    .............!..
03 08 00 07 80 9b 00 19 11 34 00 00 00 01 ff 38    .........4.....8
43 43 00 00 00 09 87 65 43 21 09 87 65 43 21 00    CC.....eC!..eC!.
00 00 00 00 00 00 00 00 00 00 00 00 14 fe 5b b0    ..............[.

---
decoded packet/ NetMinder EN
---
Packet 1
Size:  64
T (ms)= 16 (4/15/92 4:12:42 PM)
Errors:  None

   Ethernet Header
Destination    =ATalk_BCast
Source         Asante04bbe1
Length         $0021

   ATalk Phase 2 Header
DSAP           $aa
SSAP           $aa
Control        $03
Protocol       ATalk

   Long DDP Header
Length         25 (Hops=0)
Checksum       $1134
Dest Net       0
Src Net        1
Dest Node      255
Src Node       56
Dest Socket    67
Src Socket     67
Type           $0

   Packet Data
00 00 09 87 65 43 21 09    ....eC!.
87 65 43 21                .eC!

   Pad/CRC Bytes
00 00 00 00 00 00 00 00    ........
00 00 00 00 00 14 fe 5b    .......[
b0                         .

-----

Thank's in advance.

-Richard

Richard Ford
Falcon Microsystems
Landover MD 20785 USA
301-386-6440 (voice) 341-0187 (fax)

Mail: 72510.553@compuserve.com
Newsgroups: comp.protocols.appletalk,comp.protocols.tcp