From nobody Mon Nov 20 22:03:50 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SZ1k16Df6z518r9 for ; Mon, 20 Nov 2023 22:03:53 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZ1k144RKz4HTs; Mon, 20 Nov 2023 22:03:53 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3AKM3p0U073134; Mon, 20 Nov 2023 16:03:51 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1700517832; bh=t61p+KMGAfZn+45lmJTVagt2gun6wGqtg5p4/dz6bZI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=rxm1WttddbXxz/hKi+f4d/dLgiGDNFbo3zoej5ywd5FuhwS3m7zktoZ1g/reC7kC0 6YM/D94eKs3iDyfYhinuZJlfwuNhsFHq/7JazArFDf3daSbttQ3emeBA2zri++qzYO BO2NCYjZIKUewLlVLKAFWYJfWx3xyT+Y9A/DWjIkywcfPAEu4e6lrRAAyHQ0z/Q8EI 8OU5ExX/s4ZInk+8KnzCY6ouc40EFoVkoPeO+zMe8LQea5ZuU8vy7jHn87K9CdTCOW RSfCSn6vAoJEtRbIu70QjGgEgr4N2u0O8HrydO9z9mUUvdPW5a9Oev0iWi+JmiZ1UV g/L5mtfjR5p0w== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id DvgJK8fXW2WsHQEAs/W3XQ (envelope-from ); Mon, 20 Nov 2023 16:03:51 -0600 From: Mike Karels To: Kristof Provost Cc: =?utf-8?q?Mina_Gali=C4=87?= , Zhenlei Huang , Kyle Evans , freebsd-net@freebsd.org Subject: Re: How to tell if a network interface was renamed (and from what) Date: Mon, 20 Nov 2023 16:03:50 -0600 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: References: <9eef5488-e8da-4edd-bc00-baeb5aaf4a23@FreeBSD.org> <032BADD4-0A49-42E2-BAAB-40D2F76C64B9@FreeBSD.org> <31B38FCE-0B67-4122-A202-568150E971E1@karels.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4SZ1k144RKz4HTs On 20 Nov 2023, at 14:56, Kristof Provost wrote: > On 20 Nov 2023, at 21:29, Mike Karels wrote: >> On 19 Nov 2023, at 15:35, Mina Gali=C4=87 wrote: >>> Hi Zhenlei, >>> >>> >>>> Since it is just for physical devices, may I propose to have the dri= ver name in their groups ? >>>> >>>> So an if_ure interface ue0 will look like: >>>> >>>> ``` >>>> ue0: flags=3D1008843 metric 0 mtu 1500 >>>> >>>> options=3D60009b >>>> >>>> ether 00:e0:4c:xx:xx:xx >>>> media: Ethernet autoselect (1000baseT ) >>>> >>>> status: active >>>> +++ groups: ure >>>> nd6 options=3D23 >>>> >>>> ``` >>>> >>>> That does not include the unit number. But could be useful to quickl= y get the driver name of physical devices. >>>> >>> >>> Given that currently on FreeBSD the easiest way to tell if something >>> is a physical device is by checking the *absence* of groups, this >>> would only really be acceptable if we add an "egress" group like >>> OpenBSD does, in addition to the driver name. >>> >>> If we can't do that, then I think Mike's solution with having the >>> driver (and unit) as a separate category would be preferable. >> >> I have a proof of concept that makes the presumed original name >> (driver name + unit number) available to ifconfig, which prints >> the string with everything else in the standard output format. >> I don't think that is the right solution, > > I believe a similar solution has been proposed before, and it failed to= cope with things like epair interfaces. Hmm, epair certainly breaks the rules (well, conventions). My current code sees "epair0" for both halves, which may not be what is desired. epair does some of this by hand, so could have more custom code. > I=E2=80=99d look in the direction of just adding a field to struct ifne= t with the original interface name (likely easily done in if_attach()), a= long with a new ioctl to retrieve that field. That may be as good as we can do, although I'm working with netlink rather than ioctls. But see the next message... Mike > Best regards, > Kristof