FYI: tftp-hpa breaks when used on secondary ip addresses

tftp-hpa has code to test to see if the address it received a connection
on is a local address.  I don't have a clue why tftp-hpa doesn't trust
the kernel but the code looks like:

static int address_is_local(const struct sockaddr_in *addr)
{
        struct sokcaddr sa;
        int sockfd = -1;
        sockfd = socket(AF_INET, SOCK_DGRAM, 0);
        connect(sockfd, (struct sockaddr *)&addr, sizeof(*addr));
        getsockname(sockfd, (struct sockaddr *)&sa, sizeof(sa));
        return sa.sin_addr.s_addr == addr->sin_addr.s_addr;
}

Which if fails now if you happen to be running tftp-hpa on a secondary
ip address on the same subnet as your first ip.  Because pref_source
in the routing table points at the first ip.

The change in kernel behavior appears to be from the commit below to
honor the preferred source address in local connections.

This all seems very fuzzy to me and mostly this appears to be a bug in
tftp-hpa but since I tracked it down I figured I would let everyone
know what happened.

Eric



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>

                res.fi = NULL;

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 03/04/2011 04:58 PM, Eric W. Biederman wrote:
> 
> Which if fails now if you happen to be running tftp-hpa on a secondary
> ip address on the same subnet as your first ip.  Because pref_source
> in the routing table points at the first ip.
> 
> The change in kernel behavior appears to be from the commit below to
> honor the preferred source address in local connections.
> 

If this is done for all local connections (as opposed to the ones that
have been configured explicitly by the administrator to behave that
way), that's a massive lossage.  Not only does a large number of
applications use this trick to determine if an address is local (e.g.
allowing bypass) -- it is pretty much the only portable way to do it --
but it would cause applications which expect to get a reply back from
the same address they sent a request to to completely fall on their face.

tftp-hpa needs this information in order to handle clients that send
their initial request to a broadcast (or multicast) address.

> This all seems very fuzzy to me and mostly this appears to be a bug in
> tftp-hpa but since I tracked it down I figured I would let everyone
> know what happened.

This seems like a broken change to me, or at the very least having
seriously unintended consequences.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, 04 Mar 2011 17:31:00 -0800

> If this is done for all local connections (as opposed to the ones that
> have been configured explicitly by the administrator to behave that
> way), that's a massive lossage.  Not only does a large number of
> applications use this trick to determine if an address is local (e.g.
> allowing bypass) -- it is pretty much the only portable way to do it --
> but it would cause applications which expect to get a reply back from
> the same address they sent a request to to completely fall on their face.

Actually this is what SOL_IP, IP_PKTINFO, was created for.  Even glibc
uses it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html