netdev - Re: [PATCH v3 net-next 03/15] net: dsa: tag_sja1105: request promiscuous mode for master

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: <20200926202252.GB3887691@lunn.ch>
Date:   Sat, 26 Sep 2020 22:22:52 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, f.fainelli@...il.com,
        vivien.didelot@...il.com, kuba@...nel.org
Subject: Re: [PATCH v3 net-next 03/15] net: dsa: tag_sja1105: request
 promiscuous mode for master

On Sat, Sep 26, 2020 at 10:32:03PM +0300, Vladimir Oltean wrote:
> Currently PTP is broken when ports are in standalone mode (the tagger
> keeps printing this message):
> 
> sja1105 spi0.1: Expected meta frame, is 01-80-c2-00-00-0e in the DSA master multicast filter?
> 
> Sure, one might say "simply add 01-80-c2-00-00-0e to the master's RX
> filter" but things become more complicated because:
> 
> - Actually all frames in the 01-80-c2-xx-xx-xx and 01-1b-19-xx-xx-xx
>   range are trapped to the CPU automatically
> - The switch mangles bytes 3 and 4 of the MAC address via the incl_srcpt
>   ("include source port [in the DMAC]") option, which is how source port
>   and switch id identification is done for link-local traffic on RX. But
>   this means that an address installed to the RX filter would, at the
>   end of the day, not correspond to the final address seen by the DSA
>   master.
> 
> Assume RX filtering lists on DSA masters are typically too small to
> include all necessary addresses for PTP to work properly on sja1105, and
> just request promiscuous mode unconditionally.
> 
> Just an example:
> Assuming the following addresses are trapped to the CPU:
> 01-80-c2-00-00-00 to 01-80-c2-00-00-ff
> 01-1b-19-00-00-00 to 01-1b-19-00-00-ff
> 
> These are 512 addresses.
> Now let's say this is a board with 3 switches, and 4 ports per switch.
> The 512 addresses become 6144 addresses that must be managed by the DSA
> master's RX filtering lists.
> 
> This may be refined in the future, but for now, it is simply not worth
> it to add the additional addresses to the master's RX filter, so simply
> request it to become promiscuous as soon as the driver probes.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew