netdev - Re: Incorrect routing to lo in spite of correct record in routing table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Sep 2011 20:47:51 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Марк Коренберг 
	<socketpair@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Incorrect routing to lo in spite of correct record in routing
 table

Le lundi 12 septembre 2011 à 23:14 +0600, Марк Коренберг a écrit :
> Suppose this (note netowrk masks):
> 
> [mmarkk@...rkk-devel ~]# uname -a
> Linux mmarkk-devel 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT
> 2010 x86_64 x86_64 x86_64 GNU/Linux
> 
> [mmarkk@...rkk-devel ~]# ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>     inet 127.0.0.1/32 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>     inet 10.80.20.21/16 brd 10.80.255.255 scope global eth0
> 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
>     inet 127.0.0.2/32 scope host dummy0
> 
> [mmarkk@...rkk-devel ~]# ip route show
> 10.80.0.0/16 dev eth0  proto kernel  scope link  src 10.80.20.21
> unreachable 127.0.0.0/8 <---------------------- has been added by hand
> default via 10.80.90.40 dev eth0
> 
> [mmarkk@...rkk-devel ~]# ip route show table local
> broadcast 10.80.0.0 dev eth0  proto kernel  scope link  src 10.80.20.21
> local 10.80.20.21 dev eth0  proto kernel  scope host  src 10.80.20.21
> local 127.0.0.2 dev dummy0  proto kernel  scope host  src 127.0.0.2
> broadcast 10.80.255.255 dev eth0  proto kernel  scope link  src 10.80.20.21
> local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
> 
> [mmarkk@...rkk-devel ~]# ip route flush cache
> 
> [mmarkk@...rkk-devel ~]# ip route get 127.0.0.3
> RTNETLINK answers: Network is unreachable <------------ good, that is OK
> 
> [mmarkk@...rkk-devel ~]# ip route get 127.0.0.1
> local 127.0.0.1 dev lo  src 127.0.0.1  <--------- Good, that's OK too
>     cache <local>  mtu 16436 advmss 16396 hoplimit 64
> 
> [mmarkk@...rkk-devel ~]# ip route get 127.0.0.2
> local 127.0.0.2 dev lo  src 127.0.0.2 <------------ HAY! this is not I
> want. Why device is "lo" (instead of dummy0) ?!
>     cache <local>  mtu 16436 advmss 16396 hoplimit 64
> 
> =========================
> The problem is that I want to do DNAT to localhost. I know, why DNAT
> to 127.0.0.1 (to interface "lo") does not work. I decide to do that
> using interface dummy0. It works as expected if I choose any address
> not in 127.0.0.0/8.
> 
> RFC 3330 said:
> -------------
> A datagram sent by a higher level protocol to an  address anywhere
> within this block should loop back inside the host. This is ordinarily
> implemented using only 127.0.0.1/32 for loopback, but no addresses
> within this block should ever appear on any network anywhere
> -------------
> So, my question: Why the kernel routes 127.0.0.2 to lo (instead of dummy0) ?
> 
> Well, If kernel is so smart to route any 127.0.0.0/8 to "lo", why it
> routes 127.0.0.3 to default gateway if I remove "unreachable
> 127.0.0.0/8" ?!
> 

Because you have 127.0.0.1/32 on lo, not 127.0.0.1/8

> I think there is some bug in kernel. What are you thinking about?
> 

I have no idea why you think there is a bug.

127.0.0.2 (dummy0) is a local address like 10.80.20.21 (eth0)

When you ping 10.80.20.21, the frame goes through loopback, not eth0.

# ip ro get 10.80.20.21
local 10.80.20.21 dev lo  src 10.80.20.21 
    cache <local> 

BTW, if you 'ifconfig lo down', ping to 10.80.20.21 doesnt work.




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