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