From: Murali Karicheri <m-karicheri2@ti.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: 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: Tue, 18 Apr 2017 13:20:27 -0400 [thread overview]
Message-ID: <58F64ADB.8040900@ti.com> (raw)
In-Reply-To: <58F648FB.10606@ti.com>
On 04/18/2017 01:12 PM, Murali Karicheri wrote:
> On 04/17/2017 05:38 PM, Cong Wang wrote:
>> Hello,
>>
>> On Thu, Apr 13, 2017 at 9:36 AM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>>> On 03/22/2017 11:04 AM, Murali Karicheri wrote:
>>>> 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?
>>>
>>
>> How did you configure your network interfaces and IPv4/IPv6 multicast?
>> IOW, how did you reproduce this? For example, did you change your
>> HSR setup when this happened since you mentioned
>> NETDEV_CHANGEUPPER?
>>
> Thanks for responding! Really appreciate.
>
> I didn't set up anything explicitly for IPv4/IPv6 multicast. As part of
> my testing, I dump the packets going through the slave interfaces attached
> to the hsr interface (for example my Ethernet interfaces eth2 and eth3
> are attached to the hsr interface and I dump the packets at the egress
> of eth2 and eth3 in my driver along with that at hsr xmit function). As
> soon as I create the hsr interface, I see a bunch of packets going directly
> through the lower interface, not through the upper one (i.e hsr interface)
> and these are of eth_type = 86 dd. Please ignore my reference to
> NETDEV_CHANGEUPPER for now as it was wild guess.
>
> I have not done any debugging, but the WARN_ONCE which I have placed
> in the lower level driver looking for eth_type = 86 dd provided the
> above trace.
>
Here is the command I have used to create the hsr interface...
ip link add name hsr0 type hsr slave1 eth2 slave2 eth3 supervision 45 version 1
--
Murali Karicheri
Linux Kernel, Keystone
next prev parent reply other threads:[~2017-04-18 17:20 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
2017-04-17 21:38 ` Cong Wang
2017-04-18 17:12 ` Murali Karicheri
2017-04-18 17:20 ` Murali Karicheri [this message]
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=58F64ADB.8040900@ti.com \
--to=m-karicheri2@ti.com \
--cc=davem@davemloft.net \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).