frequently questioned answers

A word of warning: This reply is purely theoretical as I have never tested PumpKIN for ability to transfer large files. If PumpKIN fails to transfer big files due to the bug, not protocol limitations, I would rather fix it than make this bug into the feature by documenting it.

TFTP protocol by default operates on 512 bytes long blocks, counted using a 16 bits word. Which means that the file size is limited to 65536*512=32M. Although, if both sides supports it you can raise the limit by increasing the block size. For example, if you use 1024 bytes long blocks you can go as far as 64M.

And I do not think it is a good idea to use TFTP to transfer large files, anyway.

I am afraid NATing port 69 is not enough for tftp operations as this port is only used for initiating request, then the connection gets a new port assigned to it.

It is the limit for blocksize of 512 bytes. With 1024 bytes you can go as far as 64M. Further up you'll need the blocksize of 2048. But keep in mind that both ends needs to support blocksize option.

You already have a TFTP service running?

Let me guess, you have followed the link from pcworld? If so, it is most likely, you do not need PumpKIN, because their description does not have much to do with PumpKIN functionality. Taking into account they have put some different developer as PumpKIN author it is a miracle you ended up at our site.

And, to answer your question: use binary download, not source (do not ask me why pcworld thinks everyone needs sources).

Thank you. We're glad you liked it.

This is how it's supposed to work. Here is an excerpt from RFC1350: 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.

As a solution I would suggest that you don't put any obstacles between client and server.

After a short email exchange the author of the question came up with the solution and kindly shared it with other users:

• Requirements
  • INSTSRV.EXE and SRVANY.EXE for Windows NT Resource Kit
• Installation
  • Install PumpKIN
  • Copy INSTSRV.EXE and SRVANY.EXE to the PumpKIN directory
  • Run INSTSRV.EXE tftp "<PumpKIN install dir>\SRVANY.EXE"
  • Run regedt32
  • In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tftp create a key called "Parameters" (no quotes)
  • In the new "Parameters" Key, create a string value "Application"
  • Double click the new "Application" and enter "<PumpKIN install dir>\PumpKIN.exe" (no quotes)
• Configuration
  • Open Services Console and find the service tftp
  • Right click tftp, ask for properties
  • Click Log On tab and mark "Allow Service to interact with desktop"
  • Start the service — PumpKIN interface will popup
  • Configure PumpKIN to your liking and remove any prompting for confirmations.
  • Stop the service and back to properties
  • Click Log On tab and uncheck "Allow Service to interact with desktop"
  • Start the service again, all should work.
• Done.

There are no command line options to set the path to tftp root. As for the way to save options, PumpKIN does save options each time it's properly shut down.

It seems like it is a Linksys proprietary extension. I do not have any information on how do they do it, but if I get time and will find out I'll add the functionality to PumpKIN.

The problem here is the very idea of using tftp protocol to transfer large files. TFTP protocol operates on 512 bytes long blocks and uses a 16 bits word to count blocks, which effectively prevents protocol from being used for files that large. You can raise the limit a bit by using block size option if both ends support it.

This is a message from remote server, i.e. Linux tftp server. Here is an excerpt from the manpage:

Due to the lack of authentication information, tftpd will allow only publicly readable files to be accessed. Files may be written only if they already exist and are publicly writable.

My guess is - this is not the case.

Yes, it does, but for the option to work both sides has to support it.

If there is no check on the other endpoint consistency it may lead to data corruption, since it may receive the data from the other stream and there is no integrity check in tftp. It can only happen if the other side of the first transfer isn't aware of connection termination. I wouldn't recommend it, especially if the same TID may be assigned twice on both sides.

There is no particular limit set. Basically, it depends on your resources. And it is not likely that you hit this limit either, in real life. We have not stress-tested PumpKIN, though, to give you any estimation. If you test it, your feedback is welcome.

As a result of our email exchange we have found that this may happen if you have a few overlapping interfaces set up. I am not sure whether this is a bug in PumpKIN, yet. Disabling offending interfaces (all but one) seems to help.

First of all, let me warn you that I have never seen Solarwinds TFTP and have absolutely no idea what keyboard input it is supposed to accept. So, I will have to guess.

And my guess is that solarwinds is a tftp server, not client. Which means that it accepts input from the network, not from the user.

PumpKIN combines both client and server. Which means that you can either invoke transfer from the network or initiate transfer from your machine in either direction. This is what 'get file' and 'put file' are for.

As for the tftp commands provided with XP, I also lack any knowledge here, but I suppose this is where you 'connect' to the server and then either 'put' or 'get' files.

The error message means that PumpKIN received TFTP packet it did not expect. If you want more details, read the corresponding RFC.

All versions of PumpKIN are free for everyone, even government.

Although everyone (including government) may express their gratitude monetarily by donating money to the developer.

None that I know of, but you should make sure there is no other tftp service running.

There is no such thing. I think you're talking about passive ftp, which PumpKIN has nothing to do with.

Not yet.

Unfortunately, I have no idea what you're asking about.

There is no particular limit set, but the one that is imposed by your server/network capacity.

Only in PumpKIN window, I think. But it should show the reason if it denies request. Most likely access control, if a different file works...

PumpKIN itself doesn't have any access control. Nothing prevents you from using external firewall, though.

Depends on what do you mean. If you're asking about your own ip, maybe properties of network connection is what you're looking for.

TFTP is certainly not the fastest protocol and depending on how slow they get it may be due to the protocol.

Naturally, failed transfers are not exactly what tftp is designed for and I can not guarantee that PumpKIN has no bugs which can lead to this experience. On the other hand if other implementations exhibit similar behavior it is likely that the problem lies outside the tftp implementation.

Unfortunately, at this point PumpKIN provides no way to automate these tasks. Thank you for your suggestion.

69 by default.

PumpKIN stores configuration data in registry. Search for 'Klever Group' there. So, it's likely that you will want to create a .reg file for this purpose.

Yes. It's right here. Also, you might have overlooked, that we have set up the site dedicated to our KIN software, including pumpkin, which is available at http://kin.klever.net/, or have you seen it?

For what I know, it does, except for the help file, because old help files do not work on Vista anymore. Help is available at http://kin.klever.net/pumpkin/help though.

It is my belief, that reading the proper page before submitting question sometimes helps.

Hello. It sounds like the router didn't really understand the blocksize option. You set it in options, but do you see the block increase when the actual transfer happens?

And don't be shy, you could've left your email (unwilling to make it public), now you can email me directly so that we can discuss the problem via e-mail. If you want, of course.

I am afraid, there isn't enough information to diagnose the problem. If you really wish to find something out, try emailing me or using feedback form (not FQA) and fill in your email address.

After a short email exchange we found out it was firewall on the SuSE box.

TFTP does not have authentication mechanism, so if your hardware uses some proprietary extension, PumpKIN, probably, doesn't have it implemented (yet?).

This is the error returned by underlying OS. You should make sure pumpkin is entitled to acess the file in question.

It pumps the files and it's KIN!

What is download.bin file, anyway?

Not at the moment, but it's easy to implement and the code is open.

TFTP has no authentication mechanism defined. There are linksys extensionsm, but PumpKIN does not implement it.

I don't think I can tell you much here, as it seems to be an issue with your Linksys and/or VPN router. I do not see why Linksys would want to use different transfer types, so it does sound like intrusive router's behaviour. But that's about all I can say on the matter.

It means, the PumpKIN can not read the file due to windows access restrictions.

No, it is not designed. PumpKIN saves settings on normal shutdown. Could it be that your machine crashed before you had a chance to close PumpKIN?

Originally developed for Windows 95, PumpKIN reportedly works on all Win32 systems (Windows 95, Windows 98, Windows NT, Windows XP, etc.).

Sorry, I have no idea. There may be tons of reasons for your network slowdown.

filesize/blocksize should be less than 65536.

Well, you have two problems:

• You already have tftp server running
• tftp works over network, not serial port

Undefined answer.

Is your PumpKIN server set to deny requests? Is file readable by user running PumpKIN?

The Internet.