All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv3 net] igmp: do not remove igmp souce list info when set link down
@ 2016-11-14  8:16 Hangbin Liu
  2016-11-16  0:51 ` David Miller
  2017-03-22 15:04 ` IGMP on IPv6 Murali Karicheri
  0 siblings, 2 replies; 10+ messages in thread
From: Hangbin Liu @ 2016-11-14  8:16 UTC (permalink / raw)
  To: netdev; +Cc: Hannes Frederic Sowa, Daniel Borkmann, Hangbin Liu

In commit 24cf3af3fed5 ("igmp: call ip_mc_clear_src..."), we forgot to remove
igmpv3_clear_delrec() in ip_mc_down(), which also called ip_mc_clear_src().
This make us clear all IGMPv3 source filter info after NETDEV_DOWN.
Move igmpv3_clear_delrec() to ip_mc_destroy_dev() and then no need
ip_mc_clear_src() in ip_mc_destroy_dev().

On the other hand, we should restore back instead of free all source filter
info in igmpv3_del_delrec(). Or we will not able to restore IGMPv3 source
filter info after NETDEV_UP and NETDEV_POST_TYPE_CHANGE.

Fixes: 24cf3af3fed5 ("igmp: call ip_mc_clear_src() only when ...")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 net/ipv4/igmp.c | 50 ++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 14 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 606cc3e..15db786 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -162,7 +162,7 @@ static int unsolicited_report_interval(struct in_device *in_dev)
 }
 
 static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im);
-static void igmpv3_del_delrec(struct in_device *in_dev, __be32 multiaddr);
+static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im);
 static void igmpv3_clear_delrec(struct in_device *in_dev);
 static int sf_setstate(struct ip_mc_list *pmc);
 static void sf_markstate(struct ip_mc_list *pmc);
@@ -1130,10 +1130,15 @@ static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im)
 	spin_unlock_bh(&in_dev->mc_tomb_lock);
 }
 
-static void igmpv3_del_delrec(struct in_device *in_dev, __be32 multiaddr)
+/*
+ * restore ip_mc_list deleted records
+ */
+static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im)
 {
 	struct ip_mc_list *pmc, *pmc_prev;
-	struct ip_sf_list *psf, *psf_next;
+	struct ip_sf_list *psf;
+	struct net *net = dev_net(in_dev->dev);
+	__be32 multiaddr = im->multiaddr;
 
 	spin_lock_bh(&in_dev->mc_tomb_lock);
 	pmc_prev = NULL;
@@ -1149,16 +1154,26 @@ static void igmpv3_del_delrec(struct in_device *in_dev, __be32 multiaddr)
 			in_dev->mc_tomb = pmc->next;
 	}
 	spin_unlock_bh(&in_dev->mc_tomb_lock);
+
+	spin_lock_bh(&im->lock);
 	if (pmc) {
-		for (psf = pmc->tomb; psf; psf = psf_next) {
-			psf_next = psf->sf_next;
-			kfree(psf);
+		im->interface = pmc->interface;
+		im->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
+		im->sfmode = pmc->sfmode;
+		if (pmc->sfmode == MCAST_INCLUDE) {
+			im->tomb = pmc->tomb;
+			im->sources = pmc->sources;
+			for (psf = im->sources; psf; psf = psf->sf_next)
+				psf->sf_crcount = im->crcount;
 		}
 		in_dev_put(pmc->interface);
-		kfree(pmc);
 	}
+	spin_unlock_bh(&im->lock);
 }
 
+/*
+ * flush ip_mc_list deleted records
+ */
 static void igmpv3_clear_delrec(struct in_device *in_dev)
 {
 	struct ip_mc_list *pmc, *nextpmc;
@@ -1366,7 +1381,7 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
 	ip_mc_hash_add(in_dev, im);
 
 #ifdef CONFIG_IP_MULTICAST
-	igmpv3_del_delrec(in_dev, im->multiaddr);
+	igmpv3_del_delrec(in_dev, im);
 #endif
 	igmp_group_added(im);
 	if (!in_dev->dead)
@@ -1626,8 +1641,12 @@ void ip_mc_remap(struct in_device *in_dev)
 
 	ASSERT_RTNL();
 
-	for_each_pmc_rtnl(in_dev, pmc)
+	for_each_pmc_rtnl(in_dev, pmc) {
+#ifdef CONFIG_IP_MULTICAST
+		igmpv3_del_delrec(in_dev, pmc);
+#endif
 		igmp_group_added(pmc);
+	}
 }
 
 /* Device going down */
@@ -1648,7 +1667,6 @@ void ip_mc_down(struct in_device *in_dev)
 	in_dev->mr_gq_running = 0;
 	if (del_timer(&in_dev->mr_gq_timer))
 		__in_dev_put(in_dev);
-	igmpv3_clear_delrec(in_dev);
 #endif
 
 	ip_mc_dec_group(in_dev, IGMP_ALL_HOSTS);
@@ -1688,8 +1706,12 @@ void ip_mc_up(struct in_device *in_dev)
 #endif
 	ip_mc_inc_group(in_dev, IGMP_ALL_HOSTS);
 
-	for_each_pmc_rtnl(in_dev, pmc)
+	for_each_pmc_rtnl(in_dev, pmc) {
+#ifdef CONFIG_IP_MULTICAST
+		igmpv3_del_delrec(in_dev, pmc);
+#endif
 		igmp_group_added(pmc);
+	}
 }
 
 /*
@@ -1704,13 +1726,13 @@ void ip_mc_destroy_dev(struct in_device *in_dev)
 
 	/* Deactivate timers */
 	ip_mc_down(in_dev);
+#ifdef CONFIG_IP_MULTICAST
+	igmpv3_clear_delrec(in_dev);
+#endif
 
 	while ((i = rtnl_dereference(in_dev->mc_list)) != NULL) {
 		in_dev->mc_list = i->next_rcu;
 		in_dev->mc_count--;
-
-		/* We've dropped the groups in ip_mc_down already */
-		ip_mc_clear_src(i);
 		ip_ma_put(i);
 	}
 }
-- 
2.5.5

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

* Re: [PATCHv3 net] igmp: do not remove igmp souce list info when set link down
  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
  1 sibling, 0 replies; 10+ messages in thread
From: David Miller @ 2016-11-16  0:51 UTC (permalink / raw)
  To: liuhangbin; +Cc: netdev, hannes, daniel

From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 14 Nov 2016 16:16:28 +0800

> In commit 24cf3af3fed5 ("igmp: call ip_mc_clear_src..."), we forgot to remove
> igmpv3_clear_delrec() in ip_mc_down(), which also called ip_mc_clear_src().
> This make us clear all IGMPv3 source filter info after NETDEV_DOWN.
> Move igmpv3_clear_delrec() to ip_mc_destroy_dev() and then no need
> ip_mc_clear_src() in ip_mc_destroy_dev().
> 
> On the other hand, we should restore back instead of free all source filter
> info in igmpv3_del_delrec(). Or we will not able to restore IGMPv3 source
> filter info after NETDEV_UP and NETDEV_POST_TYPE_CHANGE.
> 
> Fixes: 24cf3af3fed5 ("igmp: call ip_mc_clear_src() only when ...")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>

Applied.

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

* IGMP on IPv6
  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 ` Murali Karicheri
  2017-04-13 16:36   ` Murali Karicheri
  1 sibling, 1 reply; 10+ messages in thread
From: Murali Karicheri @ 2017-03-22 15:04 UTC (permalink / raw)
  To: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER

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.


-- 
Murali Karicheri
Linux Kernel, Keystone

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

* Re: IGMP on IPv6
  2017-03-22 15:04 ` IGMP on IPv6 Murali Karicheri
@ 2017-04-13 16:36   ` Murali Karicheri
  2017-04-17 21:38     ` Cong Wang
  0 siblings, 1 reply; 10+ messages in thread
From: Murali Karicheri @ 2017-04-13 16:36 UTC (permalink / raw)
  To: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

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

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

* Re: IGMP on IPv6
  2017-04-13 16:36   ` Murali Karicheri
@ 2017-04-17 21:38     ` Cong Wang
  2017-04-18 17:12       ` Murali Karicheri
  0 siblings, 1 reply; 10+ messages in thread
From: Cong Wang @ 2017-04-17 21:38 UTC (permalink / raw)
  To: Murali Karicheri
  Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

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?

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

* Re: IGMP on IPv6
  2017-04-17 21:38     ` Cong Wang
@ 2017-04-18 17:12       ` Murali Karicheri
  2017-04-18 17:20         ` Murali Karicheri
  0 siblings, 1 reply; 10+ messages in thread
From: Murali Karicheri @ 2017-04-18 17:12 UTC (permalink / raw)
  To: Cong Wang; +Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

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. 

-- 
Murali Karicheri
Linux Kernel, Keystone

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

* Re: IGMP on IPv6
  2017-04-18 17:12       ` Murali Karicheri
@ 2017-04-18 17:20         ` Murali Karicheri
  2017-04-18 22:37           ` Cong Wang
  0 siblings, 1 reply; 10+ messages in thread
From: Murali Karicheri @ 2017-04-18 17:20 UTC (permalink / raw)
  To: Cong Wang; +Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

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

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

* Re: IGMP on IPv6
  2017-04-18 17:20         ` Murali Karicheri
@ 2017-04-18 22:37           ` Cong Wang
  2017-04-25 16:16             ` Murali Karicheri
  0 siblings, 1 reply; 10+ messages in thread
From: Cong Wang @ 2017-04-18 22:37 UTC (permalink / raw)
  To: Murali Karicheri
  Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

On Tue, Apr 18, 2017 at 10:20 AM, Murali Karicheri <m-karicheri2@ti.com> wrote:
> 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.

OK. Note: I know nothing about HSR, I assume it is similar to bonding
in your case?

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

Did you assign IPv4 and IPv6 addresses to the HSR master device?

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

* Re: IGMP on IPv6
  2017-04-18 22:37           ` Cong Wang
@ 2017-04-25 16:16             ` Murali Karicheri
  2017-04-26  5:24               ` Cong Wang
  0 siblings, 1 reply; 10+ messages in thread
From: Murali Karicheri @ 2017-04-25 16:16 UTC (permalink / raw)
  To: Cong Wang; +Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

On 04/18/2017 06:37 PM, Cong Wang wrote:
> On Tue, Apr 18, 2017 at 10:20 AM, Murali Karicheri <m-karicheri2@ti.com> wrote:
>> 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.
> 
> OK. Note: I know nothing about HSR, I assume it is similar to bonding
> in your case?
> 

Similar in the sense it glues two standard Ethernet interfaces and run
HSR protocol frames over it to support redundancy.

>>>
>>> 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
> 
> Did you assign IPv4 and IPv6 addresses to the HSR master device?

No. I just used IPv4. From the trace mld_ifc_timer_expire() -> mld_sendpack() -> ip6_output()
do you know what is it trying to do? Is it some neighbor discovery message or something
going over the lower interface instead of the hsr interface?

Murali

> 


-- 
Murali Karicheri
Linux Kernel, Keystone

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

* Re: IGMP on IPv6
  2017-04-25 16:16             ` Murali Karicheri
@ 2017-04-26  5:24               ` Cong Wang
  0 siblings, 0 replies; 10+ messages in thread
From: Cong Wang @ 2017-04-26  5:24 UTC (permalink / raw)
  To: Murali Karicheri
  Cc: Hangbin Liu, open list:TI NETCP ETHERNET DRIVER, David Miller

On Tue, Apr 25, 2017 at 9:16 AM, Murali Karicheri <m-karicheri2@ti.com> wrote:
> On 04/18/2017 06:37 PM, Cong Wang wrote:
>> Did you assign IPv4 and IPv6 addresses to the HSR master device?
>
> No. I just used IPv4. From the trace mld_ifc_timer_expire() -> mld_sendpack() -> ip6_output()
> do you know what is it trying to do? Is it some neighbor discovery message or something
> going over the lower interface instead of the hsr interface?
>

IPv6 is special here because it has link-local address configured
automatically for each device, so this mld_ifc_timer is armed
for link-local multicasts. See:


 464         /* Join interface-local all-node multicast group */
 465         ipv6_dev_mc_inc(dev, &in6addr_interfacelocal_allnodes);
 466
 467         /* Join all-node multicast group */
 468         ipv6_dev_mc_inc(dev, &in6addr_linklocal_allnodes);
 469
 470         /* Join all-router multicast group if forwarding is set */
 471         if (ndev->cnf.forwarding && (dev->flags & IFF_MULTICAST))
 472                 ipv6_dev_mc_inc(dev, &in6addr_linklocal_allrouters);

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

end of thread, other threads:[~2017-04-26  5:25 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2017-04-18 22:37           ` Cong Wang
2017-04-25 16:16             ` Murali Karicheri
2017-04-26  5:24               ` Cong Wang

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.