Bug 157700

Summary: tftpd(8) in 8.2-RELEASE expects more data after EOF
Product: Base System Reporter: Barry Mishler <barry_mishler>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me CC: asomers
Priority: Normal    
Version: 8.2-RELEASE   
Hardware: Any   
OS: Any   

Description Barry Mishler 2011-06-08 09:20:13 UTC
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".

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.
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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-06-09 03:40:15 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-bugs

Fix up and assign.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:14 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 3 commit-hook freebsd_committer freebsd_triage 2018-03-09 15:30:55 UTC
A commit references this bug:

Author: asomers
Date: Fri Mar  9 15:30:20 UTC 2018
New revision: 330696
URL: https://svnweb.freebsd.org/changeset/base/330696

Log:
  Add some functional tests for tftpd(8)

  tftpd(8) is difficult to test in isolation due to its relationship with
  inetd.  Create a test program that mimics the behavior of tftp(1) and
  inetd(8) and verifies tftpd's response in several different scenarios.

  These test cases cover all of the basic TFTP protocol, but not the optional
  parts.

  PR:		157700
  PR:		225996
  PR:		226004
  PR:		226005
  MFC after:	3 weeks
  Differential Revision:	https://reviews.freebsd.org/D14310

Changes:
  head/libexec/tftpd/Makefile
  head/libexec/tftpd/tests/
  head/libexec/tftpd/tests/Makefile
  head/libexec/tftpd/tests/functional.c
Comment 4 commit-hook freebsd_committer freebsd_triage 2018-03-09 23:25:56 UTC
A commit references this bug:

Author: asomers
Date: Fri Mar  9 23:25:19 UTC 2018
New revision: 330710
URL: https://svnweb.freebsd.org/changeset/base/330710

Log:
  tftpd: Flush files as soon as they are fully received

  On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
  Instead, it waits five seconds just in case the client didn't receive the
  server's last ACK and decides to resend the final DATA packet.
  Unfortunately, this created a 5 second delay from when the client thinks
  it's done sending the file, and when the file is available for other
  processes.

  Fix this bug by closing the file as soon as receipt is finished.

  PR:			157700
  Reported by:		Barry Mishler <barry_mishler@yahoo.com>
  MFC after:		3 weeks

Changes:
  head/libexec/tftpd/tests/functional.c
  head/libexec/tftpd/tftp-transfer.c
  head/libexec/tftpd/tftpd.c
  head/usr.bin/tftp/tftp.c
Comment 5 commit-hook freebsd_committer freebsd_triage 2018-04-16 16:32:28 UTC
A commit references this bug:

Author: asomers
Date: Mon Apr 16 16:32:01 UTC 2018
New revision: 332608
URL: https://svnweb.freebsd.org/changeset/base/332608

Log:
  MFC r330696, r330709, r330742, r331358

  r330696:
  Add some functional tests for tftpd(8)

  tftpd(8) is difficult to test in isolation due to its relationship with
  inetd.  Create a test program that mimics the behavior of tftp(1) and
  inetd(8) and verifies tftpd's response in several different scenarios.

  These test cases cover all of the basic TFTP protocol, but not the optional
  parts.

  PR:		157700
  PR:		225996
  PR:		226004
  PR:		226005
  Differential Revision:	https://reviews.freebsd.org/D14310

  r330709:
  Commit missing file from r330696

  X-MFC-With:	330696

  r330742:
  tftpd: fix the build of tests on i386 after 330696

  It's those darn printf format specifiers again

  Reported by:	cy, kibab
  X-MFC-With:	330696

  r331358:
  tftpd: misc Coverity cleanup in the tests

  A bunch of unchecked return values from open(2) and read(2)

  Reported by:	Coverity
  CID:		1386900, 1386911, 1386926, 1386928, 1386932, 1386942
  CID:		1386961, 1386979
  X-MFC-With:	330696

Changes:
_U  stable/11/
  stable/11/etc/mtree/BSD.tests.dist
  stable/11/libexec/tftpd/Makefile
  stable/11/libexec/tftpd/tests/
  stable/11/libexec/tftpd/tests/functional.c
Comment 6 commit-hook freebsd_committer freebsd_triage 2018-04-16 16:34:42 UTC
A commit references this bug:

Author: asomers
Date: Mon Apr 16 16:33:36 UTC 2018
New revision: 332609
URL: https://svnweb.freebsd.org/changeset/base/332609

Log:
  MFC r330710, r330718-r330720

  r330710:
  tftpd: Flush files as soon as they are fully received

  On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
  Instead, it waits five seconds just in case the client didn't receive the
  server's last ACK and decides to resend the final DATA packet.
  Unfortunately, this created a 5 second delay from when the client thinks
  it's done sending the file, and when the file is available for other
  processes.

  Fix this bug by closing the file as soon as receipt is finished.

  PR:			157700
  Reported by:		Barry Mishler <barry_mishler@yahoo.com>

  r330718:
  tftpd: Verify world-writability for WRQ when using relative paths

  tftpd(8) says that files may only be written if they already exist and are
  publicly writable.  tftpd.c verifies that a file is publicly writable if it
  uses an absolute pathname.  However, if the pathname is relative, that check
  is skipped.  Fix it.

  Note that this is not a security vulnerability, because the transfer
  ultimately doesn't work unless the file already exists and is owned by user
  nobody.  Also, this bug does not affect the default configuration, because
  the default uses the "-s" option which makes all pathnames absolute.

  PR:		226004

  r330719:
  tftpd: Abort on an WRQ access violation

  On a WRQ (write request) tftpd checks whether the client has access
  permission for the file in question.  If not, then the write is prevented.
  However, tftpd doesn't reply with an ERROR packet, nor does it abort.
  Instead, it tries to receive the packet anyway.

  The symptom is slightly different depending on the nature of the error.  If
  the target file is nonexistent and tftpd lacks permission to create it, then
  tftpd will willingly receive the file, but not write it anywhere.  If the
  file exists but is not writable, then tftpd will fail to ACK to WRQ.

  PR:		225996

  r330720:
  tftpd: reject unknown opcodes

  If tftpd receives a command with an unknown opcode, it simply exits 1.  It
  doesn't send an ERROR packet, and the client will hang waiting for one.  Fix
  it.

  PR:		226005

Changes:
_U  stable/11/
  stable/11/libexec/tftpd/tests/functional.c
  stable/11/libexec/tftpd/tftp-transfer.c
  stable/11/libexec/tftpd/tftpd.c
  stable/11/usr.bin/tftp/tftp.c
Comment 7 commit-hook freebsd_committer freebsd_triage 2018-08-03 14:14:12 UTC
A commit references this bug:

Author: asomers
Date: Fri Aug  3 14:13:16 UTC 2018
New revision: 337246
URL: https://svnweb.freebsd.org/changeset/base/337246

Log:
  MFC r330696, r330709, r330742, r331358

  r330696:
  Add some functional tests for tftpd(8)

  tftpd(8) is difficult to test in isolation due to its relationship with
  inetd.  Create a test program that mimics the behavior of tftp(1) and
  inetd(8) and verifies tftpd's response in several different scenarios.

  These test cases cover all of the basic TFTP protocol, but not the optional
  parts.

  PR:		157700
  PR:		225996
  PR:		226004
  PR:		226005
  Differential Revision:	https://reviews.freebsd.org/D14310

  r330709:
  Commit missing file from r330696

  X-MFC-With:	330696

  r330742:
  tftpd: fix the build of tests on i386 after 330696

  It's those darn printf format specifiers again

  Reported by:	cy, kibab
  X-MFC-With:	330696

  r331358:
  tftpd: misc Coverity cleanup in the tests

  A bunch of unchecked return values from open(2) and read(2)

  Reported by:	Coverity
  CID:		1386900, 1386911, 1386926, 1386928, 1386932, 1386942
  CID:		1386961, 1386979
  X-MFC-With:	330696

Changes:
_U  stable/10/
  stable/10/etc/mtree/BSD.tests.dist
  stable/10/libexec/tftpd/Makefile
  stable/10/libexec/tftpd/tests/
  stable/10/libexec/tftpd/tests/functional.c
Comment 8 commit-hook freebsd_committer freebsd_triage 2018-08-03 14:17:23 UTC
A commit references this bug:

Author: asomers
Date: Fri Aug  3 14:17:12 UTC 2018
New revision: 337247
URL: https://svnweb.freebsd.org/changeset/base/337247

Log:
  MFC r330710:

  tftpd: Flush files as soon as they are fully received

  On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
  Instead, it waits five seconds just in case the client didn't receive the
  server's last ACK and decides to resend the final DATA packet.
  Unfortunately, this created a 5 second delay from when the client thinks
  it's done sending the file, and when the file is available for other
  processes.

  Fix this bug by closing the file as soon as receipt is finished.

  PR:			157700
  Reported by:		Barry Mishler <barry_mishler@yahoo.com>

Changes:
  stable/10/libexec/tftpd/tests/functional.c
  stable/10/libexec/tftpd/tftp-transfer.c
  stable/10/libexec/tftpd/tftpd.c
  stable/10/usr.bin/tftp/tftp.c