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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Jul 2007 12:43:04 -0400 From: Jeff Garzik <jeff@...zik.org> To: Jay Vosburgh <fubar@...ibm.com> CC: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, yoshfuji@...ux-ipv6.org Subject: Re: [PATCH] bonding / ipv6: no addrconf for slaves separately from master Jay Vosburgh wrote: > At present, when a device is enslaved to bonding, if ipv6 is > active then addrconf will be initated on the slave (because it is closed > then opened during the enslavement processing). This causes DAD and RS > packets to be sent from the slave. These packets in turn can confuse > switches that perform ipv6 snooping, causing them to incorrectly update > their forwarding tables (if, e.g., the slave being added is an inactve > backup that won't be used right away) and direct traffic away from the > active slave to a backup slave (where the incoming packets will be > dropped). > > This patch alters the behavior so that addrconf will only run on > the master device itself. I believe this is logically correct, as it > prevents slaves from having an IPv6 identity independent from the > master. This is consistent with the IPv4 behavior for bonding. > > This is accomplished by (a) having bonding set IFF_SLAVE sooner > in the enslavement processing than currently occurs (before open, not > after), and (b) having ipv6 addrconf ignore UP and CHANGE events on > slave devices. > > The eql driver also uses the IFF_SLAVE flag. I inspected eql, > and I believe this change is reasonable for its usage of IFF_SLAVE, but > I did not test it. > > Signed-off-by: Jay Vosburgh <fubar@...ibm.com> applied - 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