netdev - Re: Using a bridge for DSA and non-DSA devices

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

Date:   Mon, 5 Dec 2022 22:43:26 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Christian Eggers <ceggers@...i.de>
Cc:     netdev@...r.kernel.org
Subject: Re: Using a bridge for DSA and non-DSA devices

On Mon, Dec 05, 2022 at 09:08:38PM +0100, Christian Eggers wrote:
> No, I didn't. But just to make it clear: Will the DSA framework
> change to "pure software" switching as soon I add the first non-DSA
> slave to an exisiting DSA bridge?

No, DSA doesn't change to pure software switching when foreign interfaces
are added to the bridge. The forwarding decision (hardware or software)
is taken per packet. From the perspective of the DSA switch, a station
behind a foreign bridge port is just behind the CPU port, hence the idea
of managing FDB entries towards that port. Packets forwarded by hardware
are simply not seen by software (if not flooded). Or if they're flooded,
software will set the skb->offload_fwd_mark flag, and this will tell the
bridge that the packet was already flooded to the ksz bridge ports, but
not to other (foreign) bridge ports. So the bridge will clone this skb
and send it to the USB adapter bridge port and what not.

But I'm not sure that you're asking the right question with that bridge,
since you don't seem to need Ethernet bridging with these other technologies.

I don't know what is the most civilized way to solve what you're trying
to achieve ("too many IP addresses when I just want to access the board
over one of the available point-to-point links"?!). Have you considered
putting a unique (routable) IP address on the loopback interface of
your board? If you put 1.2.3.4/32 on lo, Linux should respond to a ping
towards 1.2.3.4 no matter which interface the ICMP request came from.
Granted, the ICMP reply will have the IP address of the connected
interface as source.