public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
* BUG (?) multicast loopback (IP6SKB_FORWARDED)
@ 2012-06-08 16:48 maxd
  2012-06-08 17:23 ` Eric Dumazet
  0 siblings, 1 reply; 2+ messages in thread
From: maxd @ 2012-06-08 16:48 UTC (permalink / raw)
  To: netdev

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?

Thanks,
Massimiliano D'Angelo

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: BUG (?) multicast loopback (IP6SKB_FORWARDED)
  2012-06-08 16:48 BUG (?) multicast loopback (IP6SKB_FORWARDED) maxd
@ 2012-06-08 17:23 ` Eric Dumazet
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Dumazet @ 2012-06-08 17:23 UTC (permalink / raw)
  To: maxd@inwind.it; +Cc: netdev

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-06-08 17:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-08 16:48 BUG (?) multicast loopback (IP6SKB_FORWARDED) maxd
2012-06-08 17:23 ` Eric Dumazet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox