Message-ID: <20220128212024.57ef9c59@md1za8fc.ad001.siemens.net>
Date:   Fri, 28 Jan 2022 21:20:24 +0100
From:   Henning Schild <henning.schild@...mens.com>
To:     "Limonciello, Mario" <Mario.Limonciello@....com>
Cc:     Andrew Lunn <andrew@...n.ch>, Aaron Ma <aaron.ma@...onical.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "hayeswang@...ltek.com" <hayeswang@...ltek.com>,
        "tiwai@...e.de" <tiwai@...e.de>
Subject: Re: [PATCH v3] net: usb: r8152: Add MAC passthrough support for
 RTL8153BL

Am Fri, 28 Jan 2022 18:41:16 +0000
schrieb "Limonciello, Mario" <Mario.Limonciello@....com>:

> [Public]
> 
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: Friday, January 28, 2022 12:07
> > To: Henning Schild <henning.schild@...mens.com>
> > Cc: Aaron Ma <aaron.ma@...onical.com>; Limonciello, Mario
> > <Mario.Limonciello@....com>; kuba@...nel.org;
> > linux-usb@...r.kernel.org; netdev@...r.kernel.org;
> > linux-kernel@...r.kernel.org; gregkh@...uxfoundation.org;
> > davem@...emloft.net; hayeswang@...ltek.com; tiwai@...e.de
> > Subject: Re: [PATCH v3] net: usb: r8152: Add MAC passthrough
> > support for RTL8153BL
> > 
> > On Fri, Jan 28, 2022 at 09:21:03AM +0100, Henning Schild wrote:  
> > > I am still very much against any patches in that direction. The
> > > feature as the vendors envision it does not seem to be really
> > > understood or even explained.
> > > Just narrowing down the device matching caters for vendor lock-in
> > > and confusion when that pass through is happening and when not.
> > > And seems to lead to unmaintainable spaghetti-code.
> > > People that use this very dock today will see an unexpected
> > > mac-change once they update to a kernel with this patch applied.  
> > 
> > I've not yet been convinced by replies that the proposed code really
> > does only match the given dock, and not random USB dongles.   
> 
> Didn't Realtek confirm this bit is used to identify the Lenovo
> devices?

The question is really why we do all that and that answer really seems
missing. Lenovo might have a very different answer than Dell. All i saw
was Lenovo docks that suggest PXE. While that could be a good case,
bootloaders and OSs should then inherit the MAC of a NIC that is
already up. But sure not try and guess what to do and spoof on their
own. (based on weird bits and topology guesses) I am willing to bet that
grub/pxelinux/uboot/systemd-boot would all fail a PXE run even if the
OS to boot would spoof/inherit.

PXE uses spoofed MAC and bootloader will dhcp again and not spoof. dhcp
would time out or fall back to somewhere (MAC not known), Linux kernel
would not come, PXE boot failed.

In fact i have seen first hand how PXE Windows install failed on a
Lenovo dock and the real NIC worked. That was within my company and i
sure do not know the BIOS settings or what bootloader was involved and
if that Windows installer did active spoofing. But i would say that the
PXE story probably does not really "work" for Windows either.
In fact i am willing to bet the BIOS setting for spoofing was turned
on, because it seems to be the factory default.

And all stories beyond PXE-bootstrap should probably be answered with
"a MAC does not identify a machine". So people that care to ident a
machine should use something like x509, or allow network access in any
other way not relying on a MAC. If "Linux" cares to spoof for the lazy
ones, udev is a better place than the kernel.

> > To be
> > convinced i would probably like to see code which positively
> > identifies the dock, and that the USB device is on the correct port
> > of the USB hub within the dock. I doubt you can actually do that in
> > a sane way inside an Ethernet driver. As you say, it will likely
> > lead to unmaintainable spaghetti-code.
> > 
> > I also don't really think the vendor would be keen on adding code
> > which they know will get reverted as soon as it is shown to cause a
> > regression.
> > 
> > So i would prefer to NACK this, and push it to udev rules where you
> > have a complete picture of the hardware and really can identify with
> > 100% certainty it really is the docks NIC.  
> 
> I remember when I did the Dell implementation I tried userspace first.
> 
> Pushing this out to udev has a few other implications I remember
> hitting: 1) You need to also get the value you're supposed to use
> from ACPI BIOS exported some way in userland too.

Sounds like a problem with ACPI in userspace. So the kernel could
expose ACPI in a better shape. Or you will simply need to see what
systemd thinks about a funny "sed | grep | awk | bc" patch to parse
binary. DMI might contain bits, but without clear vendor instructions
we would be guessing (like on ACPI?).

> 2) You can run into race conditions with other device or MAC renaming
> rules. My first try I did it with NM and hit that continually.  So
> you would probably need to land this in systemd or so.

For sure you would end up in systemd (udev). NM is just one of many
options and would be the wrong place. You might quickly find yourself
in mdev (busybox) as well because of that PXE case or because of an
initrd.

If it was my call i would revert all mac passthough patches and request
Lenovo/Dell and others to present their case first hand. (no
canonical/amd/suse proxies)
The "feature" causes MAC collisions and is not well understood/argued by
anyone.

https://en.wikipedia.org/wiki/MAC_address

> A media access control address (MAC address) is a unique identifier
> assigned to a network interface controller (NIC) ...

unique and NIC, as opposed to colliding and machine

Henning
 
> > 
> >    Andre  

Powered by blists - more mailing lists