Bug 787689

Summary: tftp-server does not work with kernels newer than 2.6.32-131.21.1.el6.x86_64
Product: Red Hat Enterprise Linux 6 Reporter: Dario Palmisano <Dario.Palmisano>
Component: tftpAssignee: Jiri Skala <jskala>
Status: CLOSED WORKSFORME QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0CC: aglotov, eric.denicolai
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-16 12:28:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
strace output when running kernel-2.6.32-131.21.1.el6.x86_64
none
strace output when running kernel-2.6.32-220.4.1.el6.x86_64 none

Description Dario Palmisano 2012-02-06 14:30:19 UTC
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.

Comment 2 Dario Palmisano 2012-02-07 07:42:18 UTC
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.

Comment 3 Dario Palmisano 2012-02-07 07:46:19 UTC
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.

Comment 5 Suzanne Logcher 2012-02-14 23:31:05 UTC
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.

Comment 6 Jiri Skala 2012-02-16 08:45:09 UTC
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?

Comment 7 Dario Palmisano 2012-02-16 09:35:39 UTC
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.

Comment 8 Jiri Skala 2012-02-16 12:28:59 UTC
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.

Comment 9 Dario Palmisano 2012-02-16 13:29:22 UTC
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

Comment 10 Eric DENICOLAI 2012-02-28 13:17:36 UTC
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...