Your message dated Sat, 22 Nov 2025 17:34:42 +0000
with message-id <[email protected]>
and subject line Bug#1108702: fixed in tftp-hpa 5.3+20251116-1
has caused the Debian Bug report #1108702,
regarding tftpd-hpa: communication error when running on multi-homed servers
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1108702: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108702
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: tftpd-hpa
Version: 5.2+20240610-3
Severity: important
X-Debbugs-CC: [email protected]
Tags: patch
Dear tftpd-hpa maintainers,
When tftpd is deployed on servers with multiple addresses, if the client
is reaching the server via an address which is not preferred as a source
address when the server is sending the replying packets, the communication
will fail, since the client is receiving packets from unexpected source
address and rejecting them.
This can be reproduced using the following steps:
# create a netns and create a pair of veths
ip netns add ns1
ip link add veth1 type veth peer name veth2
ip link set veth1 up
ip link set veth2 netns ns1 name eth0 up
# assign two IPs for veth1
ip addr add 10.0.0.1/24 dev veth1
ip addr add 10.0.0.2/24 dev veth1
# assign one IP for eth0 in ns1
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip addr add 10.0.0.3/24 dev eth0
# put some file in /srv/tftp, the file should be larger than 1 transfer block
seq 1 1024 > /srv/tftp/foo
# start the server
in.tftpd --listen --foreground --address 0.0.0.0 --secure /srv/tftp
# try to download the data within ns1
ip netns exec ns1 tftp 10.0.0.1
tftp> get foo
# it works normally
# try to download the data within ns1, but use the secondary IP of the server
interface
ip netns exec ns1 tftp 10.0.0.2
tftp> get foo
# it will get stuck
By capturing the traffic, we can see tftpd is trying to send response
packets to 10.0.0.3 from 10.0.0.1 instead of 10.0.0.2 and is also unable to
receive the ACK packets from the client.
tcpdump: listening on veth1, link-type EN10MB (Ethernet), snapshot length
262144 bytes
13:32:53.760731 IP (tos 0x0, ttl 64, id 18689, offset 0, flags [DF], proto UDP
(17), length 43)
10.0.0.3.49134 > 10.0.0.2.69: [bad udp cksum 0x142d -> 0x9683!] TFTP,
length 15, RRQ "foo" netascii
13:32:53.761375 IP (tos 0x0, ttl 64, id 62903, offset 0, flags [none], proto
UDP (17), length 544)
10.0.0.1.47636 > 10.0.0.3.49134: [bad udp cksum 0x1621 -> 0x86b8!] UDP,
length 516
13:32:53.761454 IP (tos 0x0, ttl 64, id 18690, offset 0, flags [DF], proto UDP
(17), length 32)
10.0.0.3.49134 > 10.0.0.2.47636: [bad udp cksum 0x1422 -> 0x71c9!] UDP,
length 4
13:32:53.761464 IP (tos 0xc0, ttl 64, id 49801, offset 0, flags [none], proto
ICMP (1), length 60)
10.0.0.2 > 10.0.0.3: ICMP 10.0.0.2 udp port 47636 unreachable, length 40
IP (tos 0x0, ttl 64, id 18690, offset 0, flags [DF], proto UDP (17), length 32)
10.0.0.3.49134 > 10.0.0.2.47636: [bad udp cksum 0x1422 -> 0x71c9!] UDP,
length 4
13:32:54.767567 IP (tos 0x0, ttl 64, id 62904, offset 0, flags [none], proto
UDP (17), length 544)
10.0.0.1.47636 > 10.0.0.3.49134: [bad udp cksum 0x1621 -> 0x86b8!] UDP,
length 516
13:32:54.767706 IP (tos 0x0, ttl 64, id 18845, offset 0, flags [DF], proto UDP
(17), length 32)
10.0.0.3.49134 > 10.0.0.2.47636: [bad udp cksum 0x1422 -> 0x71c9!] UDP,
length 4
13:32:54.767720 IP (tos 0xc0, ttl 64, id 49804, offset 0, flags [none], proto
ICMP (1), length 60)
10.0.0.2 > 10.0.0.3: ICMP 10.0.0.2 udp port 47636 unreachable, length 40
IP (tos 0x0, ttl 64, id 18845, offset 0, flags [DF], proto UDP (17), length 32)
10.0.0.3.49134 > 10.0.0.2.47636: [bad udp cksum 0x1422 -> 0x71c9!] UDP,
length 4
The root cause of this problem is during the upstream refactoring the autoconf
system, some feature test macros are left out, so the function myrecvfrom()
cannot properly obtain the local address used to receive the packets from the
client.
I have posted patch series to fix this problem to the upstream [1]. The second
patch in the series can also fix another problem inside myrecvfrom() that
prevents the above setup from working, which I'd like to have it into stable-pu.
[1]: https://www.syslinux.org/archives/2025-July/026938.html
Cheers,
Miao Wang
--- End Message ---
--- Begin Message ---
Source: tftp-hpa
Source-Version: 5.3+20251116-1
Done: Chris Hofstaedtler <[email protected]>
We believe that the bug you reported is fixed in the latest version of
tftp-hpa, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Chris Hofstaedtler <[email protected]> (supplier of updated tftp-hpa package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 22 Nov 2025 17:45:30 +0100
Source: tftp-hpa
Architecture: source
Version: 5.3+20251116-1
Distribution: unstable
Urgency: medium
Maintainer: Chris Hofstaedtler <[email protected]>
Changed-By: Chris Hofstaedtler <[email protected]>
Closes: 1108702
Changes:
tftp-hpa (5.3+20251116-1) unstable; urgency=medium
.
* New upstream snapshot. (Closes: #1108702)
Checksums-Sha1:
dbb0b3fa4b274feab42cfe15eb65bf097f1acd57 2121 tftp-hpa_5.3+20251116-1.dsc
74933eabf79f41aacfa4eeea01b17ee7e98cfe0f 78823
tftp-hpa_5.3+20251116.orig.tar.gz
53e5e1044f603dafce2caec46893cb71e017903e 23196
tftp-hpa_5.3+20251116-1.debian.tar.xz
Checksums-Sha256:
30159cfdbd886ac252b81a79fd049bd7e892d0ecbe573d4770fa5a4878174472 2121
tftp-hpa_5.3+20251116-1.dsc
8682a249ccc96a84f5d44617dbb0c61f27b1eb697c6a26b729a3ad0ae98831db 78823
tftp-hpa_5.3+20251116.orig.tar.gz
ee5ac41d7b4936be169f45f18fff6aa680fa19dcd24a8ed0bd8bc94c367e08b8 23196
tftp-hpa_5.3+20251116-1.debian.tar.xz
Files:
f5c59624e7f264f3e43222f6dc902b0a 2121 net optional tftp-hpa_5.3+20251116-1.dsc
16daa9a0adaf5f4c21567f45ec34c861 78823 net optional
tftp-hpa_5.3+20251116.orig.tar.gz
194c9c4d7f2d32eb275211206fa7f116 23196 net optional
tftp-hpa_5.3+20251116-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfRrP+tnggGycTNOSXBPW25MFLgMFAmkh6sMACgkQXBPW25MF
LgOvwQ//Y7LHme9BuiiYklFK1Azdy8rEdIUg170eeL/gP+SP2vfRN7dbj+RL+yXs
rXIZgtJoxKo1dEd8gluXQFdLPjA6Vb5r4/eUWHX0MebKas39NWyKZbITAmbeOnTF
PBft+xXGYlibwkq97ewEVssXqvCvsoS/RM4TD1hQZJ0igwecbL0tti5j1GB4zWBP
jW/7pinF7GNDXneb1MwglZZUj04hwN93SXf5b8+0UiprGV8jyWXhjnomF3JBCFD5
xw9vEy+TxtghIawenKZTbloXdQktaZlWs6tbq4XcpLLtU4kbfS7Y9tg9UgXrAZ8x
+hsxG8JBljrhCYt7f55t8wCtQrmMDM6uI+5tkjL2ZsiMRXI4Cx6ZChMs3e/4X+ts
V6jiBWJYg+31HUIfxtswayoVgnbvyGMhP+r/KurMOepKrFPeCc940WphuoMxvF05
F0phrrAV44DKgVrha6NeE9bvJdOtd1ZmhjIZQaka9kVniSl0Jp/7v4QlLFP7/Ou9
fMs18vvIqEaP177rttQ1UzEQTJ71xRgARSlcFXOQEd7pPlstHe3Ayxmd2QqyLVjJ
LHQYm7OyLm98pjLJ41CStBnHdjqavCjNKcIF9aquUUnXux69rSOVY+KGHPLhjjY4
p+qzmq/dPcvw2NQUp5sXgzErEYjfQhMFVFlexqTuSNaEM3KoZxY=
=gOrK
-----END PGP SIGNATURE-----
pgp6F2HxR37ji.pgp
Description: PGP signature
--- End Message ---
