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]
Date:	Tue, 28 Jun 2016 14:02:07 +0200
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	Linus Lüssing <linus.luessing@...3.blue>
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 28/06/16 13:03, Linus Lüssing wrote:
> 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
> 

Hi Linus,
I think these are all reasonable and helpful things to export in addition. I will
definitely look into extending the stats with them. If this patch is accepted as-is
I'll just do it as a follow-up.

Thanks for the good suggestions!

Cheers,
 Nik

Powered by blists - more mailing lists