From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 08:00:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11125106568D for ; Fri, 14 Aug 2009 08:00:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id B18028FC45 for ; Fri, 14 Aug 2009 08:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6E1F841C647; Fri, 14 Aug 2009 10:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id NXloOnDwlYaz; Fri, 14 Aug 2009 10:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E726841C667; Fri, 14 Aug 2009 10:00:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0AA204448EC; Fri, 14 Aug 2009 07:58:34 +0000 (UTC) Date: Fri, 14 Aug 2009 07:58:33 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: d@delphij.net In-Reply-To: <4A84FE96.1070506@yandex.ru> Message-ID: <20090814071511.U93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> <4A84FE96.1070506@yandex.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: RFC: interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 08:00:08 -0000 On Fri, 14 Aug 2009, Andrey V. Elsukov wrote: Hi, > Xin LI wrote: >> The only question I have would be, that is it possible to uniquely >> identify a NIC without assistance from kernel? For instance, one can >> change an interface from being called "em0" to "eth0" and from "bge0" to >> "em0". It's easy to track this information through ifconfig(8) with a >> callback, clean up the file upon restart, but we can not prevent other >> programs from calling IOCSIFNAME on the interface. Any idea for this? > > What about using interface index as a key(see if_nameindex(3))? So here comes the usual catch 22 on a classic PC system: you can change everything. Using RFC 2553 Section 4 is probably the best indeed but has drawbacks as well. If you match by xname, renaming the interface will break things. If you match by dname+unit, unit can still change between boots (see further on). If you match by MAC address the MAC address can be changed by the user. If you match by (PCI/..) slot, cards can be moved. If you match by card serial number, *oops* most of those don't have that in the consumer or even server world so that's not an option. Because of the above we don't have any metadata that would allow us to have persistent ifIndexes between boots. Once you add portable interfaces (pcmcia, usb, pc card, ..) to the game even your ifIndex upon boot may vary depending on if a card is plugged in or not or if you added another one, possibly using the same driver changing the unit number if unlucky (see above). Now add cloned interfaces from gif, tun, .. to wlan and you'll understand the big (problem|picture). Now let us look at this from a different view - what can venders do to avoid all this or how can they handle things: They might have ways to uniquely identify each interface so an ifIndex could possibly always be the same after the interface was first put into a device (interface serial number for example). They usually do not allow renaming of interface names. They usually do not have physical interfaces coming and going very often. They do have "cloned-a-like" interfaces as well so they have to handle them somehow. I have seldomly seen descriptions on those if they come and go. They possibly treat static "tunnel" interfaces, etc. more statically having a well defined bringup order. The cards lose their description if moved to a different slot or rather as the interface goes away usually and even if plugged into a different slot would lose the description but maybe not the ifIndex. What does that mean for us? For "dynamic" interfaces storing things with the kernel would for sure be easier as if you remove the interface the description is gone. If not storing in the kernel we get interface insertion and removal events already to userspace/devd imho we could use. The moment you add the description it doesn't matter what the interface is, as you can name it always some way. If you take the classic BSD scheme and will seed the "storage" upon boot from scratch from rc.conf or other places you will have a consitent ifIndex for all hard wired physical interfaces (non-hotpluggable). [Unless you move hardware that should even be the same if we don't change bus scanning orders, etc.] For all the cloned stuff things are harder, as we to my knowledge even recycle ifIndexes to not have huge gaps in the array (which is a real pain), so there are kernel limitations as well in the way we store/lookup things that also had come up during the vnet merges and that people are aware of. Bsnmp should have to handle parts of this all already and is for sure one of the first consumers so talking to harti and syrinx or looking at that code might also be a good thing todo. My biggest worry comes with the cloned interfaces like tuns or similar ones if they come and go often; if an ifIndex is recycled and even if the interface name is the same afterwards there should be no old description left, so "purging" entries on interface deletion and possibly asserting that on interface creation would be a good idea. JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe /bz -- Bjoern A. Zeeb What was I talking about and who are you again?