ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-users: [Ethereal-users] Ethereal crashes

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Charles Elliott" <elliott.ch@xxxxxxxxxxx>
Date: Sat, 1 Feb 2003 20:36:40 -0500
Hello:

	Ethereal and especially Tethereal have been of enormous help to me in
attempting to solve various problems, and they have helped satisfy my
curiosity as to what is going on "under the hood" in networking, so please
don't take this message as criticism, but as feedback.

	My problem is that I wrote a distributed processing application in Java
just to test the usability of the Java RMI facility for parallel processing.
The program splits the generation of a fractal into screen columns, sends
commands to ten slave computers to generate the fractal for certain screen
columns, and receives the results and displays them on the screen.  The
program generates an enormous amount of network traffic, and it fails every
time within a few seconds.  I tried to use both Ethereal and Tethereal to
capture the TCP traffic so I could see what was wrong.  Tethereal worked
well on the slaves, but Ethereal bombed out every time; I am not sure why,
but the file generated was always corrupted and unreadable after only a few
seconds.

	When the master is receiving results it gets hundreds of packets every few
seconds.  Ethereal crashed immediately when run on the master every time.
However, Tethereal would run for a few seconds and then crash with a stack
overflow error.  I am attaching the Dr Watson log for one of these crashes.
If there is anything I can do to help debug Tethereal or Ethereal, please
don't hesitate to ask.

Charles Elliott
316 East Cambria Street
Philadelphia, PA 19134-3324

Work: (215) 425-5222
Mobile: (267) 242-9845
Pager: (215) 213-0015
elliott.ch@xxxxxxxxxxx


P.S.  If you are at all interested, RMI crashes because every time one of
the slaves sends out about ten packets asking for the location of the PDC,
the master resets the connection to that slave.  Whenever the master sends
out the packets asking for the PDC, the slaves get a TCP ACK packet with the
wrong sequence number and just die.

Attachment: drwtsn32.log
Description: Binary data