q3k/khepri-tftpy
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Get rid of stupid shit.

Browse source
This commit is contained in:
q3k 2012-11-14 12:53:40 +01:00
parent 3e0a967133
commit e814174d7b
39 changed files with 0 additions and 6367 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
COPYING
View file

@ -1,21 +0,0 @@
The MIT License
Copyright (c) 2009 Michael P. Soulier
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

273
ChangeLog
View file

@ -1,273 +0,0 @@
2011-07-24 Michael P. Soulier
04aaa2e: Fixing issue #3, expanding unit tests.
2011-07-23 Michael P. Soulier
40977c6: Fixing some pyflakes complaints
add4440: Fixes issue #23, breaking up TftpStates into TftpStates and TftpContexts.
949c998: Fixing issue #9, removing blksize option from client if not supplied.
a43773e: Fixing issue #16 on github, server failing to use timeout time in checkTimeout() method.
1e74abf: Adding retries on timeouts, still have to exhaustively test. Should close issue #21 on github.
2011-06-02 Michael P. Soulier
6fd9391: Fixing a file descriptor leak. Closes issue 22.
f6442eb: Adding a server download state test to the unit tests.
2010-10-18 Kenny Millington
a6cff4f: Fix exceptions propagating out of TftpServer.listen()
71d827d: Allow dyn_file_func to trigger a FileNotFound error.
2010-10-13 Michael P. Soulier
4396124: Forcing decode mode to lower case, fixes bug 17.
2010-07-20 Michael P. Soulier
45185ed: Fixing setNextBlock to roll over at 2**16 - 1 instead of 2**16, which was causing problems when uploading large files.
2010-07-14 Michael P. Soulier
e1b1be2: Updating README for 0.5.1
4f61f7f: Updated changelog for 0.5.1.
e35cd2d: Added simple doc examples and install info.
2010-07-12 Michael P. Soulier
74f6756: Playing with sphinx formatting
2010-07-11 Michael P. Soulier
1caa220: Latest doc updates
ad94976: Replacing epydoc output on website.
402b2ae: Adding initial Sphinx docs
2010-05-25 Michael P. Soulier
0b54068: Fixing typo in unit test
58623df: Adding support for input/output as stdin/stdout
2010-05-24 Michael P. Soulier
f4a3ff6: Fixing failure to set default blocksize if options were provided but blksize was not one of them.
2010-05-12 Patrick Oppenlander
1a2b556: fix incorrectly assigned state transition
360b0b9: fix divide by zero in speed calculation for short transfers
2010-05-10 Michael P. Soulier
3c40546: Updated site html formatting
9ed42a8: Website update
5f0e405: Updating notes
d4c15e1: Fixing the license in the setup.py
2f0c0db: Updated website
becb299: Updating metadata for 0.5.0 release
faebd44: Fixing buffering issue in upload. Uploads work now.
a071549: Updated README
2bb8326: First working upload with new state machine. Not usable yet, upload fails to always send all data for some reason.
4a4f53a: Fixed an obvious error introduced with the dyn_file_func merge
2010-04-24 Michael P. Soulier
8a56d94: Merge commit 'angry-elf/master' into merge
2010-02-18 Michael P. Soulier
8343ccf: Taking patch from "Mike C. Fletcher" <mcfletch@vrplumber.com>, fixing a bad reference to dyn_func_file from a state object.
2010-02-18 Alexey Loshkarev
72c4769: Fix dyn_file_func (was broken?) Fix error message (filename was not displayed)
2009-10-24 Michael P. Soulier
badf18f: Updated epydoc output for website.
2009-09-24 Michael P. Soulier
a80639c: Changed licenses to the MIT License
ce7fc32: Fixing some log messages and bad variable references.
2009-08-18 Michael P. Soulier
781072b: Updated resent_data in metrics.
3ae3b31: Fixed server metrics summary.
2009-08-16 Michael P. Soulier
a6a18c1: First successful download with both client and server.
2009-08-15 Michael P. Soulier
62b22fb: Did some rework for the state machine in a server context. Removed the handler framework in favour of a TftpContextServer used as the session.
2009-06-20 Michael P. Soulier
03e4e74: Fixing up some of the upload code.
2009-07-21 Michael P. Soulier
5ee5f63: Adding patch for dynamic content from Alex ? <yix@ya.ru>
2009-04-10 Michael P. Soulier
c61ca17: Fixing a merge error in rebase
410e14c: Fixed bug in tidport handling, and lack of OACK response.
874fef5: Fixing OACK handling with new state machine.
5072f6d: Fixed TftpClient with new state machine.
2009-04-08 Michael P. Soulier
e7a63bb: Started overhaul of state machine.
2009-04-10 Michael P. Soulier
41bf3a2: Improving sample client output on error and fixing default blocksize when server ignores options.
bd2e195: Merged upload patch.
2009-04-09 Michael P. Soulier
449f10a: Updating version in setup
2009-04-08 Michael P. Soulier
40185e5: Website update
2009-04-07 Michael P. Soulier
bc55a17: Fixing bogus warnings in options handling.
74c68b1: Merge branch 'master' of git@github.com:msoulier/tftpy
d058642: Fixing tftproot configured for server as a relative path.
2009-03-15 Michael P. Soulier
23b32d0: Updated site with stylesheet
0cfcea2: Website update
2009-03-14 Michael P. Soulier
abf0f1f: Adding website
2008-10-08 Michael P. Soulier
ca7a06a: Fixed the use of the tsize option in RRQ packets.
2008-10-05 Michael P. Soulier
0a5df33: Rolling 0.4.6
2008-10-04 Michael P. Soulier
07416bf: Rebased tsize branch and added a --tsize option to the client. Now sending all packets to the progresshook, not just DAT packets, so that the client can see the OACK. Not yet making use of the returned tsize. Need to test this on a server that supports tsize.
2008-07-30 Michael P. Soulier
8a0162b: Adding transfer size option patch from Kuba Kończyk. Patch 2018609 in SF tracker.
2008-10-03 Michael P. Soulier
c408389: Merged from SVN trunk after register to PyPi
2008-10-04 msoulier
65ef2d9: Updated for PyPi
2008-07-30 Michael P. Soulier
6730280: Adding upload patch from Lorenz Schori - patch 1897344 in SF tracker
2008-05-28 msoulier
33b1353: Tagging 0.4.5.
936e4df: Updated for v0.4.5 release.
caff30d: Fix for bug 1967647, referencing self.sock instead of sock.
2008-05-20 msoulier
70f22b1: Fix for [ 1932310 ] security check always fail for windows.
596af40: Fixed division by zero error in rate calculations in download function of client. Thanks to Stefaan Vanheesbeke for the report.
3b1bae3: Fix for bug [ 1932330 ] binary downloads fail in Windows.
2008-01-31 msoulier
648564c: Updated README.
792df2d: Updated ChangeLog
941f5bf: Updating version to 0.4.4
2007-12-16 msoulier
f8af287: Fixing 1851544 - server not tolerant of unsupported options Thanks to Landon Jurgens for the report.
2007-07-17 msoulier
89a8382: Updated for 0.4.3 release.
2007-07-16 msoulier
2a98d72: Removed redundant comparison.
955ced3: Fixing string/integer comparison. Thanks to Simon P. Ditner, bug #1755146.
2007-06-05 msoulier
493dcac: Updated for 0.4.2
bb47795: Fixed unit test for factory
2007-03-31 msoulier
d9665e1: Updating docs for epydoc.
b68ceca: Updated build process.
d8730c7: Adding epydoc target.
2007-03-15 msoulier
0b41ffb: Updated ChangeLog
2007-02-23 msoulier
8f5595c: Simplifying use of optparse. Thanks to Steven Bethard for the suggestions.
2007-02-17 msoulier
5c52975: Removed mention of sorceror's apprentice problem.
c8df0fd: Rearranged packaging a bit to fix an importing problem.
c7d86d3: Supplying a default blksize options in the server. Fix for 1633625.
2007-02-10 msoulier
07906cd: Added a check for rogue packets in the server.
2007-02-09 msoulier
f53e68b: Making the lib backwards-compatible to Python 2.3.
2006-12-17 msoulier
efd248f: Rolling to version 0.4.1.
95b6a72: Restructuring single lib into a package.
a1ad552: Restructuring single lib into a package.
c43a24c: Restructuring single lib into a package.
5e6d8fe: Restructuring single lib into a package.
6eb1501: Fixing install location of library.
2006-12-16 msoulier
15023eb: Added server to package.
ac2faa3: Updated ChangeLog, and rolled version to 0.4
2006-12-15 msoulier
f79a1e9: Making server exit gracefully.
16ebbf2: Tweak to EOF handling in server.
7723705: First working server tests with two clients.
5cfbae3: Added lots in the server to support a download, with timeouts. Not yet tested with a client, but the damn thing runs.
d5b7276: Fixed a bug in handling block number rollovers.
2006-12-14 msoulier
7441f0a: Got handling of file not found working in server.
3b4d177: Starting on sample server.
94ef067: Successful test on basic select loop
2006-12-11 msoulier
6f186f2: Added some security checks around the tftproot. Further fleshed-out the handler. Still not actually starting the transfer.
2006-12-10 msoulier
b5a96ec: Fleshing out server handler implementation.
fc2a587: Started on the server
2006-12-09 msoulier
aece5aa: Added --debug option to sample client.
204cce4: Adding license
4fc510b: Adding ChangeLog
07e2976: Bumped the version.
104dfe0: Changed the port variables to something more intelligent.
15c5a0f: Fixing poor TID implementation.
2006-10-25 msoulier
8e6cd77: Added testcase for TftpPacketFactory.
2006-10-13 msoulier
7486502: Implemented retries on download timeouts.
0528b1b: Added some info statements regarding option negotiation.
4c73041: Updated testcases, fixed one error in decode_options
2006-10-11 msoulier
f2b7d5d: Updated testcases
837344c: Updated makefile
08af50a: Adding makefile
2006-10-10 msoulier
99b3bbd: Moved LICENSE to COPYING
2006-10-09 msoulier
2e42f99: Added test for WRQ packet
6ebd6fc: Fixed broken decode, and adjusted the client options.
2006-10-08 msoulier
6db1b2c: Starting on unit tests
2006-10-05 msoulier
e771f67: Fixed handling of port
cb75a4b: Updating for production
19e8f0f: Freezing 0.2
0a13eb5: Fixed poor EOF detection
ed15161: Got variable blocksizes working.
2006-10-04 msoulier
c24bba2: Added confirmation of incoming traffic to known remote host.
c11ac3a: Restructured in preparation for tftp options
2827cf1: Updated README
c6094b0: Updated README
09de253: Added seconds to logs
82821e5: Upping version to 0.2
88c387b: Added OACK packet, and factored-out client code.

3
MANIFEST.in
View file

@ -1,3 +0,0 @@
include LICENSE
include ChangeLog
include COPYING

16
Makefile
View file

@ -1,16 +0,0 @@
PY=/usr/bin/env python
PYTHONPATH=.
all: test sdist
sdist:
PYTHONPATH=$(PYTHONPATH) $(PY) setup.py sdist
test:
PYTHONPATH=$(PYTHONPATH) $(PY) t/test.py
clean:
rm -rf dist src tftpy-doc* MANIFEST
flakes:
pyflakes bin/*.py tftpy/*.py

106
README
View file

@ -1,106 +0,0 @@
Copyright, Michael P. Soulier, 2010.
About Release 0.6.0:
====================
Maintenance update to fix several reported issues, including proper
retransmits on timeouts, and further expansion of unit tests.
About Release 0.5.1:
====================
Maintenance update to fix a bug in the server, overhaul the documentation for
the website, fix a typo in the unit tests, fix a failure to set default
blocksize, and a divide by zero error in speed calculations for very short
transfers.
Also, this release adds support for input/output in client as stdin/stdout
About Release 0.5.0:
====================
Complete rewrite of the state machine.
Now fully implements downloading and uploading.
About Release 0.4.6:
====================
Feature release to add the tsize option.
Thanks to Kuba Kończyk for the patch.
About Release 0.4.5:
====================
Bugfix release for compatability issues on Win32, among other small issues.
About Release 0.4.4:
====================
Bugfix release for poor tolerance of unsupported options in the server.
About Release 0.4.3:
====================
Bugfix release for an issue with the server's detection of the end of the file
during a download.
About Release 0.4.2:
====================
Bugfix release for some small installation issues with earlier Python
releases.
About Release 0.4.1:
====================
Bugfix release to fix the installation path, with some restructuring into a
tftpy package from the single module used previously.
About Release 0.4:
==================
This release adds a TftpServer class with a sample implementation in bin.
The server uses a single thread with multiple handlers and a select() loop to
handle multiple clients simultaneously.
Only downloads are supported at this time.
About Release 0.3:
==================
This release fixes a major RFC 1350 compliance problem with the remote TID.
About Release 0.2:
==================
This release adds variable block sizes, and general option support,
implementing RFCs 2347 and 2348. This is accessible in the TftpClient class
via the options dict, or in the sample client via the --blocksize option.
About Release 0.1:
==================
This is an initial release in the spirit of "release early, release often".
Currently the sample client works, supporting RFC 1350. The server is not yet
implemented, and RFC 2347 and 2348 support (variable block sizes) is underway,
planned for 0.2.
About Tftpy:
============
Purpose:
--------
Tftpy is a TFTP library for the Python programming language. It includes
client and server classes, with sample implementations. Hooks are included for
easy inclusion in a UI for populating progress indicators. It supports RFCs
1350, 2347, 2348 and the tsize option from RFC 2349.
Dependencies:
-------------
Python 2.3+, hopefully. Let me know if it fails to work.
Trifles:
--------
Home page: http://tftpy.sf.net/
Project page: http://sourceforge.net/projects/tftpy/
License is the MIT License
See COPYING in this distribution.
Limitations:
------------
- Only 'octet' mode is supported.
- The only options supported are blksize and tsize.
Author:
=======
Michael P. Soulier <msoulier@digitaltorque.ca>

94
doc/Makefile
View file

@ -1,94 +0,0 @@
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = _build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
clean:
-rm -rf $(BUILDDIR)/*
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
install-html: html
rm -rf ../html/sphinx
mkdir -p ../html/sphinx
cp -R _build/html/* ../html/sphinx
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/TFTPy.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/TFTPy.qhc"
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
"run these through (pdf)latex."
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."

194
doc/conf.py
View file

@ -1,194 +0,0 @@
# -*- coding: utf-8 -*-
#
# TFTPy documentation build configuration file, created by
# sphinx-quickstart on Sun Jul 11 18:48:32 2010.
#
# This file is execfile()d with the current directory set to its containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys, os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
sys.path.append(os.path.abspath('..'))
# -- General configuration -----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.autodoc']
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'TFTPy'
copyright = u'2010, Michael P. Soulier'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = '0.6'
# The full version, including alpha/beta/rc tags.
release = '0.6.0'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of documents that shouldn't be included in the build.
#unused_docs = []
# List of directories, relative to source directory, that shouldn't be searched
# for source files.
exclude_trees = ['_build']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. Major themes that come with
# Sphinx are currently 'default' and 'sphinxdoc'.
html_theme = 'default'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_use_modindex = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = ''
# Output file base name for HTML help builder.
htmlhelp_basename = 'TFTPydoc'
# -- Options for LaTeX output --------------------------------------------------
# The paper size ('letter' or 'a4').
#latex_paper_size = 'letter'
# The font size ('10pt', '11pt' or '12pt').
#latex_font_size = '10pt'
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'TFTPy.tex', u'TFTPy Documentation',
u'Michael P. Soulier', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# Additional stuff for the LaTeX preamble.
#latex_preamble = ''
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_use_modindex = True

114
doc/index.rst
View file

@ -1,114 +0,0 @@
.. TFTPy documentation master file, created by
sphinx-quickstart on Sun Jul 11 18:48:32 2010.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
TFTPy
=====
TFTPy is a pure python TFTP implementation.
.. toctree::
:maxdepth: 2
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`
Requirements
============
Python 2.3+, I think. I haven't tested in Python 2.3 in a while but it should
still work. Let me know if it doesn't.
Installation
============
If you download the source distribution, you can simply use distutils to
install, via::
python setup.py build
python setup.py install
Or, as this has been uploaded to pypi, you can use easy_install or pip::
easy_install tftpy
pip install tftpy
Once installed you should have the sample client and server scripts in bin,
and you should be able to import the `tftpy` module.
Examples
========
The simplest tftp client::
import tftpy
client = tftpy.TftpClient('tftp.digitaltorque.ca', 69)
client.download('remote_filename', 'local_filename')
The simplest tftp server::
import tftpy
server = tftpy.TftpServer('/tftpboot')
server.listen('0.0.0.0', 69)
See the sample client and server for slightly more complex examples.
API Documentation
=================
Front-end Modules
-----------------
These modules are the ones that you will need to use directly to implement a
TFTP client or server.
The :mod:`tftpy` Module
~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy
:members:
:show-inheritance:
The `TftpClient` Module
~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpClient
:members:
:show-inheritance:
The `TftpServer` Module
~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpServer
:members:
:show-inheritance:
Back-end Modules
----------------
The `TftpPacketFactory` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpPacketFactory
:members:
:show-inheritance:
The `TftpPacketTypes` Module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpPacketTypes
:members:
:show-inheritance:
The `TftpShared` Module
~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpShared
:members:
:show-inheritance:
The `TftpContexts` Module
~~~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpContexts
:members:
:show-inheritance:
The `TftpStates` Module
~~~~~~~~~~~~~~~~~~~~~~~
.. automodule:: tftpy.TftpStates
:members:
:show-inheritance:

551
doc/rfc1350.txt
View file

@ -1,551 +0,0 @@
RFC 1350 (RFC1350)
Internet RFC/STD/FYI/BCP Archives
[ [1]RFC Index | [2]RFC Search | [3]Usenet FAQs | [4]Web FAQs | [5]Documents
| [6]Cities ]
Alternate Formats: [7]rfc1350.txt | [8]rfc1350.txt.pdf
RFC 1350 - The TFTP Protocol (Revision 2)
_________________________________________________________________
Network Working Group K. Sollins
Request For Comments: 1350 MIT
STD: 33 July 1992
Obsoletes: [9]RFC 783
THE TFTP PROTOCOL (REVISION 2)
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Summary
TFTP is a very simple protocol used to transfer files. It is from
this that its name comes, Trivial File Transfer Protocol or TFTP.
Each nonterminal packet is acknowledged separately. This document
describes the protocol and its types of packets. The document also
explains the reasons behind some of the design decisions.
Acknowlegements
The protocol was originally designed by Noel Chiappa, and was
redesigned by him, Bob Baldwin and Dave Clark, with comments from
Steve Szymanski. The current revision of the document includes
modifications stemming from discussions with and suggestions from
Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
Yellick, and the author. The acknowledgement and retransmission
scheme was inspired by TCP, and the error mechanism was suggested by
PARC's EFTP abort message.
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
bug [4] and other minor document problems was done by Noel Chiappa.
This research was supported by the Advanced Research Projects Agency
of the Department of Defense and was monitored by the Office of Naval
Research under contract number N00014-75-C-0661.
1. Purpose
TFTP is a simple protocol to transfer files, and therefore was named
the Trivial File Transfer Protocol or TFTP. It has been implemented
on top of the Internet User Datagram protocol (UDP or Datagram) [2]
so it may be used to move files between machines on different
networks implementing UDP. (This should not exclude the possibility
of implementing TFTP on top of other datagram protocols.) It is
designed to be small and easy to implement. Therefore, it lacks most
of the features of a regular FTP. The only thing it can do is read
and write files (or mail) from/to a remote server. It cannot list
directories, and currently has no provisions for user authentication.
In common with other Internet protocols, it passes 8 bit bytes of
data.
Three modes of transfer are currently supported: netascii (This is
ascii as defined in "USA Standard Code for Information Interchange"
[1] with the modifications specified in "Telnet Protocol
Specification" [3].) Note that it is 8 bit ascii. The term
"netascii" will be used throughout this document to mean this
particular version of ascii.); octet (This replaces the "binary" mode
of previous versions of this document.) raw 8 bit bytes; mail,
netascii characters sent to a user rather than a file. (The mail
mode is obsolete and should not be implemented or used.) Additional
modes can be defined by pairs of cooperating hosts.
Reference [4] (section 4.2) should be consulted for further valuable
directives and suggestions on TFTP.
2. Overview of the Protocol
Any transfer begins with a request to read or write a file, which
also serves to request a connection. If the server grants the
request, the connection is opened and the file is sent in fixed
length blocks of 512 bytes. Each data packet contains one block of
data, and must be acknowledged by an acknowledgment packet before the
next packet can be sent. A data packet of less than 512 bytes
signals termination of a transfer. If a packet gets lost in the
network, the intended recipient will timeout and may retransmit his
last packet (which may be data or an acknowledgment), thus causing
the sender of the lost packet to retransmit that lost packet. The
sender has to keep just one packet on hand for retransmission, since
the lock step acknowledgment guarantees that all older packets have
been received. Notice that both machines involved in a transfer are
considered senders and receivers. One sends data and receives
acknowledgments, the other sends acknowledgments and receives data.
Most errors cause termination of the connection. An error is
signalled by sending an error packet. This packet is not
acknowledged, and not retransmitted (i.e., a TFTP server or user may
terminate after sending an error message), so the other end of the
connection may not get it. Therefore timeouts are used to detect
such a termination when the error packet has been lost. Errors are
caused by three types of events: not being able to satisfy the
request (e.g., file not found, access violation, or no such user),
receiving a packet which cannot be explained by a delay or
duplication in the network (e.g., an incorrectly formed packet), and
losing access to a necessary resource (e.g., disk full or access
denied during a transfer).
TFTP recognizes only one error condition that does not cause
termination, the source port of a received packet being incorrect.
In this case, an error packet is sent to the originating host.
This protocol is very restrictive, in order to simplify
implementation. For example, the fixed length blocks make allocation
straight forward, and the lock step acknowledgement provides flow
control and eliminates the need to reorder incoming data packets.
3. Relation to other Protocols
As mentioned TFTP is designed to be implemented on top of the
Datagram protocol (UDP). Since Datagram is implemented on the
Internet protocol, packets will have an Internet header, a Datagram
header, and a TFTP header. Additionally, the packets may have a
header (LNI, ARPA header, etc.) to allow them through the local
transport medium. As shown in Figure 3-1, the order of the contents
of a packet will be: local medium header, if used, Internet header,
Datagram header, TFTP header, followed by the remainder of the TFTP
packet. (This may or may not be data depending on the type of packet
as specified in the TFTP header.) TFTP does not specify any of the
values in the Internet header. On the other hand, the source and
destination port fields of the Datagram header (its format is given
in the appendix) are used by TFTP and the length field reflects the
size of the TFTP packet. The transfer identifiers (TID's) used by
TFTP are passed to the Datagram layer to be used as ports; therefore
they must be between 0 and 65,535. The initialization of TID's is
discussed in the section on initial connection protocol.
The TFTP header consists of a 2 byte opcode field which indicates
the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the
formats of the various types of packets are discussed further in the
section on TFTP packets.
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
Figure 3-1: Order of Headers
4. Initial Connection Protocol
A transfer is established by sending a request (WRQ to write onto a
foreign file system, or RRQ to read from it), and receiving a
positive reply, an acknowledgment packet for write, or the first data
packet for read. In general an acknowledgment packet will contain
the block number of the data packet being acknowledged. Each data
packet has associated with it a block number; block numbers are
consecutive and begin with one. Since the positive response to a
write request is an acknowledgment packet, in this special case the
block number will be zero. (Normally, since an acknowledgment packet
is acknowledging a data packet, the acknowledgment packet will
contain the block number of the data packet being acknowledged.) If
the reply is an error packet, then the request has been denied.
In order to create a connection, each end of the connection chooses a
TID for itself, to be used for the duration of that connection. The
TID's chosen for a connection should be randomly chosen, so that the
probability that the same number is chosen twice in immediate
succession is very low. Every packet has associated with it the two
TID's of the ends of the connection, the source TID and the
destination TID. These TID's are handed to the supporting UDP (or
other datagram protocol) as the source and destination ports. A
requesting host chooses its source TID as described above, and sends
its initial request to the known TID 69 decimal (105 octal) on the
serving host. The response to the request, under normal operation,
uses a TID chosen by the server as its source TID and the TID chosen
for the previous message by the requestor as its destination TID.
The two chosen TID's are then used for the remainder of the transfer.
As an example, the following shows the steps used to establish a
connection to write a file. Note that WRQ, ACK, and DATA are the
names of the write request, acknowledgment, and data types of packets
respectively. The appendix contains a similar example for reading a
file.
1. Host A sends a "WRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "ACK" (with block number= 0) to host A with
source= B's TID, destination= A's TID.
At this point the connection has been established and the first data
packet can be sent by Host A with a sequence number of 1. In the
next step, and in all succeeding steps, the hosts should make sure
that the source TID matches the value that was agreed on in steps 1
and 2. If a source TID does not match, the packet should be
discarded as erroneously sent from somewhere else. An error packet
should be sent to the source of the incorrect packet, while not
disturbing the transfer. This can be done only if the TFTP in fact
receives a packet with an incorrect TID. If the supporting protocols
do not allow it, this particular error condition will not arise.
The following example demonstrates a correct operation of the
protocol in which the above situation can occur. Host A sends a
request to host B. Somewhere in the network, the request packet is
duplicated, and as a result two acknowledgments are returned to host
A, with different TID's chosen on host B in response to the two
requests. When the first response arrives, host A continues the
connection. When the second response to the request arrives, it
should be rejected, but there is no reason to terminate the first
connection. Therefore, if different TID's are chosen for the two
connections on host B and host A checks the source TID's of the
messages it receives, the first connection can be maintained while
the second is rejected by returning an error packet.
5. TFTP Packets
TFTP supports five types of packets, all of which have been mentioned
above:
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)
The TFTP header of a packet contains the opcode associated with
that packet.
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
Figure 5-1: RRQ/WRQ packet
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
shown in Figure 5-1. The file name is a sequence of bytes in
netascii terminated by a zero byte. The mode field contains the
string "netascii", "octet", or "mail" (or any combination of upper
and lower case, such as "NETASCII", NetAscii", etc.) in netascii
indicating the three modes defined in the protocol. A host which
receives netascii mode data must translate the data to its own
format. Octet mode is used to transfer a file that is in the 8-bit
format of the machine from which the file is being transferred. It
is assumed that each type of machine has a single 8-bit format that
is more common, and that that format is chosen. For example, on a
DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
four bits of breakage. If a host receives a octet file and then
returns it, the returned file must be identical to the original.
Mail mode uses the name of a mail recipient in place of a file and
must begin with a WRQ. Otherwise it is identical to netascii mode.
The mail recipient string should be of the form "username" or
"username@hostname". If the second form is used, it allows the
option of mail forwarding by a relay computer.
The discussion above assumes that both the sender and recipient are
operating in the same mode, but there is no reason that this has to
be the case. For example, one might build a storage server. There
is no reason that such a machine needs to translate netascii into its
own form of text. Rather, the sender might send files in netascii,
but the storage server might simply store them without translation in
8-bit format. Another such situation is a problem that currently
exists on DEC-20 systems. Neither netascii nor octet accesses all
the bits in a word. One might create a special mode for such a
machine which read all the bits in a word, but in which the receiver
stored the information in 8-bit format. When such a file is
retrieved from the storage site, it must be restored to its original
form to be useful, so the reverse mode must also be implemented. The
user site will have to remember some information to achieve this. In
both of these examples, the request packets would specify octet mode
to the foreign host, but the local host would be in some other mode.
No such machine or application specific modes have been specified in
TFTP, but one would be compatible with this specification.
It is also possible to define other modes for cooperating pairs of
hosts, although this must be done with care. There is no requirement
that any other hosts implement these. There is no central authority
that will define these modes or assign them names.
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
Figure 5-2: DATA packet
Data is actually transferred in DATA packets depicted in Figure 5-2.
DATA packets (opcode = 3) have a block number and data field. The
block numbers on data packets begin with one and increase by one for
each new block of data. This restriction allows the program to use a
single number to discriminate between new packets and duplicates.
The data field is from zero to 512 bytes long. If it is 512 bytes
long, the block is not the last block of data; if it is from zero to
511 bytes long, it signals the end of the transfer. (See the section
on Normal Termination for details.)
All packets other than duplicate ACK's and those used for
termination are acknowledged unless a timeout occurs [4]. Sending a
DATA packet is an acknowledgment for the first ACK packet of the
previous DATA packet. The WRQ and DATA packets are acknowledged by
ACK or ERROR packets, while RRQ
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
Figure 5-3: ACK packet
and ACK packets are acknowledged by DATA or ERROR packets. Figure
5-3 depicts an ACK packet; the opcode is 4. The block number in
an ACK echoes the block number of the DATA packet being
acknowledged. A WRQ is acknowledged with an ACK packet having a
block number of zero.
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
Figure 5-4: ERROR packet
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
ERROR packet can be the acknowledgment of any other type of packet.
The error code is an integer indicating the nature of the error. A
table of values and meanings is given in the appendix. (Note that
several error codes have been added to this version of this
document.) The error message is intended for human consumption, and
should be in netascii. Like all other strings, it is terminated with
a zero byte.
6. Normal Termination
The end of a transfer is marked by a DATA packet that contains
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
packet is acknowledged by an ACK packet like all other DATA packets.
The host acknowledging the final DATA packet may terminate its side
of the connection on sending the final ACK. On the other hand,
dallying is encouraged. This means that the host sending the final
ACK will wait for a while before terminating in order to retransmit
the final ACK if it has been lost. The acknowledger will know that
the ACK has been lost if it receives the final DATA packet again.
The host sending the last DATA must retransmit it until the packet is
acknowledged or the sending host times out. If the response is an
ACK, the transmission was completed successfully. If the sender of
the data times out and is not prepared to retransmit any more, the
transfer may still have been completed successfully, after which the
acknowledger or network may have experienced a problem. It is also
possible in this case that the transfer was unsuccessful. In any
case, the connection has been closed.
7. Premature Termination
If a request can not be granted, or some error occurs during the
transfer, then an ERROR packet (opcode 5) is sent. This is only a
courtesy since it will not be retransmitted or acknowledged, so it
may never be received. Timeouts must also be used to detect errors.
I. Appendix
Order of Headers
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------
TFTP Formats
Type Op # Format without header
2 bytes string 1 byte string 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n bytes
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2 bytes
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string 1 byte
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------
Initial Connection Protocol for reading a file
1. Host A sends a "RRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "DATA" (with block number= 1) to host A with
source= B's TID, destination= A's TID.
Error Codes
Value Meaning
0 Not defined, see error message (if any).
1 File not found.
2 Access violation.
3 Disk full or allocation exceeded.
4 Illegal TFTP operation.
5 Unknown transfer ID.
6 File already exists.
7 No such user.
Internet User Datagram Header [2]
(This has been included only for convenience. TFTP need not be
implemented on top of the Internet User Datagram Protocol.)
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values of Fields
Source Port Picked by originator of packet.
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Length Number of bytes in UDP packet, including UDP header.
Checksum Reference 2 describes rules for computing checksum.
(The implementor of this should be sure that the
correct algorithm is used here.)
Field contains zero if unused.
Note: TFTP passes transfer identifiers (TID's) to the Internet User
Datagram protocol to be used as the source and destination ports.
References
[1] USA Standard Code for Information Interchange, USASI X3.4-1968.
[2] Postel, J., "User Datagram Protocol," [10]RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[3] Postel, J., "Telnet Protocol Specification," [11]RFC 764,
USC/Information Sciences Institute, June, 1980.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", [12]RFC 1123, USC/Information Sciences
Institute, October 1989.
Security Considerations
Since TFTP includes no login or access control mechanisms, care must
be taken in the rights granted to a TFTP server process so as not to
violate the security of the server hosts file system. TFTP is often
installed with controls such that only files that have public read
access are available via TFTP and writing files via TFTP is
disallowed.
Author's Address
Karen R. Sollins
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
Phone: (617) 253-6006
EMail: [13]SOLLINS@LCS.MIT.EDU
Comments about this RFC:
* [14]RFC 1350: How to setup TFTP across firewall. Why to spawn
connections on several different... by WahJava (2/7/2006)
* [15]RFC 1350: Since there is no master slave arrangement. What happens
if both ends of the... by pg (3/30/2005)
* [16]RFC 1350: What happens when the TFTP client or server detects that
the ethernet link which... by Sekhar Nori (12/29/2003)
* [17]RFC 1350: This RFC may benefit from an update in the style of PPP or
SSCOP protocol... by Chris (10/4/2004)
* [18]RFC 1350: What happens if the server receives any packet other than
RRQ/WRQ in the initial... by Orgad (10/24/2003)
* [19]RFC 1350: In the following para,it is considered duplication of the
acknowledgment packet... by KiranKumar (1/1/2006)
* [20]RFC 1350: What happens if the data on the file is a multiple 512
bytes? When will the... by yara (2/23/2005)
* [21]RFC 1350: I tried WhiteHorn TFTP server (www.whitehorns.net) and
really liked it. Does... by bartley (7/29/2005)
* [22]RFC 1350: I'd like to see more discussion about the benefits and
drawbacks of using... by Mike Cepek (4/19/2005)
* [23]RFC 1350: Any words on the ipv6 support in TFTP..It might be not the
correct question here... by Piyush Yaduvanshi (2/23/2006)
Previous: [24]RFC 1349 - Type of Service in the Internet Protocol Suite
Next: [25]RFC 1351 - SNMP Administrative Model
_________________________________________________________________
[ [26]RFC Index | [27]RFC Search | [28]Usenet FAQs | [29]Web FAQs |
[30]Documents | [31]Cities ]
References
1. http://www.faqs.org/rfcs/
2. http://www.faqs.org/rfcs/rfcsearch.html
3. http://www.faqs.org/faqs/
4. http://www.faqs.org/contrib/
5. http://www.faqs.org/docs/
6. http://www.city-data.com/
7. http://www.faqs.org/ftp/rfc/rfc1350.txt
8. http://www.faqs.org/ftp/rfc/pdf/rfc1350.txt.pdf
9. http://www.faqs.org/rfcs/rfc783.html
10. http://www.faqs.org/rfcs/rfc768.html
11. http://www.faqs.org/rfcs/rfc764.html
12. http://www.faqs.org/rfcs/rfc1123.html
13. mailto:SOLLINS@LCS.MIT.EDU
14. http://www.faqs.org/qa/rfcc-2889.html
15. http://www.faqs.org/qa/rfcc-1841.html
16. http://www.faqs.org/qa/rfcc-433.html
17. http://www.faqs.org/qa/rfcc-1281.html
18. http://www.faqs.org/qa/rfcc-255.html
19. http://www.faqs.org/qa/rfcc-2798.html
20. http://www.faqs.org/qa/rfcc-1734.html
21. http://www.faqs.org/qa/rfcc-2297.html
22. http://www.faqs.org/qa/rfcc-1916.html
23. http://www.faqs.org/qa/rfcc-2933.html
24. http://www.faqs.org/rfcs/rfc1349.html
25. http://www.faqs.org/rfcs/rfc1351.html
26. http://www.faqs.org/rfcs/
27. http://www.faqs.org/rfcs/rfcsearch.html
28. http://www.faqs.org/faqs/
29. http://www.faqs.org/contrib/
30. http://www.faqs.org/docs/
31. http://www.city-data.com/

395
doc/rfc2347.txt
View file

@ -1,395 +0,0 @@
Network Working Group G. Malkin
Request for Commments: 2347 Bay Networks
Updates: 1350 A. Harkin
Obsoletes: 1782 Hewlett Packard Co.
Category: Standards Track May 1998
TFTP Option Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host. This document describes a simple extension to TFTP to
allow option negotiation prior to the file transfer.
Introduction
The option negotiation mechanism proposed in this document is a
backward-compatible extension to the TFTP protocol. It allows file
transfer options to be negotiated prior to the transfer using a
mechanism which is consistent with TFTP's Request Packet format. The
mechanism is kept simple by enforcing a request-respond-acknowledge
sequence, similar to the lock-step approach taken by TFTP itself.
While the option negotiation mechanism is general purpose, in that
many types of options may be negotiated, it was created to support
the Blocksize option defined in [2]. Additional options are defined
in [3].
Packet Formats
TFTP options are appended to the Read Request and Write Request
packets. A new type of TFTP packet, the Option Acknowledgment
(OACK), is used to acknowledge a client's option negotiation request.
A new error code, 8, is hereby defined to indicate that a transfer
Malkin & Harkin Standards Track [Page 1]
RFC 2347 TFTP Option Extension May 1998
should be terminated due to option negotiation.
Options are appended to a TFTP Read Request or Write Request packet
as follows:
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
>-------+---+---~~---+---+
< optN | 0 | valueN | 0 |
>-------+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
filename
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field.
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field.
opt1
The first option, in case-insensitive ASCII (e.g., blksize).
This is a NULL-terminated field.
value1
The value associated with the first option, in case-
insensitive ASCII. This is a NULL-terminated field.
optN, valueN
The final option/value pair. Each NULL-terminated field is
specified in case-insensitive ASCII.
The options and values are all NULL-terminated, in keeping with the
original request format. If multiple options are to be negotiated,
they are appended to each other. The order in which options are
specified is not significant. The maximum size of a request packet
is 512 octets.
The OACK packet has the following format:
Malkin & Harkin Standards Track [Page 2]
RFC 2347 TFTP Option Extension May 1998
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains a 6, for Option Acknowledgment.
opt1
The first option acknowledgment, copied from the original
request.
value1
The acknowledged value associated with the first option. If
and how this value may differ from the original request is
detailed in the specification for the option.
optN, valueN
The final option/value acknowledgment pair.
Negotiation Protocol
The client appends options at the end of the Read Request or Write
request packet, as shown above. Any number of options may be
specified; however, an option may only be specified once. The order
of the options is not significant.
If the server supports option negotiation, and it recognizes one or
more of the options specified in the request packet, the server may
respond with an Options Acknowledgment (OACK). Each option the
server recognizes, and accepts the value for, is included in the
OACK. Some options may allow alternate values to be proposed, but
this is an option specific feature. The server must not include in
the OACK any option which had not been specifically requested by the
client; that is, only the client may initiate option negotiation.
Options which the server does not support should be omitted from the
OACK; they should not cause an ERROR packet to be generated. If the
value of a supported option is invalid, the specification for that
option will indicate whether the server should simply omit the option
from the OACK, respond with an alternate value, or send an ERROR
packet, with error code 8, to terminate the transfer.
An option not acknowledged by the server must be ignored by the
client and server as if it were never requested. If multiple options
were requested, the client must use those options which were
acknowledged by the server and must not use those options which were
not acknowledged by the server.
Malkin & Harkin Standards Track [Page 3]
RFC 2347 TFTP Option Extension May 1998
When the client appends options to the end of a Read Request packet,
three possible responses may be returned by the server:
OACK - acknowledge of Read Request and the options;
DATA - acknowledge of Read Request, but not the options;
ERROR - the request has been denied.
When the client appends options to the end of a Write Request packet,
three possible responses may be returned by the server:
OACK - acknowledge of Write Request and the options;
ACK - acknowledge of Write Request, but not the options;
ERROR - the request has been denied.
If a server implementation does not support option negotiation, it
will likely ignore any options appended to the client's request. In
this case, the server will return a DATA packet for a Read Request
and an ACK packet for a Write Request establishing normal TFTP data
transfer. In the event that a server returns an error for a request
which carries an option, the client may attempt to repeat the request
without appending any options. This implementation option would
handle servers which consider extraneous data in the request packet
to be erroneous.
Depending on the original transfer request there are two ways for a
client to confirm acceptance of a server's OACK. If the transfer was
initiated with a Read Request, then an ACK (with the data block
number set to 0) is sent by the client to confirm the values in the
server's OACK packet. If the transfer was initiated with a Write
Request, then the client begins the transfer with the first DATA
packet, using the negotiated values. If the client rejects the OACK,
then it sends an ERROR packet, with error code 8, to the server and
the transfer is terminated.
Once a client acknowledges an OACK, with an appropriate non-error
response, that client has agreed to use only the options and values
returned by the server. Remember that the server cannot request an
option; it can only respond to them. If the client receives an OACK
containing an unrequested option, it should respond with an ERROR
packet, with error code 8, and terminate the transfer.
Malkin & Harkin Standards Track [Page 4]
RFC 2347 TFTP Option Extension May 1998
Examples
Read Request
client server
-------------------------------------------------------
|1|foofile|0|octet|0|blksize|0|1432|0| --> RRQ
<-- |6|blksize|0|1432|0| OACK
|4|0| --> ACK
<-- |3|1| 1432 octets of data | DATA
|4|1| --> ACK
<-- |3|2| 1432 octets of data | DATA
|4|2| --> ACK
<-- |3|3|<1432 octets of data | DATA
|4|3| --> ACK
Write Request
client server
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| --> RRQ
<-- |6|blksize|0|2048|0| OACK
|3|1| 2048 octets of data | --> DATA
<-- |4|1| ACK
|3|2| 2048 octets of data | --> DATA
<-- |4|2| ACK
|3|3|<2048 octets of data | --> DATA
<-- |4|3| ACK
Security Considerations
The basic TFTP protocol has no security mechanism. This is why it
has no rename, delete, or file overwrite capabilities. This document
does not add any security to TFTP; however, the specified extensions
do not add any additional security risks.
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
May 1998.
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
Size Options", RFC 2349, May 1998.
Malkin & Harkin Standards Track [Page 5]
RFC 2347 TFTP Option Extension May 1998
Authors' Addresses
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.com
Art Harkin
Internet Services Project
Information Networks Division
19420 Homestead Road MS 43LN
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 6]
RFC 2347 TFTP Option Extension May 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.