linux-kernel - Re: Multicast snooping fixes and suggestions

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1297966672-3457-1-git-send-email-linus.luessing@web.de>
Date:	Thu, 17 Feb 2011 19:17:50 +0100
From:	Linus Lüssing <linus.luessing@....de>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	bridge@...ts.linux-foundation.org
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: Multicast snooping fixes and suggestions

> These look correct. Did you test them with real traffic?

Yes, I did. With these patches the hashlist and linked lists per port
are being filled correctly for IPv6 - initially. Verified that with
both some printk()s for the per port mglists as well as with vlc. With
patch 5/5 this also worked fine with transient link local addresses,
verified that with 'vlc -vvv "udp://@[ff12::123%eth1]"' on a device
connected to the other one with the bridge and could stream
a video as expected with no multicast traffic on any other bridge port.

However, the MLD queries are/were still broken, the queries initiated
by the bridge device do not get a response from the multicast listeners.
The following additional, attached patches fix this issue.


Last but not least, there are still a couple of bugs I could observe:
- I have attached a laptop with two interfaces with a multicast listener
  each to another PC playing with the bridge device. With the fixes
  below, the laptop sends a multicast listener report to the other PC
  on each interface, however these reports' IPv6 header's source addresses
  seem to be a random one from any of the laptop's two interfaces'
  link local addresses (which has to be a bug in the IPv6 code, as
  this one is generating the reports and not the bridge code) as long
  as it matches the selected multicast address (which was ff12::123 in
  this case).
- If there is no multicast listener present, then the multicast packets
  get flooded on all bridge ports.

And two issues with a little lower priority, I suppose:
- Packets do not get delivered to the bridge interface itself when
  a multicast listener has been started on this bridge interface
  (might be related to http://www.spinics.net/lists/linux-net/msg17556.html,
  so possibly a bug in the IPv6 code again).
~ Quitting of a multicast listener with a MLDv2 message is interpreted as
  a join, resulting in relatively long timeouts - but this MLDv1
  interpretation of MLDv2 messages seems to be intended so far due to its
  simplicity according to the comment in the code.

Cheers, Linus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/