Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!decvax!genrad!teddy!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@csnet-relay.arpa From: BostonU SysMgrNewsgroups: net.unix-wizards Subject: TFTP bug? Message-ID: <6857@brl-tgr.ARPA> Date: Mon, 31-Dec-84 03:03:58 EST Article-I.D.: brl-tgr.6857 Posted: Mon Dec 31 03:03:58 1984 Date-Received: Tue, 1-Jan-85 06:02:50 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 38 This is probably only of interest to those few TFTP users (4.2bsd.) I was getting up an implementation of tftp (server) on a workstation and having trouble. Putting a trace at the UDP level indicated that, when sending a file to 4.2, ACKs were being sent to 'well-known' socket 69 although the server was expecting only the initial request on 69 and the rest on a newly generated socket. I consulted RFC783 and pages 7-8 speak of similar behavior with sending the initial connection request on 69 and the rest on a 'randomly' generated 'TID' so I made the following change to /usr/src/ucb/tftp.c: in recvfile(): if(firsttrip) { ... } else { sin.sin_port = from.sin_port ; /* add this line */ and it all now works. The question is, who was right? My suspicion is the workstation was right so this is a bug report but I guess I wanted a little reassurance as it does not seem obvious. -Barry Shein, Boston University P.S. I am aware of the security problems with tftp (and you should be too before you use it) In fact, I added a -s flag for 'secure' which demands that file names in request packets come in with a valid username/password (which creates new potential problems) and performs the reasonable setuid/setgid/chdir. [in our server tftpd's that is]