netdev - Multicast routing: wrong output interface selected unless VRF default route is added

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

Message-ID: <CADxRGxBfaWWvtYJmEebdzSMkVk6-YTx+jff2bGwS+TXBUPM-LA@mail.gmail.com>
Date:   Mon, 22 Jun 2020 09:19:10 +1000
From:   Qiwei Wen <wenqiweiabcd@...il.com>
To:     netdev@...r.kernel.org
Subject: Multicast routing: wrong output interface selected unless VRF default
 route is added

Hi all,

While experimenting with FRRouting, I observed the following
behaviour. I'm not sure whether it's intended or not.

In a virtual machine set up as a multicast router, I added two
networks, created a VRF, and enslaved interfaces to both networks to
the VRF, like so:

ip link add blue type vrf table 1001
ip link set eth0 master blue
ip link set eth1 master blue

I then set up PIM on the router VM (FRR configs attached) and started
the multicast sender and receiver processes on two other VMs. The
mroutes came up as expected (ip show mroute table 1001), but no
packets came to the receiver. I added the following debug message to
ipmr_queue_xmit, just before the NF_HOOK macro:

+    pr_info("calling NF_HOOK! vif->dev is %s,"
+            " dev is %s, skb->dev is %s\n",
+            vif->dev->name, dev->name, skb->dev->name);

and I found that "dev", the selected output interface, is in fact the
output interface of the main table (unicast) default route. Running
tcpdump on that (very wrong) output interface confirmed this.

I then went back to networking/vrf.txt, and found that I forgot to do this:

ip route add table 1001 unreachable default metric 4278198272

after this step, multicast routing began to work correctly.

Further debugging-by-printk lead to these observations:
1. Using the main table (without VRFs), multicast routing works fine
with or without the default unicast route; but in the function "
ip_route_output_key_hash_rcu", the call to "fib_lookup" in fact fails
with -101, "network unreachable".
2. Using the VRF table 1001, the kernel stops routing multicast
packets to the wrong interface once the unreachable default route is
added. "fib_lookup" continues to fail, but with -113, "host
unreachable".

My questions are:
1. is fib_lookup supposed to work with multicast daddr? If so, has
multicast routing been working for the wrong reason?
2. Why does the addition of a unicast default route affect multicast
routing behaviour?

-Dave

Download attachment "frr-runn" of type "application/octet-stream" (295 bytes)