Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B446C433F5 for ; Mon, 10 Jan 2022 03:41:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238384AbiAJDjg (ORCPT ); Sun, 9 Jan 2022 22:39:36 -0500 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]:53928 "EHLO smtp-relay-internal-0.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236129AbiAJDjf (ORCPT ); Sun, 9 Jan 2022 22:39:35 -0500 Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id E0A7F406EA for ; Mon, 10 Jan 2022 03:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1641785973; bh=pQ19/9SUWFmu9QWaYJWAgIjttlL4E8YQab0OKaz5DsA=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=q2ptJYO0ewt7UUY7kt1GbShK1W0z0kKUwbRBZu6eR+mUYTm6U7TmxRrjFGRQ0p/oi J1+kjTpKauoqglTasIXygBnMIg49eYRcpnyG96oDKrkmQnYewO3qHhjGxaGgjxlCPf miUwWYzBAIbqYBm0pHPKeridO1fm1ub+Glm7RXv2OAIgbVfrgrZfwvGiGUimx16N2v /lLSsBwvDqBdjglcD0qaurme8Miw9JPqhFb8N/8aJw5jfpmQ2XtkZHokm2xOiN9ZkE OXeFDyfP0I67dh0ggxDheLnE7xSmSBWwuFf9fw9r8I0MorXhqPidL+P7Arz1PZkbC/ 7DnHcK9eAfhcw== Received: by mail-oo1-f69.google.com with SMTP id b8-20020a4a9bc8000000b002c5d4b37b30so7959730ook.3 for ; Sun, 09 Jan 2022 19:39:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pQ19/9SUWFmu9QWaYJWAgIjttlL4E8YQab0OKaz5DsA=; b=wNPk7bftDcOU0a774HpVQeZvSlBX2bw4uHvlCPQJ44NIYJs4Kt6SQAceLQavhXTHCQ Ig7H0JjLuejXx2T8Og4Vck+iETKkPfw3cA3Ay4opLwWKjl3P4ncmn12ssTGj8V+fg4Pd 9vo1bANvxqVuNGst78JM/ZN50LZgm4PllVf9CY1Nw7OuguwK+OjVqKIBl2e+otTqlxUk 4XZpKcaVQiUEp9vGkmJVvUYL0rXCH7fJ+tEuclO9y3HkghhElQQoX72a98nSCnn1Pxjr JQ95iGkCAV+hOZ9YO6BeGf0FkyDFxjnhcnP/4RQhJA8AFOUm0ZeGtrVGttaaLCx7Qgf6 go5g== X-Gm-Message-State: AOAM5304sdko4U/CrIuhox1FSNnQnE4z1N8vy2cVa0Ap7ybAKkXSRPiu 0YulLIuGt1dsaJjKIPlG4ap+GA01ogVtVmmGrTz0/BWsO/qSUC1Kc6zM0DrJ4/BM3pQwOPo1s0q 9Ie17UL+VNCh8UrP5vQzvKSBTxAOdL6sHCpAAkAVVAK1RE9f5/DcGb0vUVw== X-Received: by 2002:a05:6808:198c:: with SMTP id bj12mr3768728oib.146.1641785972687; Sun, 09 Jan 2022 19:39:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJz05xk4ZBJfcYO9IQwZKVBtMGSiPz0jY4s034Wxc925wwPuDP2ai5KfuJBp99zDtCJRoyXhOt6lcdvyHA9pNDU= X-Received: by 2002:a05:6808:198c:: with SMTP id bj12mr3768719oib.146.1641785972457; Sun, 09 Jan 2022 19:39:32 -0800 (PST) MIME-Version: 1.0 References: <20220105151427.8373-1-aaron.ma@canonical.com> In-Reply-To: From: Kai-Heng Feng Date: Mon, 10 Jan 2022 11:39:21 +0800 Message-ID: Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address To: Andrew Lunn Cc: Oliver Neukum , Aaron Ma , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 7, 2022 at 9:32 PM Andrew Lunn wrote: > > > > 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. It's possible, just stick to whitelist and never over generalize the device matching rule. > > > 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. That's not what I mean. I mean the kernel should do what firmware/hardware expects kernel should do - copy the MAC from ACPI to the external NIC in the dock. Then the userspace can assign a random MAC to external interface if internal interface is already up. > > > 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. That's true, but as someone who work closely with other Distro folks, we really should make this feature works for (hopefully) everyone. Kai-Heng > > Andrew