Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

}       I would say the bug is that tftpd responds to broadcast at
}  all.  What happens if you have more then one tftpd on a network
}  segment?

	Nothing.  The initial request comes into inetd, which launches tftpd
in the usual way.  Once the session begins, the server forks and begins
serving files from ephemeral port numbers.  This patch only allows the
reception of acknowledgements on the same ephemeral port number that the
tftp server is serving from.  For example, an initial request comes in on
port 69 for the file named "foo".  The tftp server forks and begins
returning the contents of "foo" to the client, sourcing the data from port
50102.  The client then acknowledges that data by replying to the unicast
address of the server on port 50102.  This change allows the tftp server to
receive those acknowledgements on the server's unicast address, port 50102,
as well as the broadcast address, port 50102.  Any additional requests that
come in on port 69 to the server would be considered new requests and would
be handled by a new instance of the server.  It's worth noting that the
current behavior of the system would cause any tftp servers listening on
the network segment in question to respond to the initial request which
came in to the broadcast address.  However, none of them would be able to
complete the request because they are unable to communicate with the client
after the initial request is received.  

-Brian