netdev - Re: [Bridge] [PATCH net-next] net: bridge: add support for IGMP/MLD stats and export them via netlink

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: <20160628110321.GA3221@otheros>
Date:	Tue, 28 Jun 2016 13:03:21 +0200
From:	Linus Lüssing <linus.luessing@...3.blue>
To:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:	netdev@...r.kernel.org, roopa@...ulusnetworks.com,
	bridge@...ts.linux-foundation.org, davem@...emloft.net
Subject: Re: [Bridge] [PATCH net-next] net: bridge: add support for IGMP/MLD
 stats and export them via netlink

On Mon, Jun 27, 2016 at 08:10:48PM +0200, Nikolay Aleksandrov via Bridge wrote:
> These are invaluable when monitoring or debugging complex multicast setups
> with bridges.

Indeed! Great patch :). Especially if people are unable to provide
pcap files for debugging (due to whatever reason). Hopefully that
will help with bugzilla ticket #99081, too...

I know it might not quite fit into your current patch, which simply
stores the ICMPv6 and IGMP type in the bridge private skb->cb, but
do you think you could count and export the following two more
things, too:

* MLDv1 vs. MLDv2 querier (and IGMP accordingly)
* Number of (potential) MLD/IGMP parse errors
  (e.g. beginning of br_multicast_ipv{4,6}_rcv():
   http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.5#L1588 and
   http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.5#L1634)

The former would help to know how the network is expected to
behave (for instance whether you should see MLDv2 reports at all or
whether / how much report suppression to expect).

The latter would help to spot either potential IGMP/MLD parsing bugs in
the bridge or malformed IGMP/MLD messages send by someone else.

Ideally, there would be per port counters again for the overall
IPv4/IPv6 multicast traffic. That would help for multicast streams
for instance, to easily see whether multicast counters increase
rapidly on the ports you would expect them to. And whether snooping
is working in general for such streames, without needing to check
each port individually via tcpdump, for instance.

Just some thoughts, would love to hear what you think about them.

Regards, Linus