netdev - IGMPMSG_WRONGVIF only happens when true VIF is an OIF of correct IIF?

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]

Date:	Fri, 18 Feb 2011 16:46:56 +0100
From:	Dan Langlois <daniel.langlois@...mens.com>
To:	netdev@...r.kernel.org
Subject: IGMPMSG_WRONGVIF only happens when true VIF is an OIF of correct
 IIF?

Hi, I have a question about the IGMPMSG_WRONGVIF message.
I have MRT_ASSERT enabled but do not receive notifications.
However, if I enable MRT_PIM, I do get them.  I'm curious
why MRT_ASSERT alone isn't sufficient.

This if-statement appears in ip_mr_forward() in net/ipv4/ipmr.c

       if (true_vifi >= 0 && net->ipv4.mroute_do_assert &&
            /* pimsm uses asserts, when switching from RPT to SPT, 
               so that we cannot check that packet arrived on an oif. 
               It is bad, but otherwise we would need to move pretty
               large chunk of pimd to kernel. Ough... --ANK
             */      
            (net->ipv4.mroute_do_pim ||
             cache->mfc_un.res.ttls[true_vifi] < 255) && 
            time_after(jiffies,
                       cache->mfc_un.res.last_assert +
MFC_ASSERT_THRESH)) {
                cache->mfc_un.res.last_assert = jiffies;
                ipmr_cache_report(net, skb, true_vifi,
IGMPMSG_WRONGVIF);
        }       

By the time this statement is reached, it is known that the packet
did not arrive on the expected incoming interface (IIF) and thus a
"WRONGVIF" condition.  This if-statement decides whether a PIM-assert
notification needs to be sent to the multicast routing daemon.

The part of this if-statement I'm questioning is:
    (net->ipv4.mroute_do_pim ||
     cache->mfc_un.res.ttls[true_vifi] < 255) &&

I read this as:
"send WRONGVIF if PIM is enabled -OR-
the packet arrived on an outgoing interface OIF of the correct IIF"

So this statement is always true when PIM is enabled.
However, if only ASSERT is enabled, this statement is only true when
a packet is reflected back on an OIF.

Why not always send the assert for any WRONGVIF condition regardless
of the interface it came in on?  I mean, isn't that the point of
enabling MRT_ASSERT in the first place?  If the assertions weren't
wanted, just don't enable that feature, right?

In our system, multicast streams may get rerouted through a different
VIF than what was first installed in the MFC cache.  I would very much
like to get these WRONGVIF assertions in this case, which is NOT the
case that a packet is seen on an OIF.

Of course I can simply enable MRT_PIM to get the messages, but in that
case I don't understand the reason for having two separate toggles
(MRT_ASSERT versus MRT_PIM).

Could someone please explain the reasoning here, as I don't understand
the comment, and I'm tempted to patch out this part of the if-statement.

cheers,
Dan

--
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