From: "Tj (Elloe Linux)" <ml.linux@elloe.vision>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vladimir Oltean <olteanv@gmail.com>,
netdev@vger.kernel.org, chris.packham@alliedtelesis.co.nz,
f.fainelli@gmail.com, marek.behun@nic.cz,
vivien.didelot@gmail.com, info <info@turris.cz>
Subject: Re: dsa: mv88e6xxx not receiving IPv6 multicast packets
Date: Sun, 15 Nov 2020 17:19:26 +0000 [thread overview]
Message-ID: <79ad87d1-15e0-7ccc-e1ad-4aab3fdf0d20@elloe.vision> (raw)
In-Reply-To: <20201115160244.GD1701029@lunn.ch>
[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.
next prev parent reply other threads:[~2020-11-15 17:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 14:46 dsa: mv88e6xxx losing DHCPv6 solicit packets / IPv6 multicast packets? Marek Behún
2020-07-23 21:27 ` Chris Packham
2020-07-23 21:33 ` Florian Fainelli
2020-07-24 10:24 ` Tj (Elloe Linux)
2020-11-14 15:39 ` dsa: mv88e6xxx not receiving IPv6 multicast packets Tj (Elloe Linux)
2020-11-14 15:56 ` Andrew Lunn
2020-11-14 16:06 ` Tj (Elloe Linux)
2020-11-14 17:43 ` Marek Behun
2020-11-14 18:49 ` Vladimir Oltean
2020-11-15 10:53 ` Tj (Elloe Linux)
2020-11-15 16:02 ` Andrew Lunn
2020-11-15 17:19 ` Tj (Elloe Linux) [this message]
2020-11-15 17:27 ` Andrew Lunn
2020-11-16 7:07 ` Tj (Elloe Linux)
2020-11-16 10:45 ` Tj (Elloe Linux)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79ad87d1-15e0-7ccc-e1ad-4aab3fdf0d20@elloe.vision \
--to=ml.linux@elloe.vision \
--cc=andrew@lunn.ch \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=f.fainelli@gmail.com \
--cc=info@turris.cz \
--cc=marek.behun@nic.cz \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox