Hide Forgot
Description of problem: I am using Scientific Linux 6.0 (a free Red Hat Enterprise Linux derivative), in a virtualized environment. When with tftp client I try to save a file to the tftp-server, the client times out (and the target file is zero bytes) when the system is running a kernel that is older than 2.6.32-131.21.1.el6.x86_64. I verified the problem on a server using ip aliases, but also on a freshly installed server where ip aliases are NOT used. Version-Release number of selected component (if applicable): Recompiled and installed tftp-5.2.2.fc16.src.rpm # /usr/sbin/in.tftpd -V tftp-hpa 5.2, with remap, with tcpwrappers How reproducible: Always. When I boot with kernel-2.6.32-131.21.1.el6.x86_64 it works fine. When I boot with kernel-2.6.32-220.4.1.el6.x86_64 it times out. Steps to Reproduce: 1. Installed a fresh server. Disabled selinux, iptables, ip6tables. Installed latest kernel (kernel-2.6.32-220.4.1.el6.x86_64) and older (kernel-2.6.32-131.21.1.el6.x86_64). Created target file /var/lib/tftpboot/xxx world-writeable. 2. When the system hosting the tftp-server runs kernel-2.6.32-131.21.1.el6.x86_64 and from client: $ tftp 140.105.9.20 tftp> trace Packet tracing on. tftp> put xxx sent WRQ <file=xxx, mode=netascii> received ACK <block=0> sent DATA <block=1, 372 bytes> received ACK <block=1> tftp> quit $ 3. When the system hosting the tftp-server runs kernel-2.6.32-220.4.1.el6.x86_64 and from client: $ tftp 140.105.9.20 tftp> trace Packet tracing on. tftp> put xxx sent WRQ <file=xxx, mode=netascii> sent WRQ <file=xxx, mode=netascii> sent WRQ <file=xxx, mode=netascii> sent WRQ <file=xxx, mode=netascii> sent WRQ <file=xxx, mode=netascii> Transfer timed out. tftp> quit $ Actual results: The target file on the server is reset to 0 bytes. Expected results: The target file is tranferred and the size of the source and target are equal. Additional info: I made similar tests using a CISCO router as client with the same results, it can save the files only if the server is using the oldest kernel. This was the original need for tftp service.
Created attachment 559855 [details] strace output when running kernel-2.6.32-131.21.1.el6.x86_64 This is the strace output of tftpd when the system is running kernel-2.6.32-131.21.1.el6.x86_64. This is provided as sample when tftpd works fine.
Created attachment 559856 [details] strace output when running kernel-2.6.32-220.4.1.el6.x86_64 This is the strace output of tftpd when the system is running kernel-2.6.32-220.4.1.el6.x86_64. This is provided as sample when tftp (client) times out, tftpd reset the size of the target file to 0.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
I don't observe described difficulties using kernel-2.6.32-220.el6.x86_64. Everything works fine for me. I went through your strace logs. What about your glibc's version?
I suspected from the silence on my request that I was using something specific. Yesterday I installed a (physical) computer and verified that the problem in this set up does not show up. The bug I submitted appears as I described it, when I use a virtual machine (on a VMware 4.1 host). I expected, erroneusly, should not make any difference if phisical or virtualized installation. Now I suppose you will close the bug, because possibly the bug is inside the virtualization software. I would understand that position, but I would to repeat that it worked fine up to kernel-2.6.32-131.21.1.el6.x86_64 and no change was done to the virtualization software. If you are interested in further investigations I will be available to provide you details. I will try to submit the bug to VMware too.
Thanks for response and additional info. I tested it on native RHEL-6 machine firstly. I verified functionality on virtual (kvm) machine after reading comment #7. This works fine for me. So I guess there could be some troubles with VMware.
Dear Sir, I can confirm that a virtualized server (with VirtualBox) does not show the bug I submitted. I agree with you that the problem should be, somehow, caused by VMware. Thanks for you kind cooperation Best regards Dario
Hi there, As I've got the same bug as Dario, I share these link found here : https://access.redhat.com/knowledge/solutions/67823 "This bug is considered as a know issue. Workarounds Replace VMXNET3 adapter with Intel e1000 adapater Downgrade to RHEL 6 update 1 kernel" This is a problem with Vmware VMXNET3 driver. I tried the last update for ESX servers => same problem. Should be useful for some people...