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

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

The following reply was made to PR bin/49868; it has been noted by GNATS.

From: Brian Buhrow <buhrow%nfbcal.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: buhrow%nfbcal.org@localhost
Subject: Re: bin/49868: tftpd(8) doesn't play well with clients that return acknowledgements to the broadcast address
Date: Thu, 30 Apr 2015 12:15:39 -0700

 }       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