© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
No, I described setting up a bridge in the guest with the mcast NIC!
So the bug-triggering guest needs only one NIC, eth0, which is defined like this:
<interface type='mcast'>
<mac address='...'/>
<source address='...' port='5558'/>
</interface>
(with actual local MAC and multicast address assignments).
After booting that guest, use brctl to create a bridge br0, and simply slave that virtual eth0 to the bridge (as its only "physical" port). This will exhibit the problem, with no real networks involved.
When I mentioned the host LAN, I had created a second NIC in a privileged guest, so it had one mcast NIC and one tap NIC already bridged into the host LAN by libvirt. Then that guest bridged its two NICs, allowing other unprivileged guests to use an mcast NIC to participate in the host LAN. Because of this mcast bug, you can only do this once this privileged guest has the severe ebtables workaround I reported.
But this extra step is unnecessary to demonstrate the bug. It is only interesting in that it does something useful once the ebtables workaround is in place (allowing unprivileged guests to participate in a real LAN).