netdev - BUG: DSA blocks (some?) multicast traffic

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

Message-ID: <20180416160020.GV16141@n2100.armlinux.org.uk>
Date:   Mon, 16 Apr 2018 17:00:20 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:     netdev@...r.kernel.org
Subject: BUG: DSA blocks (some?) multicast traffic

Hi,

Yesterday, I noticed that one of my platforms had become unreachable
over IPv6.  This platform is connected to a Clearfog, which uses
the Marvell 88e6176 switch.

The setup is:

               (rest of network)
                 | | | | | | |
    Source ---- Netgear switch ---- Clearfog switch ---- Target
                                    ^             ^      ^
                                   lan1          lan5   eth2
                                  port 4        port 0

Both the source and target could ping the IPv6 link-local address on
the clearfog, and IPv4 traffic was fine.

The source was attempting to ping the target, and the target had been
attempting to mount a NFS share over IPv6 (and failing.)

Statistics from the Clearfog switch - port 0 is the target, port 4 is
the netgear switch, port 5 is the CPU port:

     Statistic   Port  0  Port  1  Port  2  Port  3  Port  4  Port  5  Port  6
 in_multicasts:    27670        0        0    14552    78196     1674        0
out_multicasts:      439        0      331      332      331   114860      334

As you can see, very few multicast packets have been sent out any of
the ports.

Running tcpdump on the source machine:

21:31:48.805654 xx:xx:xx:15:37:dd > 33:33:ff:00:00:05,
	ethertype IPv6 (0x86dd), length 86:
	fd8f:xxxx:xxxx:xxxx:222:68ff:fe15:37dd > ff02::1:ff00:5:
	ICMP6, neighbor solicitation, who has
	fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5, length 32

tcpdump on the clearfog for port 4:

21:31:48.807640 xx:xx:xx:15:37:dd > 33:33:ff:00:00:05,
	ethertype IPv6 (0x86dd), length 86:
	fd8f:xxxx:xxxx:xxxx:222:68ff:fe15:37dd > ff02::1:ff00:5:
	ICMP6, neighbor solicitation, who has
	fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5, length 32

The port connected to the target doesn't see these multicast messages
which are intended for it.  However, I am able to see messages
multicasted from the target, which is trying to solicit a different
machine on my network:

21:33:22.394653 00:00:00:00:00:05 > 33:33:ff:10:1b:e6,
	ethertype IPv6 (0x86dd), length 86:
	fd8f:xxxx:xxxx:xxxx:200:ff:fe00:5 > ff02::1:ff10:1be6:
	ICMP6, neighbor solicitation, who has
	fd8f:xxxx:xxxx:xxxx:214:fdff:fe10:1be6, length 32

but these neighbour solicitations are also not forwarded to through
the switch to the rest of the network.

Tweaking the DSA switch port register 4 (which had a value of 0x0433)
to 0x043b resolved the issue - multicast traffic started to egress
these ports, and the neighbour solicitations then worked.

I thought maybe this was a 4.16 regression, but it seems my other
clearfog has a similar register setup, so I'm not sure.  I'm pretty
sure that it used to work at some point, as I'm a heavy user of IPv6
internally, and I'm quite certain that I would have noticed a failure
such as this.

The setup on the target is eth2 is part of a Linux bridge device.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up