From owner-freebsd-arch@FreeBSD.ORG Wed Apr 7 11:02:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4986F16A4CE; Wed, 7 Apr 2004 11:02:50 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2856443D49; Wed, 7 Apr 2004 11:02:50 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i37I19T7013529; Wed, 7 Apr 2004 11:01:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i37I18t7013528; Wed, 7 Apr 2004 11:01:08 -0700 Date: Wed, 7 Apr 2004 11:01:08 -0700 From: Brooks Davis To: harti@freebsd.org Message-ID: <20040407180107.GB20636@Odin.AC.HMC.Edu> References: <20040407111613.W759@130-149-145-115.dialup.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <20040407111613.W759@130-149-145-115.dialup.cs.tu-berlin.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org Subject: Re: interface renaming of an running interface X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2004 18:02:50 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 07, 2004 at 11:38:45AM +0200, Harti Brandt wrote: >=20 > I'm currently trying to teach bsnmp to correctly handle interface > renaming. One problem that I encounter is that a process listening on > the routing socket sees an interface departure and an interface arrival > message. This cause interfaces that run stateful protocols like SNMP on > ATM interfaces to drop all connections which isn't really all that nice. > The SNMP daemon would also loose all interface state and would report > the renamed interface as a new interface with a new ifindex. This directly > violates the IF-MIB RFC, because the daemon is required to understand that > this is the same interface (the ifindex doesn't really help here, because > unloading/loading the driver gives the same behaviour). I would like to do > one of the following two things: >=20 > 1) disallow renaming an interface while it is up, or > 2) instead of emiting a departure/arrival pair of routing messages, > generate a rename message. For the record, I wouldn't object to 1, but I prefer 2. My view is that the name is an ephemeral property of an interface intended to the convenience of the administrator, nothing more. I random though just hit me as I thought about this message. For a variety of good reasons, if_index's are densly packed so if you destroy an interface and create a new one, you will almost certaintly get the index of a recently used one. This leads to the problem that you can't tell the rename and create-destory operations apart with the current set of routing messages. One solution to this problem might be to add a generation number to the interface either using a global counter or just a timestamp. > Additionally I would like to create new sysctls: >=20 > net.link.generic.ifdata..dname > net.link.generic.ifdata..dunit >=20 > to access the driver's name of an interface. Fine with me. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAdEHjXY6L6fI4GtQRAqYJAJ9gIX888u95efnmfIUJn4PkX9+RlgCfU745 7mJZYD2viqchU1F7gBPo8dg= =CIDo -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1--