wjdh@ciba-geigy.ch (Jean Daniel Horner) (06/04/91)
We are desparately looking for protocol analyzing equipment able to analyze ISO/CCITT protocol stacks (e.g. x.400 email, ftam, virtual terminal, x.500 directory services). as interfaces we need serial and ethernet as well as tokenring. who knows a good product??? what we found up to now with iso capabilities is: hp: 4972 analyzer (iso software end 91 begin 92, ethernet only) tekelec: chamaeleon (WAN only, x400) Wandel+Goltermann: DA-30 (iso software end 91 begin 92, LAN+WAN) thank you for hints armin schweizer
joerg@bdc.ubc.ca (Joerg Messer) (06/04/91)
Please remove me from this list. Thanks. Joerg Messer | Email: joerg@bdc.ubc.ca Department of Zoology | joerg@nexus.bdc.ubc.ca (NeXT) University of British Columbia | Phone: 604-228-6527 Vancouver, Canada, V6T 1W5 | Fax: 604-228-2416
ggm@brolga.cc.uq.oz.au (George Michaelson) (06/04/91)
wjdh@ciba-geigy.ch (Jean Daniel Horner) writes: >We are desparately looking for protocol analyzing equipment >able to analyze ISO/CCITT protocol stacks (e.g. x.400 email, >ftam, virtual terminal, x.500 directory services). as >interfaces we need serial and ethernet as well as tokenring. >who knows a good product??? For low-layer protocol elements I have no information. for transport and above, You should consider using an OSI programming suite like RETIX or ISODE. This allows you to do complete PDU tracing of the input and output dataflow. For pre-defined cases it is fairly easy (if time consuming) to construct drivers to put you into known states and watch dataflow, certainly to debug connection phase activity this approach is valid. (I did this to debug some problems connecting to X.400 services between two implementations: set ISODE to accept the TSEL and X.25 address and debug all the OSI stacktrace up until an application specific exchange, reveals quite a lot about whats being done. post-connection this model breaks down, but with an application written to match and using ISODE you can always use IT as a test driver and monitor the flow all the way) In the case of ISODE it is also free. In other words, split the requirement into two parts at the network/transport layer boundary, and approach each separately. Debugging applications like X.400 and X.500 and FTAM is not best done in a standalone box like a network analyzer, you want almost limitless diskspace (for traces and PDU dis-assembly) and a programming library to construct the test drivers. There are OSI standards that cover the test suites and testing process for these applications. There are also bodies like COS which offer service testing conformance in applications. If you are buying off-the-shelf software in these areas, you should consider asking what interoperability and other testing has already been undertaken. -If the application in question has been tested against many others, but fails on your platform, it points to other failures such as the lower network stack, or operating system dependencies. -george -- George Michaelson G.Michaelson@cc.uq.oz.au The Prentice Centre | There's no market for University of Queensland | hippos in Philadelphia Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht