netdev - 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: <CAHvy4Aq=as=K48NZHt3Ek8Yg_AzyFdsmTe92b8SFobzUBM9JNA@mail.gmail.com>
Date: Mon, 19 Aug 2024 15:43:42 +0200
From: Pieter <vtpieter@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

> > > > Previously I could not use DSA because of the macb driver limitation, now
> > > > fixed (max_mtu increase, submitted here). Once I got that working, I notice
> > > > that full DSA was not a compatible use case for my board because of
> > > > requiring the conduit interface to behave as a regular ethernet interface.
> > > > So it's really the unmanaged switch case, which I though I motivated well in
> > > > the patch description here (PHY library, ethtool and switch WoL management).
> > >
> > > If its an unmanaged switch, you don't need DSA, or anything at all
> > > other than MACB. Linux is just a plain host connected to a switch. It
> > > is a little unusual that the switch is integrated into the same box,
> > > rather than being a patch cable away, bit linux does not really see
> > > this difference compared to any other unmanaged switch.
> >
> > That's true in theory but not in practice because without DSA I can't use
> > the ksz_spi.c driver which gives me access to the full register set. I need
> > this for the KSZ8794 I'm using to:
> > - apply the EEE link drop erratum from ksz8795.c
> > - active port WoL which is connected through its PME_N pin
> > - use iproute2 for PHY and connection debugging (link up/down,
> >   packets statistics etc.)
>
> Then it is not an unmanaged switch. You are managing it.
>
> > If there's another way to accomplish the above without DSA, I'd be
> > happy to learn about it.
>
> Its go back to the beginning. Why cannot use you DSA, and use it as a
> manage switch? None of your use-cases above are prevented by DSA.

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

Cheers, Pieter

[1] https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html#common-pitfalls-using-dsa-setups