4

I know this isn't the purpose of TFTP, but I'm working in an environment where a lot of different types of devices pull provisioning info from a TFTP server. What I'm developing is a provisioning system that tracks and maintains device configurations, and I would like to have the requested files generated on the fly, much like you could do with any web application.

Yes some of these devices can support HTTP for provisioning, but not all of them do, and we want things to be consistent.

Are there any TFTP daemons that can provide something analogous to CGI?

3 Answers 3

2

A quick search revealed this tftpd-cgi project on Sourceforge - might be worth checking out.

I also just wrote a simple tftpd server capable of serving CGI, available on Github, so it's definitely possible. I haven't tested with any PXE clients yet, but it does work with my operating system's tftp client.

My test usage:

./tftpd-cgi.py &

echo 'get cgi/test' | tftp 127.0.0.1; cat test && rm test

Which outputs from my simple CGI script:

Hello from CGI land!
127.0.0.1:61796
2
  • This is cool, I'd love to see where you go with this. I checked out the tftpd-cgi project already but it seemed rather incomplete. Jun 29, 2011 at 23:36
  • +1 for being super gung-ho & exploratory by the way! Jun 29, 2011 at 23:40
5

This is addressed here. Sadly, it seems to be difficult or impossible, given the constraints on the TFTP protocol.

> Hi.
>
> Has there ever been any consideration to allowing the tftp server to
> provide dynamic content?
>

Yes. The protocol makes it difficult.

You pretty much have to guarantee that the contents is generated in a fraction of a second, or your client will most likely flood your server.

The problem is that in order to be able to answer a tsize query you have to know the full size of the output. However, since TFTP isn't guaranteed to distinguish between an RRQ resend and a new request (pxelinux will make the distinction, but it's hard for the TFTP server to make use of it), so you have to have a reply before the first request.

I have a proposal for a TFTP "pause" option and opcode, but I would have to (a) implement it, and (b) write it up as an RFC, (c) figure out how to get it through IETF, which like to pretend TFTP doesn't exist.

1
  • 1
    Based on experiments and reading the thread further, this is definitely possible with the tftp client on my system. You simply stash the first request (and discard any duplicate requests), then reply when your cgi script finishes. As long as the cgi script finishes before the tftp client times out internally, the client can receive its output in response to any of the requests and won't complain. I'm working on a proof of concept and will update my answer when finished.
    – lunixbochs
    Jun 25, 2011 at 20:01
3

A better design would be to generate all config files and cache them in the tftpboot directory rather than trying to generate them on the fly. Ideally the filename your devices request would be unique or identifiable and you could pre-generate files based on that.

2
  • This is how tftp is usually used. If many devices can share a configuration, generate it once and make symlinks to it for each device.
    – TomOnTime
    Jun 26, 2011 at 2:10
  • While I typically agree with both of you, I'm dealing with a somewhat unique case provisioning a lot of devices that may or may not be inheriting one or more classes of parent configurations, all of which may be changed somewhat frequently. The majority of these devices do support HTTP for provisioning, but a couple do not, and others are only half way there. Jun 29, 2011 at 23:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .