From owner-freebsd-net@FreeBSD.ORG Mon Dec 21 21:44:59 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6988E1065670; Mon, 21 Dec 2009 21:44:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 260948FC12; Mon, 21 Dec 2009 21:44:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B20D846B35; Mon, 21 Dec 2009 16:44:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E5D8D8A020; Mon, 21 Dec 2009 16:44:57 -0500 (EST) From: John Baldwin To: net@freebsd.org Date: Mon, 21 Dec 2009 16:44:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200911131244.58819.jhb@freebsd.org> In-Reply-To: <200911131244.58819.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912211644.31826.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Dec 2009 16:44:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Brooks Davis Subject: Re: ifnet renaming interacts badly with vlans 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: Mon, 21 Dec 2009 21:44:59 -0000 On Friday 13 November 2009 12:44:58 pm John Baldwin wrote: > So first the problem I am trying to solve. I would like to give meaningful > aliases to interfaces and vlans on interfaces. For example, suppose I would > I have em0 with a vlan of 112, but I would like to call em0, "foo" and > em0.112, "foo.bar". One can do this if you do things in this order: > > ifconfig em0 name foo > ifconfig foo.112 create > ifconfig foo.112 name foo.bar > > However, our rc.d scripts want to create all cloned interfaces before applying > renames, so to attempt to do this in /etc/rc.conf you would use something > like: > > cloned_interfaces="em0.112" > ifconfig_em0_name="foo" > ifconfig_em0_112_name="foo.bar" > > However, this ends up doing a sequence more like: > > ifconfig em0.112 create > ifconfig em0 name foo > ifconfig em0.112 name foo.bar > > Unfortuantely, this sequence breaks em0.112 at the second step. The reason is > that when em0 is renamed, the kernel actaully fires off event handlers > claiming that the em0 ifnet has been detached and that a new foo ifnet has > been attached. When this happens, the em0.112 vlan ifnet is orphaned. > > I think this is a bug in how renames are handled. Specifically, I don't think > renaming an interface should always have the same semantics as if I had > physically removed an interface and then later added it back. One > alternative would be to instead broadcast a single "rename" event when an > interface is renamed and things that cared about interface names (such as > firewall rules) could still honor those events, but other subsystems might > choose to ignore said events (e.g. vlan devices). Another alternative might > be to use two different events ('ifnet_removed_name' and 'ifnet_added_name'). > Subsystems that care about the name changing could reuse their existing > detached/attached handlers for those two events without needing to change the > event handlers themselves. A separate issue if the eventhandlers were > changed is if we should use a different routing socket message when an > interface is renamed or if it we should still claim that an interface has > gone away and then come back. Given that we don't flush addresses from an > interface when the name changes or even the ifindex it seems a bit > disingenous to claim that the interface has detached and then reattached. So I took a more conservative approach so that the change was easier to MFC. My current patch adds a new flag to the ifnet if_flags IFF_RENAMING that is set during a rename operation. ifnet attach/detach handlers can then use this flag to handle renames differently from other events. This means that no other bits of code have to change to handle renames. I then changed the vlan(4) driver to do what I felt was most intuitive in that it renames the child vlan interfaces if their existing name was tied to the parent interface. However, it turns out that this does not work well with our rc.d scripts. Specifically, ifnet_rename() in /etc/network.subr fetches the list of devices before any renames happen, so with the auto-renaming feature the vlan gets renamed before the vlan interface can have its name changed. If I remove the auto-renaming feature then the example I gave above to rename em0.112 to foo.bar would work fine. This is also a smaller and simpler diff to go with this approach. What do other folks thing? (Current patch is http://www.FreeBSD.org/~jhb/patches/vlan_rename.patch ) -- John Baldwin