Description of problem: A tftp to an ip alias of an FC15 tftp-server failed for the client with the message "... timeout ..." Version-Release number of selected component (if applicable): # in.tftpd -V tftp-hpa 0.49, with remap, with tcpwrappers I tested the also FC16 tftp-server, same problem. How reproducible: # ifconfig lo:0 127.0.0.2 # ifconfig lo; ifconfig lo:0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:17908 errors:0 dropped:0 overruns:0 frame:0 TX packets:17908 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4868680 (4.6 MiB) TX bytes:4868680 (4.6 MiB) lo:0 Link encap:Local Loopback inet addr:127.0.0.2 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 # tftp 127.0.0.2 tftp> trace Packet tracing on. tftp> get /thinstation/dell/vmlinuz sent RRQ <file=/thinstation/dell/vmlinuz, mode=netascii> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> sent ACK <block=1> sent ACK <block=1> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> Transfer timed out. tftp> quit # tftp 127.0.0.1 tftp> get /thinstation/dell/vmlinuz tftp> quit Steps to Reproduce: 1. 2. 3. Actual results: File tranfert failed, no PXE network boot. Expected results: Transfert succeded Additional info: No problem if the file size is 0 and no problem with the FC14.
> Additional info: > > No problem if the file size is 0 and no problem with the FC14. As was mentioned in description there is difference in behaviour between F14 and F15. I've found additional information: - The issue is reproducible also in F16. - The issue doesn't occur on F14 with kernel-2.6.35.6-45.fc14. Updating only kernel to kernel-2.6.38.6-26.rc1.fc15 produces this issue. Therefore I'm going to switch component to kernel.
I've bisected this down to: 9fc3bbb4a752f108cf096d96640f3b548bbbce6c is the first bad commit commit 9fc3bbb4a752f108cf096d96640f3b548bbbce6c Author: Joel Sing <jsing> Date: Mon Jan 3 20:24:20 2011 +0000 ipv4/route.c: respect prefsrc for local routes The preferred source address is currently ignored for local routes, which results in all local connections having a src address that is the same as the local dst address. Fix this by respecting the preferred source address when it is provided for local routes. This bug can be demonstrated as follows: # ifconfig dummy0 192.168.0.1 # ip route show table local | grep local.*dummy0 local 192.168.0.1 dev dummy0 proto kernel scope host src 192.168.0.1 # ip route change table local local 192.168.0.1 dev dummy0 \ proto kernel scope host src 127.0.0.1 # ip route show table local | grep local.*dummy0 local 192.168.0.1 dev dummy0 proto kernel scope host src 127.0.0.1 We now establish a local connection and verify the source IP address selection: # nc -l 192.168.0.1 3128 & # nc 192.168.0.1 3128 & # netstat -ant | grep 192.168.0.1:3128.*EST tcp 0 0 192.168.0.1:3128 192.168.0.1:33228 ESTABLISHED tcp 0 0 192.168.0.1:33228 192.168.0.1:3128 ESTABLISHED Signed-off-by: Joel Sing <jsing> Signed-off-by: David S. Miller <davem> So it seems they modified how routing works with local addresses. I've emailed upstream to see if the change in behavior is intentional, or if it should be considered a bug.
Hello, Sorry I am not sure I understand, but I do the test with 127.0.0.* because it is more easy to implement. I have the original problem not with the loopback addresses. I have a hardware (Dell PC) booting over the network with PXE, this hardware try to load it system from a tftp server. If I used the real ip of the tftp server I have no problem, if I used an alias I have the problem (I have to use an alias, because I have a Cluster). What I think, the bios tftp client talk to the server with the IP alias but the server reply with the real IP and the client reject the reply. Best regards. Francis
The upstream thread on this is here: http://thread.gmane.org/gmane.linux.network/207941 It appears that the change is intentional, and they offer a couple of different suggestions on how to get TFTP working in your case.
Hello Josh, I do the test with the bind if the IP alis (for test purpose 127.0.0.2), but I have the same problem. # ifconfig lo; ifconfig lo:0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:24418 errors:0 dropped:0 overruns:0 frame:0 TX packets:24418 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3798250 (3.6 MiB) TX bytes:3798250 (3.6 MiB) lo:0 Link encap:Local Loopback inet addr:127.0.0.2 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 # netstat -an | grep 69 | grep udp udp 0 0 127.0.0.2:69 0.0.0.0:* udp 0 0 :::52697 :::* # tftp 127.0.0.2 tftp> trace Packet tracing on. tftp> get /thinstation/dell/vmlinuz sent RRQ <file=/thinstation/dell/vmlinuz, mode=netascii> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> sent ACK <block=1> sent ACK <block=1> sent ACK <block=1> received DATA <block=1, 512 bytes> sent ACK <block=1> Transfer timed out. tftp> Best regards. Francis
Hello, I found some information about a "Service Guard environment" from HP and an option "-s" to enable it (http://nixdoc.net/man-pages/HP-UX/man1/tftpd.1m.html): "This option is required for some tftp clients. These clients reject the tftp reply received from a different IP address than the one requested when the server’s interface is configured with an alias IP address." Best regards. Francis
Hello, I do this test I change the local route # ip route show table local | grep 127.0.0. broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 # # ip route change local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.2 # # ip route show table local | grep 127.0.0. broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.2 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 # # tftp 127.0.0.2 tftp> get /thinstation/dell/vmlinuz tftp> quit # # ip route change local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 # tftp 127.0.0.2 tftp> get /thinstation/dell/vmlinuz Transfer timed out. tftp> quit # Best regards. Francis
Upstream says this is really an issue with the tftp server not using the correct API. I don't think it's likely they will change the kernel code, so I'm going to assign this back to tftp.
Hello Josh, What is the correct API ? Actually I use this bypass: ip route change local <IPALIAS> dev <NETWORKINTERFACE> proto kernel scope host src <IPALIAS> The problem, I loose the modification if the cluster node standby or reboot. Best regards. Francis
I'm also experiencing this problem in Fedora 16. My problem is occurring with a non-loopback aliased address. With Wireshark, I was able to determine that the problem was caused by the TFTP server responding from the host's primary address instead of from the address on which it received the request. I am happy to provide a network dump or any other information that might be helpful.
The following workaround from the above thread seems to help: ip route change local 172.30.16.17 table local dev em1 proto kernel scope host I must admit that I don't understand half of what this is doing.
Hi, When this bug was corrected please ? Best regards. Francis
There is rebased tftp-5.2 in the updates-testing repository. It works fine for me. Could you verify it. (I've just requested pushing stable) Thanks, Jiri
Hi Jiri, Thank you for your quick replay, but I have a dependency problem: #rpm -Fvh /home/francis/Download/tftp-5.2-1.fc16.i686.rpm warning: /home/francis/Download/tftp-5.2-1.fc16.i686.rpm: Header V3 RSA/SHA256 Signature, key ID a82ba4b7: NOKEY error: Failed dependencies: libc.so.6(GLIBC_2.15) is needed by tftp-5.2-1.fc16.i686 You have mail in /var/spool/mail/root Best regards. Francis
Jiri, Same dependency problem with the server: # rpm -Fvh /home/francis/Download/tftp-server-5.2-1.fc16.i686.rpm warning: /home/francis/Download/tftp-server-5.2-1.fc16.i686.rpm: Header V3 RSA/SHA256 Signature, key ID a82ba4b7: NOKEY error: Failed dependencies: libc.so.6(GLIBC_2.15) is needed by tftp-server-5.2-1.fc16.i686 Best regards. Francis
Ah, you tried to install F16 rpms on F15, right? The bug is written against F16 but you've mentioned tests on F15. It confused me a bit. I've built a scratch build tftp-5.2 for F15. Unfortunately it doesn't work. Thanks to this I found out different behavior on F15 and F16 but I have to investigate it better. This doesn't seem to be fully fixed yet.
tftp-5.2-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/tftp-5.2-2.fc16
tftp-5.2-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/tftp-5.2-1.fc15
Package tftp-5.2-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tftp-5.2-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0118/tftp-5.2-1.fc15 then log in and leave karma (feedback).
Hello, Thank you very much that work ! But I installed the tftp-server ;). Best regards. Francis
tftp-5.2-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
tftp-5.2-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.