netdev - Re: dsa: mv88e6xxx not receiving IPv6 multicast packets

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: <79ad87d1-15e0-7ccc-e1ad-4aab3fdf0d20@elloe.vision>
Date:   Sun, 15 Nov 2020 17:19:26 +0000
From:   "Tj (Elloe Linux)" <ml.linux@...oe.vision>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org,
        chris.packham@...iedtelesis.co.nz, f.fainelli@...il.com,
        marek.behun@....cz, vivien.didelot@...il.com, info <info@...ris.cz>
Subject: Re: dsa: mv88e6xxx not receiving IPv6 multicast packets

[On 15/11/2020 16:02, Andrew Lunn wrote:

> What might be interesting is running
> 
> ip monitor
> 
> and
> 
> bridge monitor
> 
> Look for neighbours being timed out do to inactivity.

Funny you write that! This afternoon I've narrowed it down although I
still don't understand the 'why'.

Watching on the 'good' (lab) and 'bad' (gateway) Mox devices I noticed that:

# bridge -d -s mdb show

23: br-lan  br-lan  ff02::2  temp   257.05

23: br-lan  br-lan  ff05::2  temp   257.05

23: br-lan  br-lan  ff02::6a  temp   257.05
23: br-lan  br-lan  ff02::1:ff77:2b20  temp   257.05
23: br-lan  br-lan  ff02::1:ff00:ffff  temp   257.05

23: br-lan  br-lan  ff02::fb  temp   257.05

23: br-lan  br-lan  ff02::1:ff00:0  temp   257.05
23: br-lan  br-lan  ff02::1:2  temp   257.05
23: br-lan  br-lan  ff05::1:3  temp   257.05

indicates that the entries time out on 'bad' but are reset to a high
value on 'good'

# bridge monitor on 'bad' reported:

Deleted Deleted 23: br-lan  br-lan  ff02::2  temp
Deleted Deleted 23: br-lan  br-lan  ff05::2  temp
Deleted Deleted 23: br-lan  br-lan  ff02::6a  temp
Deleted Deleted 23: br-lan  br-lan  ff02::1:ff77:2b20  temp
Deleted Deleted 23: br-lan  br-lan  ff02::1:ff00:ffff  temp
Deleted Deleted 23: br-lan  br-lan  ff02::fb  temp
Deleted Deleted 23: br-lan  br-lan  ff02::1:ff00:0  temp
Deleted Deleted 23: br-lan  br-lan  ff02::1:2  temp
Deleted Deleted 23: br-lan  br-lan  ff05::1:3  temp

On the laptop I'm testing from (tcpdump always on the laptop):

Using tcpdump I *think* enp2s0 (wired link direct into lan1 on 'good')
always showed the laptop sending multicast listener report v2 packets on
a regular cadence of about 60-100 seconds as well as the DHCPv6
solicit/renews and that cadence matched when the timers on the output of
"bridge -d -s mdb show" reset to approximately 258.

But for wlp4s0 (wifi to 'bad') the DHCPv6 solicit/renew didn't seem to
be accompanied by multicast listener reports and the mdb timers expired.

I need to re-affirm that tomorrow because I've got slightly lost
attempting to compare multiple aspects on both 'good' and 'bad' and seem
to be seeing inconsistent results.

On the laptops we are using Xubuntu 20.04 amd64 with NetworkManager.
I'll try to test from a range of different devices tomorrow in case this
is only affecting staff laptops.

Many thanks for the pointers.