netdev - Re: icmpv6: issue with routing table entries from link local addresses

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b6804e09-403f-64ff-257b-6c5fda7f8047@stressinduktion.org>
Date:   Mon, 12 Sep 2016 19:26:23 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     Andreas Hübner <andreas@....de>,
        netdev@...r.kernel.org, "d. caratti" <davide.caratti@...il.com>
Subject: Re: icmpv6: issue with routing table entries from link local
 addresses

Hello,

On 12.09.2016 16:27, Andreas Hübner wrote:
> Hi,
> 
> I'm currently debugging a potential issue with the icmpv6 stack and
> hopefully this is the correct place to ask. (Was actually looking for a
> more specific list, but didn't find anything. Please point me to a more
> apropriate list if this is out of place here.)
> 
> I have the following setup:
>   - 2 directly connected hosts (A+B), both have only link local addresses
>     configured (interface on both hosts is eth0)
>   - host B is also connected to another host C (via interface eth1)
>   - main routing table (relevant part) on host B looks like this:
> 
>       fe80::/64 dev eth1  proto kernel  metric 256
>       fe80::/64 dev eth0  proto kernel  metric 256
> 
>   - host A is trying to ICMPv6 ping the link local address of host B
> 
> The issue I currently have is, that the echo reply that host B should
> generate is never sent back to host A. If I change the order of the
> routing table entries on host B, everything works fine.
> (host A is connected on eth0)
> 
> I'm wondering, if this is how it is supposed to work. Do we need to do a
> routing table lookup when generating an ICMPv6 echo reply for link local
> addresses?  (From my understanding, this is not done in the neighbour
> discovery stack, so why here?)

For global addresses this is necessary as asymetric routing could be
involved and we don't want to treat ping echos in any way special.

> Actually, I'm convinced I must be doing something wrong here. The setup
> for the issue is quite trivial, someone would have tripped over it
> already. The only condition is that one host has multiple interfaces
> with ipv6 enabled.
> 
> Any help in shedding some light onto this issue would be appreciated.

This shouldn't be the case. We certainly carry over the ifindex of the
received packet into the routing lookup of the outgoing packet, thus the
appropriate rule, with outgoing ifindex should be selected.

I also couldn't reproduce your problem here with my system. Can you
verify with tcpdump that the packet is leaving on another interface?

Thanks,
Hannes