Hi Jan, Hope your bridge-snooping related issues are resolved with the two new patches present in net. If not just let me/us know. Thanks again for the detailed and helpful reporting! Cheers, Linus On Wed, Mar 05, 2014 at 09:57:52AM -0500, Jan Stancek wrote: > > > > > ----- Original Message ----- > > From: "Linus Lüssing" <linus.luessing@xxxxxx> > > To: "Jan Stancek" <jstancek@xxxxxxxxxx> > > Cc: netdev@xxxxxxxxxxxxxxx, "Florian Westphal" <fwestpha@xxxxxxxxxx>, bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > > Sent: Wednesday, 5 March, 2014 3:27:07 PM > > Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest > > <snip> > > > > > > I hand-crafted one new packet from malformed one used in previous tests. > > > I modified source address from :: to host B link-scope address and changed > > > dst address from ff02::1 to ff02::1:ffaa:aaaa > > > > Okay, again according to your capture the guest is receiving the > > MLD query on its interface but does not react with an MLD report. > > > > Two things I'd like to know: > > > > Is using the link-scope address as a source and "ff02::1" as the > > destination address for the MLD query work for you? > > Yes, I could not trigger it with such query: > http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1.cap > frame 795 -> query > frame 1040 -> MLD report from guest > ~20 seconds later > frame 1507, 1508 -> neigh solicit/advert > frame 1580, 1581 -> neigh solicit/advert > > > > > Is using the link-scope address as a source and "ff02::1:ff00:29" > > as the destination address for the MLD query "work" for you (do > > we see an MLD report from the guest and keep on seeing neighbor > > solicitations from host B then?). > > Yes, this also worked (though I received 2 reports): > http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1_ff0029.cap > frame 446 -> query > frame 448 -> MLD report from guest > frame 465 -> MLD report from guest > frame 689, 690 -> neigh solicit/advert > frame 760, 761 -> neigh solicit/advert > ... > > Both host and guest were running 3.14.0-rc5 with your sanity check patch. > > Regards, > Jan > > > > > For the latter, I don't see anything in particular filtering these > > for a general MLD query wrong destination address in the IPv6 > > code from igmp6_event_query() on. But I suspect that the query > > doesn't even get that far on the kernel of the guest, as it is not > > listening on ff02::1:ffaa:aaaa. Therefore the test with > > "ff02::1:ff00:29", an address the guest is listening on, would be > > interesting. > > > > If that works, then I'm going to make a patch ignore General MLD > > Queries without ff02::1 as their destination address, too. > > > > > > Hm, looking at more checks in igmp6_event_query(), I'm currently > > wondering whether we should only enable the snooping behaviour in > > the bridge when receiving a General MLD Query, so one with "::" in > > the multicast field of the MLD message, instead of activating it > > upon a Multicast-Address-Specific Query, too. That'd seem more > > sane to me, I'm going to make a patch for that tomorrow. > > > > Cheers, Linus > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html