Bug 801308 - tftp doesn't work if flags=IPv6 in xinetd configuration
tftp doesn't work if flags=IPv6 in xinetd configuration
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tftp (Show other bugs)
7.0
All Linux
high Severity high
: rc
: ---
Assigned To: Jiri Skala
gradeA, RHTSdone=/CoreOS/tftp/Regress...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-08 04:18 EST by Miroslav Vadkerti
Modified: 2014-11-09 17:35 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-12 11:12:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Vadkerti 2012-03-08 04:18:26 EST
Description of problem:
# cat /etc/xinetd.d/tftp 
service tftp
{
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s /var/lib/tftpboot
	disable			= no
	per_source		= 11
	cps			= 100 2
	flags			= IPv6
}

# service xinetd restart

# ls /var/lib/tftpboot
tst

# tftp -6 ::1
tftp> trace on
Packet tracing on.
tftp> verbose on
Verbose mode on.
tftp> get tst
getting from ::1:tst to tst [netascii]
sent RRQ <file=tst, mode=netascii>
sent RRQ <file=tst, mode=netascii>
sent RRQ <file=tst, mode=netascii>
sent RRQ <file=tst, mode=netascii>
sent RRQ <file=tst, mode=netascii>
Transfer timed out.
[transfer will never finish]

Version-Release number of selected component (if applicable):
tftp-server-5.1-1.el7.x86_64
tftp-5.1-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
see description
  
Actual results:
Cannot download file with tftp client

Expected results:
No issues downloading file

Additional info:
This worked in RHEL6. The testcase works for both IPv4 and IPv6 if I use flags=IPv4
Comment 1 Jiri Skala 2012-03-12 11:12:11 EDT
I tested the issue on 10.34.25.2 (dhcp-25-173.brq.redhat.com 3.2.1-0.8.el7.x86_64) and it works fine for me.

Note You need to log in before you can comment on or make changes to this bug.