tun routing is broken

From: Jiri Slaby <jslaby@suse.cz>
Date: Sat, 05 Mar 2011 09:04:22 +0100

> Ok, so I booted the new kernel, and tun is broken there completely. If I
> try to ping a vpn peer:

-mm tree is missing this fix which went in yesterday.  Please if
you are going to be testing networking a lot, test against net-next-2.6
instead of Andrew's tree which invariable lags behind:

--------------------
ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.

Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/devinet.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

On 03/05/2011 09:10 AM, David Miller wrote:
> From: Jiri Slaby <jslaby@suse.cz>
> Date: Sat, 05 Mar 2011 09:04:22 +0100
> 
>> Ok, so I booted the new kernel, and tun is broken there completely. If I
>> try to ping a vpn peer:
> 
> -mm tree is missing this fix which went in yesterday.  Please if
> you are going to be testing networking a lot, test against net-next-2.6
> instead of Andrew's tree which invariable lags behind:

I'm not testing networking, I'm just using my desktop :). (And
next/master is mostly unusable for these needs. In comparison to mmotm
which is some kind of a "release".)

> --------------------
> ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.

It would be great to have a References: tag or better changelog. Then I
would give the commit a shot. The way it is I ignored it when looking at
next/master inside net/ipv4/ changes for commits to test.

Going to boot with this change.

> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Reported-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  net/ipv4/devinet.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index 9038928..ff53860 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -111,7 +111,7 @@ static inline unsigned int inet_addr_hash(struct net *net, __be32 addr)
>  
>  static void inet_hash_insert(struct net *net, struct in_ifaddr *ifa)
>  {
> -	unsigned int hash = inet_addr_hash(net, ifa->ifa_address);
> +	unsigned int hash = inet_addr_hash(net, ifa->ifa_local);
>  
>  	spin_lock(&inet_addr_hash_lock);
>  	hlist_add_head_rcu(&ifa->hash, &inet_addr_lst[hash]);
> @@ -146,7 +146,7 @@ struct net_device *__ip_dev_find(struct net *net, __be32 addr, bool devref)
>  
>  		if (!net_eq(dev_net(dev), net))
>  			continue;
> -		if (ifa->ifa_address == addr) {
> +		if (ifa->ifa_local == addr) {
>  			result = dev;
>  			break;
>  		}

thanks,

On 03/05/2011 09:17 AM, Jiri Slaby wrote:
>> ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.
> 
> It would be great to have a References: tag or better changelog. Then I
> would give the commit a shot. The way it is I ignored it when looking at
> next/master inside net/ipv4/ changes for commits to test.
> 
> Going to boot with this change.

Yes, it works.

thanks,

On Sat, 05 Mar 2011 00:10:22 PST, David Miller said:
> --------------------
> ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.
> 
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Reported-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  net/ipv4/devinet.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index 9038928..ff53860 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c

Confirming this fixes the problem I reported with IPv4 over PPP as well, thanks.

On Sat, 5 Mar 2011, Jiri Slaby wrote:

> > Date: Sat, 05 Mar 2011 09:04:22 +0100
> > 
> >> Ok, so I booted the new kernel, and tun is broken there completely. If I
> >> try to ping a vpn peer:
> > 
> > -mm tree is missing this fix which went in yesterday.  Please if
> > you are going to be testing networking a lot, test against net-next-2.6
> > instead of Andrew's tree which invariable lags behind:
> 
> I'm not testing networking, I'm just using my desktop :). (And
> next/master is mostly unusable for these needs. In comparison to mmotm
> which is some kind of a "release".)

I have been hit by similar issues several times already as well.

I guess that question of including -mm into linux-next should be raised 
again here ... Andrew, if I remember correctly, on last kernel summit you 
were stating that you'd stop eating untill you have -mm included in -next. 
Seems like you must be quite hungry these days already :)

Thanks,