Kurt Schroeder wrote:
Ethereal seems very good at quickly showing a capture file as ASCII in the
Follow TCP stream window, but clicking on EBCDIC seems to hang Ethereal on
my PC. It takes LOTS of CPU using only very small (1-2 MB traces.)
If it truly hangs, it takes an infinite amount of CPU; do you mean that
it hangs (loops forever, no matter how long you wait), or just that it
takes a really long time to complete?
I was told in a reply that the trace files are neither ASCII nor EBCDIC,
but instead are raw binary data. If that's true,
It is entirely true. Trace files (in Ethereal's native format, libpcap
format, as used originally in tcpdump, but other formats are similar)
have a per-file header followed by a sequence of packets, each of which
has a per-packet header giving time stamp and packet length information
followed by the raw bytes of the packet as supplied by the packet
capture mechanism.
Ethereal seems to be WAY
better at rendering ASCII than it is at rendering EBCDIC.
Ethereal renders the text of a TCP stream using a GTK+ text widget;
given that Ethereal is running on an OS whose native character set is
ASCII (I know of no OS/390 or zOS port, or ports to other OSes that use
EBCDIC; it runs on ASCII UN*Xes and Windows), that widget's native
character set is ASCII, not EBCDIC.
Rendering ASCII text means checking for non-printable characters and
showing them as ".", and showing printable characters as themselves.
Rendering EBCDIC text means translating EBCDIC characters into their
ASCII equivalents and then doing the above.
In addition, Ethereal's default display format for TCP streams is ASCII,
so to display as EBCDIC requires a redisplay. For a large stream,
clearing the text widget before inserting the new text can take a
significant amount of time (for a 6.6Mb stream, it took about 6.4
seconds on my 1.5MHz PowerPC-based UNIX workstation). In addition, it
appears it does that *twice*.
The difference in time between displaying ASCII and displaying EBCDIC is
a lot bigger than I'd naively expect from the table lookup used for the
translation; there might be ways to improve it. Not processing the
stream twice would probably help as well.
It's still not going to be *as* fast, as it has to map from the
non-native EBCDIC character set to the native ASCII character set.
