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 :-(

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 | |
  • 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 '13 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 '13 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 '13 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 '13 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 '13 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 | |
  • He is using the -c option, so the existence of the file is not required. – Kyle Smith Mar 21 '13 at 16:41
  • I'm aware of that move and I am working with /var/lib/tftpboot – chriscowley Mar 21 '13 at 21:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.