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]
Message-ID: <20120904121948.GJ11825@glenfiddich.mraw.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ