I believe I have encountered a problem with tftpd-hpa very similar to the
problem described in the following link:
http://syslinux.zytor.com/archives/2003-May/001955.html
We were running tftpd-hpa version 0.29 on RedHat 8.0 (on an older Dell desktop),
and upgraded to tftpd-hpa version 0.42 when the problem was discovered; however,
we are seeing the same thing after the upgrade.
The TFTP client I am using times out after 500ms (it is a client on an embedded
device so I cannot provide an example). Occasionally, after a write request is
sent, the client times-out and resends the write request. The TFTP server ends
up responding to both requests, and the log reads:
Mar 30 19:49:57 pderob019 in.tftpd[30818]: WRQ from 172.22.194.248 filename
pderob224/bak/from00.img
Mar 30 19:50:01 pderob019 in.tftpd[30828]: WRQ from 172.22.194.248 filename
pderob224/bak/from01.img
Mar 30 19:50:01 pderob019 in.tftpd[30830]: WRQ from 172.22.194.248 filename
pderob224/bak/from01.img
Mar 30 19:50:05 pderob019 in.tftpd[30832]: WRQ from 172.22.194.248 filename
pderob224/bak/from02.img
Mar 30 19:50:06 pderob019 in.tftpd[30830]: tftpd: read: Connection refused
So in this case the file from01.img was opened twice--and a read error is always
printed a little later. The end result is the file (from01.img in this case) is
the correct size, but contains only zeros (in the binary sense). I verified
through ethereal that the correct data was actually sent. I have the capture
file if it would help clear things up.
Re-reading the TFTP RFC I don't see anything that indicates the client is
doing anything wrong by re-sending the write request... Is this a legitimate bug
with tftp-hpa?
Thanks in advance for any help.
