linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Oliver Neukum <oneukum@suse.com>,
	Aaron Ma <aaron.ma@canonical.com>,
	kuba@kernel.org, henning.schild@siemens.com,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	hayeswang@realtek.com, tiwai@suse.de
Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address
Date: Fri, 7 Jan 2022 14:32:25 +0100	[thread overview]
Message-ID: <YdhA6QqOKQ19uKWG@lunn.ch> (raw)
In-Reply-To: <CAAd53p5YnQZ0fDiwwo-q3bNMVFTJSMLcdkUuH-7=OSaRrW954Q@mail.gmail.com>

> > You should be thinking of this in more general terms. You want to
> > design a system that will work for any vendors laptop and dock.
> >
> > You need to describe the two interfaces using some sort of bus
> > address, be it PCIe, USB, or a platform device address as used by
> > device tree etc.
> >
> > Let the kernel do whatever it wants with MAC addresses for these two
> > interfaces. The only requirement you have is that the laptop internal
> > interface gets the vendor allocated MAC address, and that the dock get
> > some sort of MAC address, even if it is random.
> 
> Those laptops and docks are designed to have duplicated MACs. I don't
> understand why but that's why Dell/HP/Lenovo did.

But it also sounds like the design is broken. So the question is, is
it possible to actually implement it correctly, without breaking
networking for others with sane laptop/docks/USB dongles.

> What if the kernel just abstract the hardware/firmware as intended, no
> matter how stupid it is, and let userspace to make the right policy?

Which is exactly what is being suggested here. The kernel gives the
laptop internal interface its MAC address from ACPI or where ever, and
the dock which has no MAC address gets a random MAC address. That is
the normal kernel abstract. Userspace, in the form of udev, can then
change the MAC addresses in whatever way it wants.

> But power users may also need to use corporate network to work as
> Aaron mentioned.
> Packets from unregistered MAC can be filtered under corporate network,
> and that's why MAC pass-through is a useful feature that many business
> laptops have.

Depends on the cooperate network, but power users generally know more
than the IT department, and will just make their machine work, copying
the 802.3x certificate where ever it needs to go, us ebtables to
mangle the MAC address, build their own little network with an RPi
acting as a gateway doing NAT and MAC address translation, etc.

       Andrew

  parent reply	other threads:[~2022-01-07 13:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 15:14 [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Aaron Ma
2022-01-05 15:14 ` [PATCH 2/3] net: usb: r8152: Set probe mode to sync Aaron Ma
2022-01-05 15:33   ` Greg KH
2022-01-05 15:14 ` [PATCH 3/3] net: usb: r8152: remove unused definition Aaron Ma
2022-01-05 15:34   ` Greg KH
2022-01-05 15:31 ` [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address Greg KH
2022-01-05 15:57 ` Henning Schild
2022-01-05 17:30 ` Andrew Lunn
2022-01-05 17:40   ` Henning Schild
2022-01-05 21:49   ` Oliver Neukum
2022-01-05 22:27     ` Andrew Lunn
2022-01-06  2:10       ` Kai-Heng Feng
2022-01-06 13:27         ` Andrew Lunn
2022-01-07  2:01           ` Kai-Heng Feng
2022-01-07  2:31             ` Jakub Kicinski
2022-01-10  3:32               ` Kai-Heng Feng
2022-01-10 16:51                 ` Jakub Kicinski
2022-01-11  1:51                   ` Kai-Heng Feng
2022-01-11 14:57                     ` Limonciello, Mario
2022-01-11 16:26                       ` Jakub Kicinski
2022-01-11 16:33                         ` Limonciello, Mario
2022-01-11 16:43                           ` Jakub Kicinski
2022-01-11 16:54                             ` Limonciello, Mario
2022-01-11 17:06                               ` Jakub Kicinski
2022-01-11 17:10                                 ` Limonciello, Mario
2022-01-12 19:21                                   ` Henning Schild
2022-01-12 19:27                                     ` Limonciello, Mario
2022-01-13  3:23                                       ` Aaron Ma
2022-01-27  2:51                                         ` Aaron Ma
2022-01-27  8:06                                           ` Hayes Wang
2022-01-27  8:13                                             ` Aaron Ma
2022-01-27  8:42                                               ` Hayes Wang
2022-01-27 12:53                                             ` Andrew Lunn
2022-01-07 13:32             ` Andrew Lunn [this message]
2022-01-10  3:39               ` Kai-Heng Feng
2022-01-10 11:39 ` Oliver Neukum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YdhA6QqOKQ19uKWG@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=aaron.ma@canonical.com \
    --cc=davem@davemloft.net \
    --cc=hayeswang@realtek.com \
    --cc=henning.schild@siemens.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).