[Guy Harris <gharris@xxxxxxxxxxxx>]

On Wed, Dec 27, 2000 at 11:53:25PM +0800, jonathan wrote:
> Thanks for the patch. I tried it out and got the same results. A couple of
> questions - if the frames are badly formed, what does that mean?

It means that Cisco are sending out packets that don't contain what RFC
1350 says they should.

> And more importantly, how can I remedy the situation ?

Call up Cisco and say

	I have a network trace in which one of your IP telephones sends
	out a TFTP Read Request packet that's 20 bytes long (the IP
	header says the total length of the packet is 48 bytes, the IP
	header is 20 bytes long, and the UDP header is 8 bytes long,
	leaving 20 bytes of TFTP).

	The first 2 bytes of those 20 bytes are the TFTP opcode.

	The next 11 bytes are the file name, "OS79XX.TXT", including a 0
	byte at the end.

	The next 6 bytes are the mode, "octet", including a 0 byte at
	the end.

	That's 2+11+6 bytes, or 19 bytes.

	This leaves an extra byte at the end, which is 0.

	RFC 2347, "TFTP Option Extension", says that "options are
	appended to a TFTP Read Request or Write Request packet as
	follows", and says that the options are just put after the end
	of the mode string; options are null-terminated strings, and an
	option consists of an option name string followed by an option
	value string.

	This means that the extra 0 byte is to be interpreted as a
	zero-length option name string; there is nothing in RFC 2347 to
	indicate that the end of the options is to be indicated by a
	zero-length string - the end of the options can be determined by
	the length of the TFTP Read Request or the TFTP Write Request
	packet.

	It seems unlikely that an option would have a zero-length name;
	furthermore, there is no value string for this option.

	Thus, it appears that the firmware in your phone has a bug.

	TFTP servers *might* be robust enough to ignore the extra 0
	byte, but it's probably better not to put that byte into your
	TFTP Read Request Packets.

and then wait for them to update the firmware in your phone with a fix
to remove the extra 0 byte.

>    I have some problems again with the format specified by RFC 1350 and
> the tftp output results that ethereal is giving me. This time it is with
> the data packet. The format for the data packet is :
> 
> 
>           2 bytes    2 bytes       n bytes
>           ---------------------------------
>    DATA  | 03    |   Block #  |    Data    |
>           --------------------------------
> 
> However, the results from the ethereal trace indicate that this is not the
> format of the IP phone tftp packets. 

Perhaps it isn't, and perhaps it is.

What happens if you select the "Trivial File Transfer" line in the
second pane of the display?  Does it highlight the "79XX.TXT" stuff, or
anything after it?

What happens if you "open up" the "Ethernet II" section in the second
pane?  Does it show a "Trailer:" section?

If the answer to the first question is "no" (i.e., it doesn't highlight
the "79XX.TXT" stuff or anything after it), and the answer to the second
question is "yes" (i.e., it does show a "Trailer:" section), what
happens if you select the "Trailer:" item?  Does *that* highlight the
"79XX.TXT" stuff and the stuff after that?

If so, then

	1) the format of the TFTP data packet *is* the format described
	   above;

	2) the extra stuff at the end is *not* part of the TFTP data
	   packet; it's not even part of the UDP or IP packet, it's an
	   Ethernet trailer.

Ethernet packets must be a minimum of 60 bytes of data (plus 4 bytes of
CRC, which probably don't show up in your capture file).  What goes into
the padding area depends on what the software/firmware that generates
the packet decides to put there; it might just be whatever junk happened
to be in that region of memory in a previous packet.