[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5cd6a70c-ea13-4547-958f-5806f86bfa10@lunn.ch>
Date: Thu, 4 May 2023 21:55:01 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Fabio Estevam <festevam@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Steffen Bätz <steffen@...osonix.de>,
netdev <netdev@...r.kernel.org>
Subject: Re: mv88e6320: Failed to forward PTP multicast
On Thu, May 04, 2023 at 04:40:53PM -0300, Fabio Estevam wrote:
> Hi Andrew,
>
> On Thu, May 4, 2023 at 4:21 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > Do you see the PTP traffic on eth1?
>
> Yes, PTP traffic is seen on eth1.
So it is not a Marvell DSA issue. The frame is making it into the
Linux bridge.
> > What MAC address is the PTP traffic using? Is it a link local MAC
> > address? There are some range of MAC addresses which you are not
> > supposed to forward across a bridge. e.g. you don't forward BPDUs.
> > Take a look at br_handle_frame(). Maybe you can play with
> > group_fwd_mask.
>
> In our case, it is a multicast MAC.
So not 01-80-C2-00-00-0E ?
I don't know how reliable it is, but see:
https://www.ieee802.org/1/files/public/docs2012/new-tc-messenger-tc-ptp-forwarding-1112-v02.pdf
Slide 5 says:
• 01-1B-19-00-00-00 – a general group address
• An 802.1Q VLAN Bridge would forward the frame unchanged.
• 01-80-C2-00-00-0E – Individual LAN Scope group ad
• An 802.1Q VLAN Bridge would drop the frame.
Maybe you are falling into this second case?
You really need to find out where in the Linux bridge it is getting
dropped. It should then be obvious why.
Andrew
Powered by blists - more mailing lists