Bug 55789

Summary: tftpd over IPv4 does not work with IPv6 enabled
Product: [Retired] Red Hat Raw Hide Reporter: Joerg Dorchain <joerg>
Component: tftpAssignee: Elliot Lee <sopwith>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: hpa, pekkas, tomek
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-06-17 21:58:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joerg Dorchain 2001-11-06 18:09:26 UTC
Description of Problem:
tftpd fails with strange errors message

Version-Release number of selected component (if applicable):
tftp-server-0.17-14

How Reproducible:
Always

Steps to Reproduce:
1.  Set up IPv6 networking (add NETWORKING_IPV6=yes to
/etc/sysconfig/network so that xinetd-ipv6 is started)
2. try to get a file

I logfile excerpt with first a working transfer via xinetd and then a
failed transfer via xinetd-ipv6 looks like this:

Nov  6 18:53:32 dorchain xinetd[25937]: xinetd Version 2.3.3 started with
libwrap options compiled in.
Nov  6 18:53:32 dorchain xinetd[25937]: Started working: 6 available
services
Nov  6 18:53:35 dorchain xinetd: xinetd startup succeeded
Nov  6 18:53:48 dorchain in.tftpd[25950]: sending
/tmp/c6msfc-pk2sv-mz.121-5a.E.bin
Nov  6 18:57:50 dorchain xinetd[25937]: Exiting...
Nov  6 18:58:08 dorchain xinetd-ipv6[26149]: xinetd Version 2.3.3 started
with ipv6 libwrap options compiled in.
Nov  6 18:58:08 dorchain xinetd-ipv6[26149]: Started working: 6 available
services
Nov  6 18:58:11 dorchain xinetd: xinetd-ipv6 startup succeeded
Nov  6 18:58:33 dorchain in.tftpd[26329]: sending
/tmp/c6msfc-pk2sv-mz.121-5a.E.bin
Nov  6 18:58:33 dorchain in.tftpd[26329]: tftpd: read(ack): Connection
refused

An strace gives the suspicion that tftpd is trying to interpret an  IPv6
socket structure as an IPv4 one.

As a side note,  it seems the talkd has similiar problems, but that a
different topic.

Comment 1 Elliot Lee 2001-12-18 22:26:28 UTC
tftp doesn't support IPv6, period. Please talk to the author
(hpa+rhbugs) about getting this implemented.

Comment 2 Pekka Savola 2002-02-14 09:41:31 UTC
No, the problem here is (confirmed by me) that tftp over IPv4 does not work if
xinetd
is v6-enabled.

It works over localhost (source and destination are the same), but not
otherwise; e.g.:

11:24:41.635054 nalle.1896 > netcore.fi.tftp:  20 WRQ "nalle-confg"
11:24:41.641243 netcore.fi.4726 > netcore.fi.1896: udp 4 (DF)
11:24:41.641382 netcore.fi > netcore.fi: icmp: netcore.fi udp port 1896
unreachable [tos 0xc0] 
11:24:45.637429 nalle.1896 > netcore.fi.tftp:  20 WRQ "nalle-confg"
11:24:45.643871 netcore.fi.4726 > netcore.fi.1896: udp 4 (DF)
11:24:45.644004 netcore.fi > netcore.fi: icmp: netcore.fi udp port 1896
unreachable [tos 0xc0] 

note netcore.fi.1896 in the second line instead of nalle.1896!


Comment 3 Pekka Savola 2002-02-14 11:49:13 UTC
It would appear that this affects UDP services only probably due to differences 
how socket interface works.

Comment 4 Phil Knirsch 2002-03-12 13:27:01 UTC
So, is there a 'possible' fix for this, is this more a kernel problem or just
something that won't work?

Read ya, Phil

Comment 5 Pekka Savola 2002-03-12 22:19:59 UTC
There seem to be about four possible courses of action I see:

 1) rewrite parts of xinetd so that you can specify which services you want to enable IPv6 for and which not.  A huge task, I fear.
 2) rewrite parts of tftpd so that it recognizes the IPv6 socket structures fed to it from xinetd and works from that.  Some patches
      already exist in OpenBSD tree (http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/tftpd/tftpd.c , R1.21), but they'd require some adaptation
      for Linux as it works a bit differently.
 3) don't start xinetd in IPv6 mode if UDP services are running unless explicitly requested, or in some way make the problem smaller.
 4) ignore the problem now, possibly adding documentation in a README somewhere or the like -- IPv6 people are still rather marginal.



Comment 6 Pekka Savola 2002-03-13 12:06:03 UTC
tftp-hpa is so bloated and diverged from OpenBSD now so I wouldn't want to
bother
to try to fix it.

Instead I ported NetBSD tftp and tftpd (both work with IPv4 and IPv6) to Linux..
If that's any consolation :-)

They're available (incl. src.rpm) at http://www.netcore.fi/pekkas/linux/ipv6/

Comment 7 Joerg Dorchain 2002-03-13 12:36:41 UTC
For tftp that's the best solution.

For your xinetd proposal, IMHO there should be a possibility to get an IPv4-only
socket from xinetd-ipv6, i.e. your proposal 1) (Can't be that difficult, e.g by
having protocol = udp4)
For the applications, like tftp,  proposal 2) is best.
3) adds more problems than it solves (e.g. violates the least-surprise-priciple)
4) won't make the distro progress (And, BTW, I absolutely don't feel marginal
;-)

This concrete bug could be considered solve by your tftp rpm. But then I have
the same problems with comsat(biff)...

Comment 8 Pekka Savola 2002-03-13 12:40:58 UTC
For your xinetd proposal, IMHO there should be a possibility to get an IPv4-only
 socket from xinetd-ipv6, i.e. your proposal 1) (Can't be that difficult, e.g by
 having protocol = udp4)

==> have a look at xinetd source... It won't be pretty :-)

This would be a preferred approach anyway, but lots of work..

Comment 9 Elliot Lee 2002-06-17 21:58:12 UTC
Going to try Cc'ing the author on this bug...

Comment 10 Elliot Lee 2002-10-23 20:10:44 UTC
added 'flags = IPv4' to tftp-xinetd. I think that should solve it