Bug 739534 - TFTP to an IP alias of FC15 tftp server failed.
Summary: TFTP to an IP alias of FC15 tftp server failed.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tftp
Version: 16
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jiri Skala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-19 12:38 UTC by SOUYRI
Modified: 2014-11-09 22:34 UTC (History)
10 users (show)

Fixed In Version: tftp-5.2-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-15 20:02:24 UTC


Attachments (Terms of Use)

Description SOUYRI 2011-09-19 12:38:49 UTC
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.

Comment 1 Jiri Skala 2011-10-03 13:07:49 UTC
> 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.

Comment 2 Josh Boyer 2011-10-06 13:25:55 UTC
I've bisected this down to:

9fc3bbb4a752f108cf096d96640f3b548bbbce6c is the first bad commit
commit 9fc3bbb4a752f108cf096d96640f3b548bbbce6c
Author: Joel Sing <jsing@google.com>
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@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

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.

Comment 3 SOUYRI 2011-10-07 08:11:14 UTC
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

Comment 4 Josh Boyer 2011-10-07 14:40:55 UTC
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.

Comment 5 SOUYRI 2011-10-10 07:28:57 UTC
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

Comment 6 SOUYRI 2011-10-10 07:37:00 UTC
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

Comment 7 SOUYRI 2011-10-10 08:08:15 UTC
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

Comment 8 Josh Boyer 2011-10-13 13:21:52 UTC
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.

Comment 9 SOUYRI 2011-10-17 13:42:56 UTC
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

Comment 10 Andrew McNabb 2011-11-23 17:34:01 UTC
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.

Comment 11 Andrew McNabb 2011-11-24 02:22:48 UTC
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.

Comment 12 SOUYRI 2011-12-22 11:00:47 UTC
Hi,

When this bug was corrected please ?

Best regards.

Francis

Comment 13 Jiri Skala 2011-12-22 12:59:33 UTC
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

Comment 14 SOUYRI 2011-12-22 13:13:17 UTC
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

Comment 15 SOUYRI 2011-12-22 13:16:47 UTC
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

Comment 16 Jiri Skala 2011-12-22 14:32:37 UTC
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.

Comment 17 Fedora Update System 2012-01-04 10:02:49 UTC
tftp-5.2-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/tftp-5.2-2.fc16

Comment 18 Fedora Update System 2012-01-04 10:14:52 UTC
tftp-5.2-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/tftp-5.2-1.fc15

Comment 19 Fedora Update System 2012-01-05 21:00:28 UTC
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).

Comment 20 SOUYRI 2012-01-06 10:48:02 UTC
Hello,

Thank you very much that work !

But I installed the tftp-server ;).

Best regards.

Francis

Comment 21 Fedora Update System 2012-01-15 20:02:24 UTC
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.

Comment 22 Fedora Update System 2012-01-15 20:04:59 UTC
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.


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