Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!eagle.ukc.ac.uk!icdoc!qmc-cs!liam
From: liam@cs.qmc.ac.uk (William Roberts)
Newsgroups: comp.protocols.appletalk
Subject: Re: AppleTalk analyzer...
Summary: I have a Sun program to analyse ETherTalk
Keywords: EtherTalk, Sun
Message-ID: <730@sequent.cs.qmc.ac.uk>
Date: 28 Sep 88 18:47:50 GMT
References: <4912@saturn.ucsc.edu> 
Reply-To: liam@cs.qmc.ac.uk (William Roberts)
Organization: Computer Science Dept, Queen Mary College, University of London, UK.
Lines: 59
Expires:
Sender:
Followup-To:
Distribution:

I have got 3/4 through writing a program to run on a Sun and
emulate the EtherTalk <-> KIP encapsulation work that our
Kinetics box is currently doing. As part of this effort I wrote
an analyser for the AppleTalk protocols that fly past.

I ran into a number of snags:

1) The Sun facility I am using, the Network Interface Tap (see
   man 4 nit), is somewhat odd and doesn't work properly. I
   managed to get round it though...

2) The AppleTalk protocols are not properly layered in the
   sense that you can analyse a packet out of context: anything
   on top of ATP is interpreted by the two ends and PAP/AFP are
   not distinguished by anything obvious in the headers. I
   haven't solved this, or done anything to improve on it...

Finally, it isn't as fast (Sun 3/50) as the Kinetics box
anyway, and spooling to lwsrv is VERY SLOW (effective
throughput via the K-Box is about 2000-6000 bits per second,
worse through my Sun talking to the other host).

Historical question: why can't you combine the TRel of an
XO ATP transaction with the TReq for the next?

Most of what I see is (output from the analyser):

Time   LAP        DDP skt    ATP                  ATP User
 ms      src dst    src dst    flg code bm tid   (who knows!)

59260: L 124 127 |D 253 153 |A X-- TReq 01 t547 | 02 43 00 00 | 24 bytes: 12 0e 41 46 50
60360: L 124 127 |D 253 153 |A X-- TReq 01 t547 | 02 43 00 00 | 24 bytes: 12 0e 41 46 50
62160: L 127 124 |D 153 253 |A -E- TRsp 00 t547 | 00 00 00 00 |
62160: L 124 127 |D 253 153 |A --- TRel 01 t547 | 00 00 00 00 |
62180: L 127 124 |D 153 253 |A -E- TRsp 00 t547 | 00 00 00 00 |
62280: L 124 127 |D 253 153 |A X-- TReq 01 t548 | 02 43 00 01 |
62340: L 127 124 |D 153 253 |A -E- TRsp 00 t548 | 00 00 00 00 |
62340: L 124 127 |D 253 153 |A --- TRel 01 t548 | 00 00 00 00 |
62340: L 124 127 |D 253 153 |A X-- TReq 01 t549 | 02 43 00 02 |
62400: L 127 124 |D 153 253 |A -E- TRsp 00 t549 | 00 00 00 00 |
62400: L 124 127 |D 253 153 |A --- TRel 01 t549 | 00 00 00 00 |

The next TReq often gets sent within 1ms of the previous
TRel, which is in turn less than 1ms from the TResp from the
other end (particularly in bulk protocols like AFP).

Also note that the two TReqs for t547 got answered in quick
succession (within 20ms) after a delay of nearly 3 and 2
seconds: it would probably be valuable to put timers in CAP end
(node 127 is our Kinetics box, forwarding to a Sequent Balance)
so that duplicate requests which are "too close" get ignored.

I could make the Sun code available if people want it - though
it is still somewhat raw.
-- 

William Roberts         ARPA: liam@cs.qmc.ac.uk  (gw: cs.ucl.edu)
Queen Mary College      UUCP: liam@qmc-cs.UUCP
LONDON, UK              Tel:  01-975 5250