netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>, Oliver Neukum <oneukum@suse.com>,
	Aaron Ma <aaron.ma@canonical.com>,
	henning.schild@siemens.com, linux-usb@vger.kernel.org,
	netdev@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: Tue, 11 Jan 2022 08:57:39 -0600	[thread overview]
Message-ID: <ec2aaeb0-995e-0259-7eca-892d0c878e19@amd.com> (raw)
In-Reply-To: <CAAd53p5mSq_bZdsZ=-RweiVLgAYU5+=Uje7TmYtAbBzZ7XCPUA@mail.gmail.com>

On 1/10/2022 19:51, Kai-Heng Feng wrote:
> [+Cc Mario Limonciello, the original author on MAC pass-through]
> 
> On Tue, Jan 11, 2022 at 12:51 AM Jakub Kicinski <kuba@kernel.org> wrote:
>>
>> On Mon, 10 Jan 2022 11:32:16 +0800 Kai-Heng Feng wrote:
>>>>> I don't think it's a good idea. On my laptop,
>>>>> systemd-udev-settle.service can add extra 5~10 seconds boot time
>>>>> delay.
>>>>> Furthermore, the external NIC in question is in a USB/Thunderbolt
>>>>> dock, it can present pre-boot, or it can be hotplugged at any time.
>>>>
>>>> IIUC our guess is that this feature used for NAC and IEEE 802.1X.
>>>> In that case someone is already provisioning certificates to all
>>>> the machines, and must provide a config for all its interfaces.
>>>> It should be pretty simple to also put the right MAC address override
>>>> in the NetworkManager/systemd-networkd/whatever config, no?
>>>
>>> If that's really the case, why do major OEMs came up with MAC
>>> pass-through? Stupid may it be, I don't think it's a solution looking
>>> for problem.
>>
>> I don't know. Maybe due to a limitation in Windows? Maybe it's hard to
>> do in network manager, too, and we're not seeing something. Or perhaps
>> simply because they want to convince corporations to buy their
>> unreasonably expensive docks.
>>
>> What I do know is that we need to gain a good understanding of the
>> motivation before we push any more of such magic into the kernel.
> 
> Mario, do you know how corporate network and other OS handle MAC
> pass-through, so we can come up with a more robust design?

The important thing to remember is that many of these machines *don't*
have in-built network controller and rely upon a USB-c network adapter.

I recall a few reasons.

1) Consistency with the UEFI network stack and dual booting Windows when 
using the machine.  IOW 1 DHCP lease to one network controller, not one OS.

2) A (small) part of an onion that is network security.  It allows 
administrators to allow-list or block-list controllers.

The example I recall hearing is someone has their laptop stolen and 
notifies I/T.  I/T removes the MAC address of the pass through address
from the allow-list and now that laptop can't use any hotel cubes for 
accessing network resources.

3) Resource planning and management of hoteling resources.

For example allow facilities to monitor whether users are reserving and 
using the hoteling cubes they reserved.

> 
> Kai-Heng
> 
>>
>> I may be able to do some testing myself after the Omicron surge is over
>> in the US.


  reply	other threads:[~2022-01-11 14:57 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 [this message]
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
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=ec2aaeb0-995e-0259-7eca-892d0c878e19@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=aaron.ma@canonical.com \
    --cc=andrew@lunn.ch \
    --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-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).