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$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=liuhangbin@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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