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