0

I can put a file successfully from localhost. If I try from another host the client connects and the file is created on the server, but it is empty. The transfer then times out a little later.

On the client I can run one of the following with the same result:

tftp <server> -c put install.log
tftp <server> -c put install.log install.log
tftp <server> -c put install.log /install.log

SELinux is in permissive mode, and IPtables is currently off.

Contents of /etc/xinetd.d/tftpd:

service tftp
{
    socket_type             = dgram
    protocol                = udp
    wait                    = yes
    user                    = root
    server                  = /usr/sbin/in.tftpd
    server_args             = -v -c -s /var/lib/tftpboot
    disable                 = no
    per_source              = 11
    cps                     = 100 2
    flags                   = IPv4
}

/tftproot has got 777 permissions.

In /var/log/messages I get:

Mar 21 17:10:30 <hostname> in.tftpd[29093]: WRQ from <client_ip> filename install.log
Mar 21 17:10:35 <hostname> in.tftpd[29093]: WRQ from <client_ip> filename install.log
Mar 21 17:10:40 <hostname> in.tftpd[29093]: WRQ from <client_ip> filename install.log
Mar 21 17:10:45 <hostname> in.tftpd[29093]: WRQ from <client_ip> filename install.log
Mar 21 17:10:50 <hostname> in.tftpd[29093]: WRQ from <client_ip> filename install.log

Been banging my head against this brick wall all afternoon. Someone please put me out of my misery. I know it will be something really stupid :-(

Improve this question

3 Answers 3

Reset to default
2

Found the problem

It was the VMware NIC type. I was using the VNXNET3, once I changed to E1000 everythings works as expected. Apparently, the problem still exists in vSphere 5.

http://communities.vmware.com/thread/215456

Improve this answer
1

I think this is MTU/fragmentation problem. Small packets between client and servers travel without problem, so server know filename. Large is blocked somewhere.

You sholud use -B max-block-size flag with minimum block size (512) for server and if this fix the problem then also try bigger one (~1460 is good one for Ethernet with 1500 MTU, but if you have IPSec/VPN between client and server then ~1350 may be better).

Improve this answer
7
  • If this not the answer then check firewall on client side - if you block UDP from server to client result will be probably same - track option in client can help.
    – dsznajder
    Mar 22, 2013 at 6:44
  • Interesting, I like solutions that are somebody else's problem :) Sadly I work in a heavily Silo'ed environment - 'aint no DevOps here :-(
    – chriscowley
    Mar 22, 2013 at 12:57
  • No such joy there. I set the block size to 512 and get exactly the same result. The Windows people will start laughing at me soon
    – chriscowley
    Mar 22, 2013 at 14:43
  • @chriscowley Could you tell more detail of network between client and server? Is there NAT somewhere? Firewall? (tftp is not firewall-friendly ) Could you try add --port-range 69:69 option to tftpd config?
    – dsznajder
    Mar 22, 2013 at 15:05
  • The TFTP server is VM on an ESXi 4.1 server, connected to a standard vSphere vSwitch. This is in turn connected to a Cisco 3560, which is currently the device we are trying to backup.
    – chriscowley
    Mar 25, 2013 at 9:15
0

In EL6, the default tftp directory changed from /tftpboot to /var/lib/tftpboot.

Make sure you have a file in the destination directory with 666 permissions on the file.

Improve this answer
2
  • He is using the -c option, so the existence of the file is not required.
    – Kyle Smith
    Mar 21, 2013 at 16:41
  • I'm aware of that move and I am working with /var/lib/tftpboot
    – chriscowley
    Mar 21, 2013 at 21:11

You must log in to answer this question.

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