On Sun, Jun 25, 2000 at 07:49:46PM +0200, Jochen Friedrich wrote:
> > PS: I hope it's the right place for bug reports, i've not found any info
> > on where to submit them on ethereal.zing.org.
>
> I guess, it is...
Yes, it is. The info on where to submit bugs can be found in the
"README" file for Ethereal, under "How to Report a Bug":
How to Report a Bug
-------------------
Ethereal is still under constant development, so it is possible that you will
encounter a bug while using it. Please report bugs to ethereal-dev@xxxxxxxx.
Be sure you tell us:
1) Operating System and version (the command 'uname -sr' may
tell you this, although on Linux systems it will probably
tell you only the version number of the Linux kernel, not of
the distribution as a whole; on Linux systems, please tell us
both the version number of the kernel, and which version of
which distribution you're running)
2) Version of GTK+ (the command 'gtk-config --version' will tell you)
3) Version of Ethereal (the command 'ethereal -v' will tell you,
unless the bug is so severe as to prevent that from working,
and should also tell you the versions of libraries with which
it was built)
4) The command you used to invoke Ethereal, and the sequence of
operations you performed that caused the bug to appear
If the bug is produced by a particular trace file, please be sure to send
a trace file along with your bug description. Please don't send a trace file
greater than 1 MB when compressed. If the trace file contains sensitive
information (e.g., passwords), then please do not send it.
If Ethereal died on you with a 'segmentation violation', you can help the
developers a lot if you have a debugger installed. A stack trace can be
obtained by using your debugger ('gdb' in this example), the ethereal binary,
and the resulting core file. Here's an example of how to use the gdb
command 'backtrace' to do so.
$ gdb ethereal core
(gdb) backtrace
..... prints the stack trace
(gdb) quit
$
> The crash happens because of the fixed size vb_display_string variable in
> snmp_variable_decode().
Unfortunately, "sprint_value()" does no length checking, and there's no
way to figure out how much space it will need, so the only place where
the variable *could* be variable-length is the code that formats it if
it's binary; I don't know whether it's worth having *two* variables, a
fixed-length buffer into which "format_value()" formats the string and
a pointer to a dynamically-allocated string buffer into which binary
values are dumped, or not.
> Clearly, the tree variable and the stack return address are trashed. The
> libsmi version doesn't have this problem (although somehow the decoded
> OBJECT STRING looks truncated). The length of the OBJECT STRING in the
> captured packet is 499, so to print this in binary, at least 1497 bytes
> would be needed instead of the allocated 1024...
I'll boost the buffer to 2048.
> The CVS version shows a second problem in this trace: the request packets
> are decoded with a wrong protocol type due to the source port having
> precedence over the destination port. There should be a way to override
> the automatic protocol detection if necessary.
We first need to figure out how the UI for that will work; clearly, one
doesn't want to override *all* automatic protocol detection (as you'll
then see a large pile of Ethernet/FDDI/Token Ring/... frames), so a
single switch won't work.
There are a number of possibilities:
1) the ability to "un-register" protocols (i.e., undo the
registration of a particular dissector as the dissector for a
given port and/or as a "heuristic" dissector for a given
containing protocol);
2) the ability to specify that for a particular conversation
(packets between two particular address/port pairs) the
packets should be dissected, at some particular protocol
layer, as a particular protocol;
3) perhaps others.
Most if not all of these would require infrastructure as well as UI
changes, and might also require changes to dissectors as well (e.g., the
"for a particular conversation" change would require, say, the TCP and
UDP dissectors to look for particular conversations before checking for
port numbers).
