[syslinux] truncated files on write with tftpd-hpa
asundell+syslinux at fas.harvard.edu
Wed Jul 9 12:46:34 PDT 2003
On Thu, May 01, 2003 at 06:52:46PM -0400, Alan Sundell wrote:
> Occasionally, when one of our switches uploads its config with TFTP, we
> end up with a 0-byte file.
> It seems to me like the problems I'm seeing could be avoided on the
> tftpd side in one (or both) of two ways:
> 1) not truncating the file until the first data packet is received
> 2) not responding to a second WRQ with the same host+port within some
> period (since the TIDs should be chosen such that they are unlikely to
> repeat, if I read the RFCs correctly).
Hey, remember this issue? I've done some things to mitigate the NIS
delays on the server side, but AFAIK, the possibly of data loss from a
truncated file due to network or other delays still exists.
Back then, I wrote a couple of quick and dirty patches against
tftp-hpa-0.3.4 to test out numbers 1) and 2) above. (Haven't had time
to think about this issue much since then, hence the long delay.)
Either one seemed to fix the problem, and they both seemed to confirm my
theory of what was going on here (that the re-transmitted request caused
the truncation of the file on open).
I've attached the two patches to this message. They are, as I said,
quick and dirty, but they should give you an idea of what I'm talking
The late-truncate patch should be harmless, and I would like to see
something like it get applied, since it will solve our data loss
The request-tracking patch is harmless for clients that choose a
different TID for every request, but will of course cause problems if
clients re-use TIDs within a short period of time. Since it may cause
problems with some clients, is a bit pedantic, and requires ugly
additions to the code, it's probably a less-advisable way to go.
What do you think?
Interestingly, as a footnote, "some clients" above includes the client
in tftp-hpa. To give some context, the RFC says:
| 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.
However, the client in tftp-hpa opens a socket once in main() and
re-uses it for all subsequent requests. Therefore the probability
that a single invocation of the client will chose the same "TID"
(port) twice in immediate succession is 1.
Whether this causes any practical problems with any TFTP servers out
there, I don't know. It doesn't cause me any trouble, like the
truncation does -- I just noticed it in passing and thought I would
point it out in case it causes anyone else any grief.
Thanks again for your help with this,
More information about the Syslinux