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: <20090318140353.GA9771@hmsreliant.think-freely.org>
Date:	Wed, 18 Mar 2009 10:03:53 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	netdev@...r.kernel.org
Cc:	davem@...emloft.net, andy@...yhouse.net, dlstevens@...ibm.com
Subject: Question: igmp behavior on interface change

Hey-
	Was wondering if anyone wanted to chime in on this.  Someone asked me
recently what our behavior should be in response to in interface link state
change in regards to multicast reception.  They claim that if an mc group is
joined, and we issue an igmp join request via, say eth0, and then preform an
ifdown/ifup on that interface, that frames stop getting delivered for that
group.  I'm having this confirmed, but its my guess that in response to the link
flap, the attached router on the other end of the link has unsubscribed from the
group in response to the link state change.

	So my question is, whats the right behavior here?  Reading RFC 3376,
seems to suggest that we need to issue a state-change report as soon as the link
goes back up, but its vague, I could see an argument being made for both the
host and the router to keep their mc group state unchanged and let membership
queries ages the groups out as per normal.

	I was going to look into writing some notification code for igmp to
detect link state chagnes and issue the reports on link up, but I wanted to be
sure there were no counter arguments first.  So any and all thoughts
appreciated.

Thanks!
Neil

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