Bug 1023645 - tftpd launched by systemd tftp.socket does not respond from secondary IP addresses
tftpd launched by systemd tftp.socket does not respond from secondary IP addr...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: tftp (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-26 08:57 EDT by Andrew J. Schorr
Modified: 2017-05-10 18:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-19 03:01:46 EST
Type: Bug
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 Andrew J. Schorr 2013-10-26 08:57:43 EDT
Description of problem: If you run "systemctl enable tftp.socket" on a system
with multiple IP addresses,  the server does not respond from the correct IP
address.  In my case, there is a VRRP secondary address on an interface.
If the client connects to the secondary VRRP address, the server responds
from the primary address on that interface.  When tftpd is launched from
xinetd, it works properly.  When run from systemd, we see error messages
like this in the logs:
Oct 26 02:46:16 ti120 in.tftpd[28414]: [ID daemon.warning] tftpd: read(ack): Connection refused
The client is unable to retrieve files because it expects the response
to come from the secondary IP address that it contacted.



Version-Release number of selected component (if applicable):
tftp-server-5.2-9.fc19.x86_64


How reproducible:
Enable the tftp server with "systemctl enable tftp.socket", assign a
secondary IP address using "ip addr add", and then tftp from a client
to the secondary IP address and try to retrieve a file.  It will not
succeed.


Steps to Reproduce:
1. assign a secondary IP address using "ip addr add"
2. enable the tftp server with "systemctl enable tftp.socket"
3. on a client host, connect to the secondary IP address and try to retrieve a file.

Actual results:
The file retrieval fails.  tcpdump shows that the server does not respond
from the correct address.


Expected results:
The client should be able to retrieve a file.  tftpd should respond from
the address on which it was contacted.

Additional info:
Comment 1 Andrew J. Schorr 2013-10-28 14:05:45 EDT
The problem seems to be related to the IPv4 to IPv6 mapping.  With this patch to tftp.socket, everything works properly on my network (which is using IPv4):

--- usr/lib/systemd/system/tftp.socket.orig     2013-04-23 03:43:43.000000000 -0400
+++ usr/lib/systemd/system/tftp.socket  2013-10-28 13:59:28.125950493 -0400
@@ -2,7 +2,7 @@
 Description=Tftp Server Activation Socket
 
 [Socket]
-ListenDatagram=69
+ListenDatagram=0.0.0.0:69
 
 [Install]
 WantedBy=sockets.target

I don't know how to fix this in the general case.  It would be nice if systemd had a setting BindIPv4Only.  Perhaps the tftpd code can be patched to handle this case properly, but I do not know exactly what is going wrong with the v4 to v6 mapping.
Comment 2 Jan Synacek 2013-11-01 05:35:30 EDT
I don't think this patch would work for ipv6 connections.

Try adding

ListenDatagram=[::]:69
BindIPv6Only=both

or any combination of the two (BindIPv6Only should default to "both", but just to be sure...) to the tftp.socket file if that helps.
Comment 3 Jan Synacek 2014-02-19 03:01:46 EST
This bugzilla has gone without response for about 3 months now. Closing.
Comment 4 Andrew J. Schorr 2014-02-19 08:37:28 EST
I do not have IPv6 infrastructure, so I cannot test that aspect.  I can only tell you for sure that the tftp.socket file does not work as shipped.  I do not see why you closed the bug.  A fix is required.
Comment 5 Stephen Quinney 2016-08-16 09:53:46 EDT
(In reply to Andrew J. Schorr from comment #4)
> I do not have IPv6 infrastructure, so I cannot test that aspect.  I can only
> tell you for sure that the tftp.socket file does not work as shipped.  I do
> not see why you closed the bug.  A fix is required.

I am still seeing this problem with 5.2-12.el7 on EL7.2

I've tried BindIPv6Only=both with various formats for the value of the ListenDatagram option but the only way to get IPv4 support to work is to specify 0.0.0.0:69 which seems to contradict the details given in the systemd.socket manual page.


Stephen Quinney
Comment 6 tschneider 2017-05-10 18:33:05 EDT
I am also seeing this issue

[root@localhost ~]# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

I discovered this issue while PXE booting. My PXE server has multiple NICs and hosted a tftp and dhcp server. On the first boot, when a client had no dhcp lease, the client would successfully negotiate the dhcp information tftp files. If a dhcp client were to PXE boot a second time, the tftp server would not respond. In the /var/log/messages I could see the incoming requests etc but when I used tshark to sniff the traffic I saw no outbound messages from the server.

This issue was fixed with Andrew J. Schorr's suggestion and a little research. I have changed by configurations to be as follows:

ListenDatagram=0.0.0.0:69

I think this issue should be reopened. At the very least I think the default configurations should be changed.

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