From: Eric Dumazet <eric.dumazet@gmail.com>
To: "maxd@inwind.it" <maxd@inwind.it>
Cc: netdev@vger.kernel.org
Subject: Re: BUG (?) multicast loopback (IP6SKB_FORWARDED)
Date: Fri, 08 Jun 2012 19:23:42 +0200 [thread overview]
Message-ID: <1339176222.6001.131.camel@edumazet-glaptop> (raw)
In-Reply-To: <7813214.2267681339174116704.JavaMail.defaultUser@defaultHost>
On Fri, 2012-06-08 at 18:48 +0200, maxd@inwind.it wrote:
> Hi guys,
> I found a probably wrong behaviour while doing some tests with multicast
> routing on IPv6 with kernel 2.6.29. I will try to describe what's wrong in the
> code in the following. I will use the latest kernel sources (3.5-rc1)
> as reference source code (line numbers are taken there).
> Let's assume a scenario with a node with two network interfaces acting as a
> multicast router. The router receives the message on one interface and needs to
> forward it on the other interface. Looking at the packet flow inside the
> kernel, we notice that
>
> in ip6mr.c, line 2282, a flag is set:
> IP6CB(skb)->flags |= IP6SKB_FORWARDED;
>
> After this, a multicast packet can be looped back (see line 124 in ip6_output.
> c where function ip6_dev_loopback_xmit is called).
> The packet is hence reinjected in the stack.
>
> The packet is processed by function ipv6_rcv (ip6_input.c), and then by
> ipv6_mc_input (ip6_input.c).
>
> In ipv6_rcv, line 82, the previously set flag is cleared
> memset(IP6CB(skb), 0, sizeof(struct inet6_skb_parm));
>
> In ipv6_mc_input, , line 268, the flag is checked to determine if the packet
> has been already forwarded. Since the flag has been cleared, the kernel cannot
> determine that the packet has been looped back, and will hence try to forward
> it again.
>
> Trying to forward a looped back packet determines a wrong behaviour of the
> multicast routing protocol (PIM): the kernel believes that a multicast message
> has been received from a wrong interface (line 1993 in ip6mr.c), discard the
> message (this explains why the packet does not loop forever) and triggers the
> transmission of an ASSERT message. Basically, the node ends up sending an
> ASSERT message because of a looped back packet.
>
> WDYT? Is my analysis correct? Which is the best way to fix this issue?
I guess your analysis is correct, try to revert commit
6b7fdc3ae18a0598a999156b62d55ea55220e00f ([IPV6]: Clean skb cb on IPv6
input) ?
prev parent reply other threads:[~2012-06-08 17:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 16:48 BUG (?) multicast loopback (IP6SKB_FORWARDED) maxd
2012-06-08 17:23 ` Eric Dumazet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1339176222.6001.131.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=maxd@inwind.it \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox