From: Murali Karicheri <m-karicheri2@ti.com>
To: Hangbin Liu <liuhangbin@gmail.com>,
"open list:TI NETCP ETHERNET DRIVER" <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>
Subject: Re: IGMP on IPv6
Date: Thu, 13 Apr 2017 12:36:35 -0400 [thread overview]
Message-ID: <58EFA913.5060604@ti.com> (raw)
In-Reply-To: <58D29265.1020604@ti.com>
On 03/22/2017 11:04 AM, Murali Karicheri wrote:
> Hi Liu,
>
> I saw that you have sent patches to the list for IGMP and have a question on IGMP on IPv6.
> Hope you can clarify. I have posted the question already to the list and is reproduced
> below. Let me know if you have an answer.
>
> ========= See email with subject "IPv6 IGMP issue in v4.4.44 ?? ========================
> Cut-n-paste from that email....
>
> I see an issue with IGMP for IPv6 when I test HSR redundancy network
> interface. As soon as I set up an HSR interface, I see some IGMP messages
> (destination mac address: 33 33 00 00 00 02 going over HSR interface to
> slave interfaces, at the egress where as for IPv6, I see similar messages
> going directly over the Ethernet interfaces that are attached to
> HSR master. It appears that the NETDEV_CHANGEUPPER is not handled properly
> and the mcast snoop sends the packets over the old interfaces at timer
> expiry.
>
> A dump of the message at the slave Ethernet interface looks like below.
>
> IPv4
>
> [ 64.643842] 33 33 00 00 00 02 70 ff 76 1c 0f 8d 89 2f 10 3e fc
> [ 64.649910] 18 86 dd 60 00 00 00 00 10 3a ff fe 80 00 00 00
> [ 64.655705] 00 00 00 72 ff 76 ff fe 1c 0f 8d ff 02 00 00 00
> [ 64.661503] 00 00 00 00 00 00 00 00 00 00 02 85 00 8d dc
>
>
> You can see this is tagged with HSR.
>
> IPv6
>
> [ 65.559130] 33 33 00 00 00 02 70 ff 76 1c 0f 8d 86 dd 60 00 00
> [ 65.565205] 00 00 10 3a ff fe 80 00 00 00 00 00 00 72 ff 76
> [ 65.571011] ff fe 1c 0f 8d ff 02 00 00 00 00 00 00 00 00 00
> [ 65.576806] 00 00 00 00 02 85 00 8d dc 00 00 00 00 01 01
>
> This is going directly to the slave Ethernet interface.
>
> When I put a WARN_ONCE, I found this is coming directly from
> mld_ifc_timer_expire() -> mld_sendpack() -> ip6_output()
>
> Do you think this is fixed in latest kernel at master? If so, could
> you point me to some commits.
>
>
Ping... I see this behavior is also seen on v4.9.x Kernel. Any clue if
this is fixed by some commit or I need to debug? I see IGMPv6 has some
fixes on the list to make it similar to IGMPv4. So can someone clarify this is
is a bug at IGMPv6 code or I need to look into the HSR driver code?
Since IGMPv4 is going over the HSR interface I am assuming this is a
bug in the IGMPv6 code. But since I have not experience with this code
can some expert comment please?
Murali
--
Murali Karicheri
Linux Kernel, Keystone
next prev parent reply other threads:[~2017-04-13 16:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 8:16 [PATCHv3 net] igmp: do not remove igmp souce list info when set link down Hangbin Liu
2016-11-16 0:51 ` David Miller
2017-03-22 15:04 ` IGMP on IPv6 Murali Karicheri
2017-04-13 16:36 ` Murali Karicheri [this message]
2017-04-17 21:38 ` Cong Wang
2017-04-18 17:12 ` Murali Karicheri
2017-04-18 17:20 ` Murali Karicheri
2017-04-18 22:37 ` Cong Wang
2017-04-25 16:16 ` Murali Karicheri
2017-04-26 5:24 ` Cong Wang
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=58EFA913.5060604@ti.com \
--to=m-karicheri2@ti.com \
--cc=davem@davemloft.net \
--cc=liuhangbin@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.