From nobody@FreeBSD.org  Wed Jun  8 08:16:31 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 111FF106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  8 Jun 2011 08:16:31 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id DBC498FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  8 Jun 2011 08:16:30 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p588GU6h033575
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 8 Jun 2011 08:16:30 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p588GUAu033574;
	Wed, 8 Jun 2011 08:16:30 GMT
	(envelope-from nobody)
Message-Id: <201106080816.p588GUAu033574@red.freebsd.org>
Date: Wed, 8 Jun 2011 08:16:30 GMT
From: Barry Mishler <barry_mishler@yahoo.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: tftpd in 8.2-RELEASE expects more data after EOF
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         157700
>Category:       bin
>Synopsis:       tftpd(8) in 8.2-RELEASE expects more data after EOF
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 08 08:20:13 UTC 2011
>Closed-Date:    
>Last-Modified:  Thu Jun 09 02:41:18 UTC 2011
>Originator:     Barry Mishler
>Release:        8.2-RELEASE-p2
>Organization:
>Environment:
FreeBSD zn120.usace.army.mil 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #3: Fri Jun  3 09:13:34 JST 2011     root@zn120.usace.army.mil:/usr/obj/usr/src/sys/MYKERNEL  i386
>Description:
The new tftpd appears to want one more packet following the last (short) packet when receiving a file.  It waits 5 seconds before timing out and finishing up.  This causes a (5-second) delay in flushing the received file to the filesystem which makes other software think that the received file is empty.

At the very bottom of the tftp_receive function in tftp-transfer.c, the controlling 'while' loop continues as long as the received packet matches the expected segment size (n_data == segsize).  But after receiving a small (final) packet, the loop exits but still calls receive_packet one last time.  The comment implies that it's doing "late packet management".

>How-To-Repeat:
Copy a file from a tftp client and watch the file be empty for 5 seconds after the transfer completes.

I use an Expect script to copy Cisco configurations to a FreeBSD tftp server.  After that script finishes copying the file and logging off the device, I watch the size of the file...

./3750 3750-1 10.100.254.120 && for i in 1 2 3 4 5 6; do ls -l 3750-1.*; sleep 1; done

spawn cisco-login 3750-1
spawn ssh -l user 3750-1

3750-1>enable
Password:
3750-1#copy running-config tftp:
Address or name of remote host []? 10.100.254.120
Destination filename [3750-1-confg]? cfg/3750-1.running
!!
10482 bytes copied in 0.805 secs (13021 bytes/sec)
3750-1#copy startup-config tftp:
Address or name of remote host []? 10.100.254.120
Destination filename [3750-1-confg]? cfg/3750-1.startup
!!
10579 bytes copied in 0.059 secs (179305 bytes/sec)
3750-1#
Script Completed
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.startup
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.startup
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.startup
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  0 Jun  8 16:47 3750-1.startup
-rwxrwxrwx  1 root  wheel  10482 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  10579 Jun  8 16:47 3750-1.startup
-rwxrwxrwx  1 root  wheel  10482 Jun  8 16:47 3750-1.running
-rwxrwxrwx  1 root  wheel  10579 Jun  8 16:47 3750-1.startup

>Fix:
Don't know exactly.  The code is so new and clean that I wouldn't presume to suggest my own patch that would just make a mess and cause problems elsewhere.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Jun 9 02:40:15 UTC 2011 
Responsible-Changed-Why:  
Fix up and assign. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157700 
>Unformatted:
