Any plan to support python3?

Hi,

I am currently using tftpy library for my own project, it is working well, thanks.
But I found a TypeError Exception recently i would like to report it to you, after browsing the lib code i found that self.context.tidport is None in the Resendlast() function.

I let you know.

WARNING:tftpy:Timeout waiting for traffic, retrying...
ERROR:tftpy:Timed-out waiting for traffic
WARNING:tftpy:resending last packet
WARNING:tftpy:Resending packet RRQ packet: filename = config.cfg mode = octet on sessions <tftpy.TftpStates.TftpStateSentRRQ object at 0xb89b50>
Traceback (most recent call last):
  File "mod_TFTP_files.py", line 210, in <module>
    obj.run()
  File "mod_TFTP_files.py", line 121, in run
    if self.__retrieve_file_attempt():
  File "mod_TFTP_files.py", line 152, in __retrieve_file_attempt
    client.download(self.path, path_file_tftp, None, 1)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpClient.py", line 53, in download
    self.context.start()
  File "/usr/lib/python2.7/site-packages/tftpy/TftpContexts.py", line 378, in start
    self.state.resendLast()
  File "/usr/lib/python2.7/site-packages/tftpy/TftpStates.py", line 203, in resendLast
    (self.context.host, self.context.tidport))
TypeError: an integer is required

Here is the sample of code i am using.

      import tftpy
     [...]
      # TFTP connection and test to download known files
      client = tftpy.TftpClient(str(self.ip), int(self.port))
      # Create all hierarchical folder if necessary
      try:
        os.makedirs(os.path.dirname(path_file_tftp))
      except (OSError, IOError) as e:
        pass
      if (self.verbose): self.log("Download %s to %s" % (self.path, path_file_tftp))
      client.download(self.path, path_file_tftp, None, 1)

The problem come from my iptables. If i clean them it work like a charm. Assume that self.ip, self.port and path_file_ftp are well formatted.

To reproduce disabling the network should be enough.

Best regard.

Currently we do no locking at all. The client and server should use flock with
read/write locks if they are reading/writing, to prevent file corruption.

So I've written a handler to generate pxelinux menus for requests on /pxelinux.cfg/[MAC], and otherwise a file off the filesystem and ran into this:

...
  File "/Users/mike/src/hermestftpd/.tox/py27/lib/python2.7/site-packages/tftpy/TftpPacketTypes.py", line 268, in encode
    self.data)
struct.error: argument for 's' must be a string

I changed the line to str(self.data) and all is well. That may be dumb, but I figured as the struct call is inferring self.data is a string, coercing it might not be terrible.

My dyn_file_func builds a string, and returns a StringIO object for the generated files, and just a file object otherwise.

When using TftpClient.download with a StringIO, it should not close it after the download otherwhise it's impossible to read the content

The unit tests don't currently run and only cover the basic types. This should be rectified.

hi,

as I'm using the old version of tftpy in my DC² (http://launchpad.net/dc2) project, I just updated the code to use your new api.
Surprised I was ;) when I saw that you don't support subdirectories:

Code sample:

There are no os.sep's allowed in the filename.

    # FIXME: Should we allow subdirectories?
    if pkt.filename.find(os.sep) >= 0:
        self.sendError(TftpErrors.IllegalTftpOp)
        raise TftpException, "%s found in filename, not permitted" % os.sep

which is somehow a bit strange.

For Example, during PXE boot pxelinux will ask for a file pxelinux.cfg/<MAC-ADDRESS/IP-ADDRESS/UUID>
now it's not supported anymore.

Can we get rid of this ?

Btw, thx for implementing dyn_file_func...:)
Regards,

\sh

When sending a filename like foo/bar/bash, the server should create foo/bar at the root, and open bash for writing, but it's not doing so.

{{{
INFO:tftpy:requested file is in the server root - good
INFO:tftpy:Opening file /home/msoulier/work/tftpy/t/foo/bar/bash for writing
Traceback (most recent call last):
File "../bin/tftpy_server.py", line 51, in
main()
File "../bin/tftpy_server.py", line 43, in main
server.listen(options.ip, options.port)
File "/home/msoulier/work/tftpy/tftpy/TftpServer.py", line 110, in listen
self.sessions[key].start(buffer)
File "/home/msoulier/work/tftpy/tftpy/TftpContexts.py", line 231, in start
self.port)
File "/home/msoulier/work/tftpy/tftpy/TftpStates.py", line 369, in handle
rport)
File "/home/msoulier/work/tftpy/tftpy/TftpStates.py", line 333, in handle
self.context.fileobj = open(path, "wb")
IOError: [Errno 2] No such file or directory: '/home/msoulier/work/tftpy/t/foo/bar/bash'
}}}

Meanwhile the client gets a very non-intuitive error back.

{{{
msoulier@egor:...oulier/work/tftpy$ PYTHONPATH=. python bin/tftpy_client.py --host=localhost --port=10000 --upload=foo/bar/bash -i t/100KBFILE
INFO:tftpy:Sending tftp upload request to localhost
INFO:tftpy: filename -> foo/bar/bash
INFO:tftpy: options -> {}
WARNING:tftpy:Timeout waiting for traffic, retrying...
ERROR:tftpy:Timed-out waiting for traffic
WARNING:tftpy:resending last packet
WARNING:tftpy:Resending packet WRQ packet: filename = foo/bar/bash mode = octet on sessions <tftpy.TftpStates.TftpStateSentWRQ object at 0x954d24c>
Traceback (most recent call last):
File "bin/tftpy_client.py", line 115, in
main()
File "bin/tftpy_client.py", line 107, in main
progresshook)
File "/home/msoulier/work/tftpy/tftpy/TftpClient.py", line 88, in upload
self.context.start()
File "/home/msoulier/work/tftpy/tftpy/TftpContexts.py", line 303, in start
self.state.resendLast()
File "/home/msoulier/work/tftpy/tftpy/TftpStates.py", line 213, in resendLast
(self.context.host, self.context.tidport))
TypeError: an integer is required
}}}

Hello!

it will be great if slash in the beginning of filename will be ignored and don't raises TftpException
i try to get file from tftpy my device got command get -u tftp://$ip:$port/filename and sends /filename as a file to get. unfortunately i can't control that behavior

It would be nice to have the remote address as a parameter to the function to dynamically generate/choose files.

I've patched a version for myself but I don't see a way to change this API without breaking it for all other people. Maybe in the next version?

Currently we use a select loop and blocking sockets, which is actually not a good combination. There are many reasons why select can return, and sometimes they result in a blocking read() operation, which would block the entire server.

Would you be able to release a package that has IPv6 addressing support?

It might be nice to allow the server to serve from a list of directories instead of just one. The only problem here is when someone sends a WRQ request, where do you write to? Likely the first one.

Running Py2.7.5 on CentOS7. After starting up the server and mounting to root (/), when client makes a request, server throws the below exception.

[root@CENT7 tftpy]# tftpy_server.py -r "/"
INFO:tftpy:Server requested on ip 0.0.0.0, port 69
INFO:tftpy:Starting receive loop...
Traceback (most recent call last):
  File "/usr/bin/tftpy_server.py", line 59, in <module>
    main()
  File "/usr/bin/tftpy_server.py", line 51, in main
    server.listen(options.ip, options.port)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpServer.py", line 166, in listen
    self.sessions[key].start(buffer)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpContexts.py", line 234, in start
    pkt = self.factory.parse(buffer)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpPacketFactory.py", line 28, in parse
    (opcode,) = struct.unpack("!H", buffer[:2])
TypeError: Struct() argument 1 must be string, not unicode

Currently, when a client sends an RRQ and requests the 'tsize' option, TftpServer (via TftpStates.TftpState.returnSupportedOptions) replies with 'tsize' set to 1. According to the spec, tsize should be the size in bytes of the file:

http://tools.ietf.org/html/rfc2349
"In Read Request packets, a size of "0" is specified in the request and the size of the file, in octets, is returned in the OACK."

Right now if you don't provide the --blksize option, the client populates it anyway with 512. This makes it difficult to test the server without the blksize option being provided, and I think it's wrong anyway, although the impact is small.

An assertion in sendDAT() asserts that the blocknumber must be positive, but it rolls over to zero when we pass 2 ** 32 blocks.

Apparently the Python CNRI license is not GPL-compatible.

Need a simple BSD-like license that is.

Using output='-' to redirect the contents of the downloaded file to stdout causes stdout to be closed, as subsequent statements like print will fail with an error like the following:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

Not sure if this is the appropriate solution, but maybe creating a closable/temp handle to stdout should be used instead if consistency is desired. cf. http://stackoverflow.com/a/40845164/4896937

This idea came from Kamal Swamidoss [email protected]. He wants the server to notify via callback when a transfer is complete.

I'm going to check in his work on a branch and then update the implementation. His required a new return value from handle(), which I don't like, but I do like the idea. I could also add a command-line argument to the included server to call an external process on completion.

From Justin Neumann:

I found a bug while trying to use your python tftp module.

I spent a few hours testing until I finally located the problem and
found a simple solution.

The problem occurs when opening many (>1024) tftp connections
(downloads - i.e. GETs). The number of sockets open becomes too large
for the OS and the program crashes.

The solution is to add the following piece of code to the TftpState.py
file in the "cycle" method.

At the end of the method, when a connection has timed out, the socket
must be closed (because we assume that this socket is done being
used).

the line:

self.sock.close()

Is all that needs to be added, just before the exception is raised.

Currently we only support octet mode. While mail support is likely pointless, netascii could be helpful for transferring text files, although I doubt it. It's likely just worth doing to be a more complete implementation.

the git tag for 0.6.2 is missing

may be it will be good idea move message
Received ACK for packet XX

to DEBUG level.
Else INFO level began to be more debugging than it must be.
and leave on iNFO level only info about sending and receiving files

It will help in editing with an additional file where I refactor context to.

I expected the server to be killed by SIGTERM, which was naive. A GUI user won't be doing that, and the server loops forever. There should be a stop() method in the server.

Not sure if the issue tracker is the right place for this:

Would you mind releasing a new version of tftpy? There are currently three commits in master that are not in 0.6.1, one of which is a bugfix for the server stop functionality.
It would make things a little easier for me if there was a version available with pip that included that fix.

Hello EveryOne,

Im using tftpy within multithread script and after call server.stop() I
have trace:

Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
self.run()
File "/usr/lib/python2.6/threading.py", line 484, in run
self.__target(_self.__args, *_self.__kwargs)
File "utils/myterm.py", line 739, in writer
self.stop()
File "utils/myterm.py", line 273, in stop
self._stop_tftpd()
File "utils/myterm.py", line 256, in _stop_tftpd
self.server.stop()
File
"/usr/local/lib/python2.6/dist-packages/tftpy-0.6.1-py2.6.egg/tftpy/TftpServer.py",
line 220, in stop
self.shutdown_immediately = True
NameError: global name 'self' is not defined

I have class Miniterm(object):
and in method
def init(
Iam call for create entity
self.server = tftpy.TftpServer('/home/hcs')

I also have method with
def tftpdstarter(self):

     self.server.listen('0.0.0.0', 69)

and it works

For create thread Im using
self.tftpd_thread = threading.Thread(target=self.tftpdstarter)
self.tftpd_thread.setDaemon(True)
self.tftpd_thread.start()

In some moment I want stop application and from another thread call
self.server.stop()

and I get:
File
"/usr/local/lib/python2.6/dist-packages/tftpy-0.6.1-py2.6.egg/tftpy/TftpServer.py",
line 220, in stop
self.shutdown_immediately = True
NameError: global name 'self' is not defined

With best wishes,
Slav Ag

Is there easy way how to implement single port mode in tftpy -- server listens and responds on the same port (i.e. 69)?

Right now, I'm using opentftp for serving firmwares into devices with 8bit MCU. Because of NATs and firewalls, I have to use single port. I would like to use Python implementation of TFTP, because the rest of my project is written in Python.

After reading the code, I'm not sure if this single port can be easily done. What part should change?

If the client tries netascii mode in the transfer then the server returrns.

We should be catching the exception and moving on to the next session.

Currently the TFTPy Server does use a random Source Port with the Source Port of the request of the client as destination port for sending files. This seems to make problems with some PXE BIOSes. With other TFTP Server which use source Port 69 there are no problems.

Hello,

I'm trying to copy configuration file from HP ProCurve switch and it fails with error:
ERROR:tftpy:Fatal exception thrown from session ip_address:1028: Only octet transfers are supported at this time.
I've tried all the options available on the HP Procurve, it didn't help?

Any hope to get this type of transfers fixed soon? Thanks!

When tftpy runs as a server and a data packet is lost, all further requests for the lost packet are just logged as duplicate ACKs by tftpy. If I add

          self.sendDAT()

right after

        elif pkt.blocknumber < self.context.next_block:
            log.debug("Received duplicate ACK for block %d"
                % pkt.blocknumber)
            self.context.metrics.add_dup(pkt)

the transfer continues properly after packet loss. I don't know if it is an error of tftpy or of my tftp client (u-boot bootloader), but the problem does not occur with other tftp servers.

Regards,
Thomas

ISPs often block udp port 69 as it's been used to spread malware. It might be nice to allow the server to listen on multiple ports. We could run multiple instances I suppose, but supporting multiple ports shouldn't be too hard.

One possible problem is in setNextBlock
I have added >= so goes from 65535 to 0 and not 65536 to 0.

def setNextBlock(self, block):
if block >= 2 ** 16:
log.debug("Block number rollover to 0 again")
block = 0
self.__eblock = block

SImple issue, when attempting to use the server. The listen() method allows specifying the select timeout, but the select in the code doesn't actually use the parameter.

I think code has to be:

if self.context.dyn_file_func:
   log.debug("No such file %s but using dyn_file_func", path)
   self.context.fileobj = \
        self.context.dyn_file_func(path, raddress=raddress, rport=rport)
elif os.path.exists(path):
    self.context.fileobj = open(path, "rb")
else:
    self.sendError(TftpErrors.FileNotFound)
    raise TftpException("File not found: %s" % path)

With this you can use program with:

#!/usr/bin/env python
import tftpy
import os

def evaluate(path,raddress,rport):
	print path
	print raddress
	print rport
	if os.path.exists(path):
		return open(path,'r')
	else:
		raise tftpy.TftpException("File not found: %s" % path)

server = tftpy.TftpServer('/srv/tftp', evaluate)
#server = tftpy.TftpServer('/srv/tftp')
server.listen('0.0.0.0')

I think now is working as expected. I think you have to evaluate file availability in function not in library.

If you pass unicode into tftpy you end up with an obscure encode error. The library should just catch that up front.

Had a feature request to add read-only flags to the server to prevent uploads. The only option right now is to run the tftp root somewhere that the server does not have write access to, but blocking uploads should be an option, maybe one that is on by default.

From: 
To: [email protected]
Subject: tftpy error with blksize
Date: Sun, 23 May 2010 14:15:53 +0700
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423
        Thunderbird/3.0.4

hello!
i find en error in TftpStates.py

and made a quick fix. here it is.

462c462,465
<             blksize = int(self.context.options['blksize'])

---
>             try:
>                 blksize = int(self.context.options['blksize'])
>             except:
>                 blksize = DEF_BLKSIZE

my device does't sets blksize only tsize.

sorry, but my english is bad.

--
?? ??????????????????, ?????????????? ??????????????,
?????????????? ?????????????????????????? ?????????????????? ????????????????????????
???????????????? ????-??????????????
??. ??????????????????????

In TftpStates.py function serverInitial(), I needed to add a check for pkt.mode against "OCTET", not just 'octet'.

After a timeout waiting for an ack, the data packet is not resent, and the transfer always fails.

I have a requirement which state that, a client requested file must be sent on 4-5 different fixed ports. right now (one file) we are sending it through ephemeral port which is not a good idea for client perspective. I need help in two issues which are mentioned below,

Issue1:
How to remove ephemeral port concept and make it fixed port server.

Issue2:
Server should serve data to fixed multiple ports parallelly (same file on to multiple ports).

FYI:
I don't want to run multiple instances of the TFTP server, because this may slow down the GUI.

In TftpContext.checkTimeout a session is aborted if no activity for SOCK_TIMEOUT sedocnds, this is 5 seconds. I am using the Tftp Server as a target for techout/backup of embedded devices. These do occasionally hiccup on uploads as they prepare data on the fly for delivery or have to do other tasks internally.

For example on 1 successful techout I had a hiccup of 4 seconds.

For now I am just going to modify checkTimeout to use a multiple of SOCK_TIMEOUT. Ideally this would be a configurable item on the tftp server or even a per session basis.

Getting the below error when client asks for a file which doesn't exist.

Looks like tftpy sends a proper error message and kills the session, but then it receives another packet (maybe an error ack?) and that causes it to crash.

[root@CENT7 tftpy]# tftpy_server.py -r "/" -d
DEBUG:tftpy:tftproot / does exist
DEBUG:tftpy:tftproot / is a directory
DEBUG:tftpy:tftproot / is readable
DEBUG:tftpy:tftproot / is writable
INFO:tftpy:Server requested on ip 0.0.0.0, port 69
INFO:tftpy:Starting receive loop...
DEBUG:tftpy:shutdown_immediately is False
DEBUG:tftpy:shutdown_gracefully is False
DEBUG:tftpy:Performing select on this inputlist: [<socket._socketobject object at 0x7f78d452de50>]
DEBUG:tftpy:Data ready on our main socket
DEBUG:tftpy:Read 13 bytes
DEBUG:tftpy:Creating new server context for session key = 10.162.0.2:58833
DEBUG:tftpy:In TftpContextServer.start
DEBUG:tftpy:Set metrics.start_time to 1494894666.47
DEBUG:tftpy:parsing a 13 byte packet
DEBUG:tftpy:opcode is 1
DEBUG:tftpy:in TftpPacketWithOptions.setoptions
DEBUG:tftpy:options: {}
DEBUG:tftpy:setting options hash to: {}
DEBUG:tftpy:in decode: about to iterate buffer counting nulls
DEBUG:tftpy:found a null at length 4, now have 1
DEBUG:tftpy:found a null at length 5, now have 2
DEBUG:tftpy:hopefully found end of mode at length 10
DEBUG:tftpy:about to unpack buffer with format: 4sx5sx
DEBUG:tftpy:unpacking buffer: 'some\x00octet\x00'
DEBUG:tftpy:set filename to some
DEBUG:tftpy:set mode to octet
DEBUG:tftpy:decode_options: buffer is: ''
DEBUG:tftpy:size of buffer is 0 bytes
DEBUG:tftpy:size of buffer is zero, returning empty hash
DEBUG:tftpy:in TftpPacketWithOptions.setoptions
DEBUG:tftpy:options: {}
DEBUG:tftpy:setting options hash to: {}
DEBUG:tftpy:in TftpPacketWithOptions.getoptions
DEBUG:tftpy:TftpContextServer.start() - factory returned a RRQ packet: filename = some mode = octet
DEBUG:tftpy:In TftpStateServerStart.handle
DEBUG:tftpy:Handling an RRQ packet
DEBUG:tftpy:In TftpStateServerRecvRRQ.handle
DEBUG:tftpy:in TftpPacketWithOptions.getoptions
INFO:tftpy:Setting tidport to 58833
DEBUG:tftpy:Setting default options, blksize
DEBUG:tftpy:Requested filename is some
DEBUG:tftpy:full_path is /some
INFO:tftpy:requested file is in the server root - good
INFO:tftpy:Opening file /some for reading
DEBUG:tftpy:In sendError, being asked to send error 1
58833
<type 'int'>
DEBUG:tftpy:encoding ERR packet with format !HH14sx
ERROR:tftpy:Fatal exception thrown from session 10.162.0.2:58833: File not found: /some
INFO:tftpy:Currently handling these sessions:
INFO:tftpy:    10.162.0.2:58833 <tftpy.TftpStates.TftpStateServerStart object at 0x7f78d4549590>
DEBUG:tftpy:Looping on all sessions to check for timeouts
DEBUG:tftpy:checking for timeout on session 10.162.0.2:58833 <tftpy.TftpStates.TftpStateServerStart object at 0x7f78d4549590>
DEBUG:tftpy:Iterating deletion list.
INFO:tftpy:
INFO:tftpy:Session 10.162.0.2:58833 complete
DEBUG:tftpy:Gathering up metrics from session before deleting
DEBUG:tftpy:in TftpContext.end
DEBUG:tftpy:Set metrics.end_time to 1494894666.47
DEBUG:tftpy:TftpMetrics.compute: duration is 0.00209307670593
DEBUG:tftpy:TftpMetrics.compute: kbps is 0.0
INFO:tftpy:Transferred 0 bytes in 0.00 seconds
INFO:tftpy:Average rate: 0.00 kbps
INFO:tftpy:0.00 bytes in resent data
INFO:tftpy:0 duplicate packets
DEBUG:tftpy:Deleting session 10.162.0.2:58833
DEBUG:tftpy:Session list is now {}
DEBUG:tftpy:shutdown_immediately is False
DEBUG:tftpy:shutdown_gracefully is False
DEBUG:tftpy:Performing select on this inputlist: [<socket._socketobject object at 0x7f78d452de50>]
DEBUG:tftpy:Data ready on our main socket
DEBUG:tftpy:Read 23 bytes
DEBUG:tftpy:Creating new server context for session key = 10.162.0.2:58833
DEBUG:tftpy:In TftpContextServer.start
DEBUG:tftpy:Set metrics.start_time to 1494894666.47
DEBUG:tftpy:parsing a 23 byte packet
DEBUG:tftpy:opcode is 5
DEBUG:tftpy:Decoding ERR packet, length 23 bytes
DEBUG:tftpy:Good ERR packet > 4 bytes
DEBUG:tftpy:Decoding ERR packet with format: !HH18sx
ERROR:tftpy:ERR packet - errorcode: 0, message: Session terminated
DEBUG:tftpy:TftpContextServer.start() - factory returned a ERR packet: errorcode = 0
    msg = 
DEBUG:tftpy:In TftpStateServerStart.handle
DEBUG:tftpy:In sendError, being asked to send error 4
None
<type 'NoneType'>
DEBUG:tftpy:encoding ERR packet with format !HH22sx
Traceback (most recent call last):
  File "/usr/bin/tftpy_server.py", line 59, in <module>
    main()
  File "/usr/bin/tftpy_server.py", line 51, in main
    server.listen(options.ip, options.port)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpServer.py", line 166, in listen
    self.sessions[key].start(buffer)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpContexts.py", line 241, in start
    self.port)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpStates.py", line 423, in handle
    self.sendError(TftpErrors.IllegalTftpOp)
  File "/usr/lib/python2.7/site-packages/tftpy/TftpStates.py", line 133, in sendError
    self.context.tidport))
TypeError: an integer is required

Currently the only API docs are generated using epydoc. Given the superiority of the Sphinx project, it would make an excellent replacement.

Right now tftpy is ipv4 only. Some patches were supplied to add ipv6 support, and I now have a network setup where I can test it, so lets do it.

dyn_file_func currently accepts just the filename. In the application I wish to use tftpy, I need to serve up files using dyn_file_func based on the source MAC address. To do this, I'd want to just change line 302 of TftpStates.py to pass self.context, rather than self.context.file_to_transfer, but that's clearly going to break things.

I'll try and work a backwards-compatible patch (probably using inspect to check the number of arguments), then issue a PR.

Hello!

I want to create tftpy thread for one connection, and then exit thread.
As i can see Tftpy server main loop is
while True:

may be it will be good to create main loop as

while <controlled expression>:

It would be great if upload and download could be made to work on any file-like object; ie open file handles, StringIO objects, etc.