netdev - Re: [BUG] Any-IP IPv6 support broken

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 2 Nov 2015 13:30:55 -0800
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	Gilberto Bertin <gilberto.bertin@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [BUG] Any-IP IPv6 support broken

> I would like to have a "bind-to-subnet" semantic with IPv6.

Ah, this is something that I have reason to suspect may indeed be
broken for IPv6.
A coworker did some one-off testing on this a few months back, and
didn't get it to trivially work.
We didn't debug it, nor try to figure out what (if anything) was wrong.

Specifically what we were trying to get is a replacement for the
127.0.0.1/8 subnet on lo, ie. more than one IPv6 loopback IP.

> This is currently working with IPv4, and the setup is the follow:
>
> - setup a dummy network device configured with any-IP
> - add an any-IP route
> - bind() on the dummy device

I'm not entirely sure why you have a dummy device.
Couldn't you use 'lo'?  How are you configuring this?
Any-ip routing configuration explicitly uses iif which should never
trigger here.

> in this way we can effectively bind a process to a particular subnet
> (by binding it to a dummy device which is receiving all the packets
> from a particular subnet).

How can a dummy device receive packets?

> The point of using dummy devices is that we can configure multiple ones
> (and so we can bind multiple processes to multiple subnets).

Interesting, I had no idea something like this was possible.
I'm not convinced this is even working as intended.

Naively I'd expect dummy devices to never be the source of packets,
and thus binding to a dummy device to cause a socket to not receive
any traffic.  But obviously I must be wrong.

> This is actually working with IPv4 (as I said I'm using a recent kernel,
> 4.1), and the fact that you say it's not supposed to work leads me to
> think that maybe we are not talking about the same feature.

Yeah, certainly seems like it.
--
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