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 SysMgr 
Newsgroups: 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]