Ethereal-dev: Re: [Ethereal-dev] Potential bug decoding a UDP packet (it thinks it's TFTP, it'
On Sat, Apr 20, 2002 at 03:34:10PM -0700, Ben Greear wrote:
> I'm using ethereal to diagnose my module, and I noticed an wierd
> thing. After the destination port got to TFTP's port number, every
> packet after that was decoded as TFTP too, even though the ports
> kept increasing.
To quote the comment in the beginning of the TFTP dissector:
/*
* The first TFTP packet goes to the TFTP port; the second one
* comes from some *other* port, but goes back to the same
* IP address and port as the ones from which the first packet
* came; all subsequent packets go between those two IP addresses
* and ports.
*
* If this packet went to the TFTP port, we check to see if
* there's already a conversation with one address/port pair
* matching the source IP address and port of this packet,
* the other address matching the destination IP address of this
* packet, and any destination port.
*
* If not, we create one, with its address 1/port 1 pair being
* the source address/port of this packet, its address 2 being
* the destination address of this packet, and its port 2 being
* wildcarded, and give it the TFTP dissector as a dissector.
*/
It might be possible to have the second packet change the conversation
to be between the two addresses and ports. We don't know the server
port for the rest of the TFTP converstaion until we see the reply to the
first port, however, so if we *don't* see a reply, there's nothing we
can do about it, short of not dissecting TFTP, which would be a Bad
Thing.
This means that if a program sends a UDP packet, from IP address X, UDP
port A, to IP address Y, port 69, and nothing running on port 69
replies, all subsequent UDP packets to or from IP address X/UDP port A
from or to IP address Y will be dissected as TFTP, unless you disable
the TFTP dissector from the "Edit->Protocols" menu item.
