linux-kernel - Re: [PATCH net-next 2/2] net: dsa: microchip: add KSZ8 change_tag

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: <e4cbc2c4-366c-442b-983b-cdba71b9fb90@lunn.ch>
Date: Mon, 19 Aug 2024 16:13:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Pieter <vtpieter@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>,
	Woojung Huh <woojung.huh@...rochip.com>,
	UNGLinuxDriver@...rochip.com,
	Florian Fainelli <f.fainelli@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>,
	Pieter Van Trappen <pieter.van.trappen@...n.ch>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net: dsa: microchip: add KSZ8
 change_tag_protocol support

> Right so I'm managing it but I don't care from which port the packets
> originate, so I could disable the tagging in my case.

> My problem is that with tagging enabled, I cannot use the DSA conduit
> interface as a regular one to open sockets etc. I don't fully understand
> why I have to admit but it's documented here [1] and with wireshark I
> can see only control packets going through, the ingress data ones are
> not tagged and subsequently dropped by the switch with tagging enabled.
> 
> PS here are my iproute2 commands:
> ip link set lan1 up
> ip link set lan2 up
> ip link add br0 type bridge
> ip link set lan1 master br0
> ip link set lan2 master br0
> ip link set br0 up

So forget about the switch for the moment. Just think about having two
network interfaces. They could be intel e1000e, macb, whatever. You
would use the exact same commands above to setup a bridge so packets
would flow between them. This is all standard Linux networking,
nothing special. You would typically add an IPv4/IPv6 address on br0,
or run a DHCP client on it. lan1 and lan2 don't have IP addresses,
only the br0. Any sockets you open and don't bind to a specific
interface will make use of the IP addresses on the br0, since that is
the only interface with an IP address. The Linux software bridge will
determine which interface packets go out of, or perform flooding if
the destination MAC address is not know etc.

DSA does not change any of this. DSA just allows Linux to offload what
it is doing in software to the hardware. You use the same commands as
above. If you want to bind your socket to a local interface, you bind
it to br0, nothing different. The software bridge will still determine
the egress interface, and pass the frame to the hardware. The hardware
itself should be able to handle frames which ingress one port and
egress another, i.e. that bit of bridging has been offloaded to the
hardware.

The name 'conduit' is supposed to give you a clue. It is just a
conduit, nothing more. It is part of the plumbing to make DSA
work. But apart from ensuring it is up, you don't do anything with
it. You operate on lan1, lan2, and anything you build on top of those,
e.g. a bridge, bonds, vlan interfaces.

     Andrew