netdev - should kernel IGMP rejoin on link up ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 4 Sep 2012 14:19:48 +0200
From:	Simon Paillard <simon.paillard@...el.enst-bretagne.fr>
To:	netdev@...r.kernel.org
Subject: should kernel IGMP rejoin on link up ?

Hello,

Here is a scenario where IMO the kernel is not doing the job, where a host
running linux kernel is connected to a switch with igmp snooping enabled:
- nominal case: an interface is member of a multicast group, reports are
  performed 
- failure of link (like cable disconnected)
- the switch flushes the multicast membership for that port
- link is back
- kernel waits for switch query to report membership

-> The application miss packets until next General Query (default value in RFC:
125 seconds)

I cannot find in IGMPv2 RFC a specification of the behaviour to follow in such
a case, but :
- having a very little query interval would affect all the network, and polling
  is not a clean way. 
- it's imo not the application job to check for link failure and issue again
  joins

So I wonder if the kernel should rejoin when interface link flag is up
(ip_mc_rejoin_groups() is already used by bonding code when a new interface is
up).

The next question, if you agree that should be the kernel job, is where the fix
should be located.

Thanks.

PS: I know little about MLD in IPv6, I didn't see in bonding code something
related to MLD, but I guess the same question applies.

(Please CC me on replies)

-- 
Simon Paillard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html