[BUG] ip6tnl ignores phys_dev for outgoing packets

[BUG] ip6tnl ignores phys_dev for outgoing packets

[Daniel Gröber]

Hi netdev,

I'm trying to build an ip6ip6 tunnel that sends encapsulated packets only
via a particular interface using the `dev PHYS_DEV` parameter but I'm
seeing packets leave via a different interface instead.

Since it's not totally clear to me what the dev option is really supposed
to do I tested with an ipip tunnel and that does what I'd expect: Even if
there's a more preferential route for the remote address via a different
interface it sends via PHYS_DEV.

To reproduce first setup some dummy interfaces:

    $ ip link add physdev type dummy
    $ ip link add othrdev type dummy

    $ ip addr add dev physdev fd00::1/64
    $ ip addr add dev othrdev fd00::2/64

    $ ip link set dev physdev up
    $ ip link set dev othrdev up

    $ ip link add name tun-test type ip6tnl mode ip6ip6 local fd00::1 remote fd00::3 dev physdev
    $ ip link set dev tun-test up

Make sure othrdev is ordinarily preferred for the remote address contrary
to our PHYS_DEV request above so we can see the difference:

    $ ip -6 route add fd00::3 dev othrdev metric 1

Now generate some traffic on tun-test and observe the encapsulated packets
going out via othrdev instead of physdev as we requested:

    $ ping fe80::1 -I tun-test&
    $ tcpdump -nli any host fd00::3
    othrdev Out IP6 fd00::1 > fd00::3: DSTOPT IP6 fe80::90ae:78ff:fe49:3eed > fe80::1: ICMP6, echo request, id 12880, seq 25, length 64

I did some digging though the code already and found that perhaps setting
`local any` would change the behaviour due to some logic I found in
ip6_route_output_flags_noref:

    any_src = ipv6_addr_any(&fl6->saddr);
    if ((sk && sk->sk_bound_dev_if) || rt6_need_strict(&fl6->daddr) ||
        (fl6->flowi6_oif && any_src))
            flags |= RT6_LOOKUP_F_IFACE;

Alas if I try with `local any` that seems even more broken as I just get
"Address unreachable" responses with or without the `dev physdev`
bit. Weird.

Any ideas whats going wrong here?

--Daniel

PS: I'm not subscribed please leave me in CC.