On Sun, Dec 24, 2000 at 06:25:44PM +0800, jonathan wrote:
> I am using version 0.8.14. Thanks for the pointer to the TFTP options
> RFC. However, the hex. display (which ethereal produces) still doesnt
> map, even if I consider the 'options' RFC. The hex output maps to
> the etherenet header-ip header-udp header-tftp packet. So i can't see
> where Ethereal is getting the information about the options from.
The packet displayed in the first scree dump has an extra 00 at the end
of the hex data, right after the trailing 00 at the end of the string
saying "octet" in the type field.
If that's truly part of the IP datagram, then it would lead a dissector
- or a TFTP server! - to conclude that the read request has options in
it; however, the option name is empty, and the option value is absent,
so the frame appears to be malformed.
As in my earlier mail, this could cause Ethereal to try to read the
non-existent option value, which, according to RFC 2347, would come
after the zero-length option name that is the extra 00 at the end;
however, if it were to do so, it wouldn't be getting it from anywhere in
the packet (so it wouldn't show up in the hex display), it'd come from
whatever happens to be in Ethereal's address space following the packet
data, which is probably data from another packet in the capture.
However, 0.8.14 should be getting an exception from the tvbuff code if
it tried to do that, so either the tvbuff code isn't doing the right
checks, or the routines being used are ones not specified as throwing
exceptions.
The capture file itself would be useful for debugging this; I might be
able to synthesize a trace with such a packet, by writing a program (or
throwing a temporary hack into editcap) and running it on a TFTP capture
I have, but I can't guarantee that this would reproduce the Ethereal bug
you're seeing.