From owner-freebsd-net@FreeBSD.ORG  Sat Feb  7 20:58:52 2015
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 0F3C919C
 for <net@freebsd.org>; Sat,  7 Feb 2015 20:58:52 +0000 (UTC)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
 by mx1.freebsd.org (Postfix) with ESMTP id F33F47D5
 for <net@freebsd.org>; Sat,  7 Feb 2015 20:58:51 +0000 (UTC)
Received: from [10.0.1.100] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192])
 by elvis.mu.org (Postfix) with ESMTPSA id 6235B341F8AD
 for <net@freebsd.org>; Sat,  7 Feb 2015 12:58:51 -0800 (PST)
From: Alfred Perlstein <alfred@freebsd.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Nasty bug in startup scripts with interface renaming.
Date: Sat, 7 Feb 2015 13:02:51 -0800
Message-Id: <CC945B9D-7BDA-46AD-8362-E82C1FD72873@freebsd.org>
To: net@freebsd.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Feb 2015 20:58:52 -0000

If you happen to use interface renaming there is a nasty bug lurking in =
the startup scripts, it seems newly introduced, but I am unsure.

Specifically the following happens at boot time:

/etc/rc.d/netif is run without args.

It gets the list of interfaces and for each interface it calls =
network_start().

however in network start we have this:

        # Create cloned interfaces
        clone_up $cmdifn

        # Rename interfaces.
        ifnet_rename $cmdifn

        # Configure the interface(s).
        network_common ifn_start $cmdifn

Now it doesn't take that much to realize that if 'ifnet_rename' renames =
'cmdifn' then the subsequent call to 'network_common ifn_start $cmdifn' =
will be passing a stale interface in as a parameter and causes a bunch =
of errors to happen.

Example:
cmdifn=3D"vtnet0"

Therefor:

        # Rename interfaces.
        ifnet_rename vtnet0     # <- gets renamed here to derp0

        # Configure the interface(s).
        network_common ifn_start vtnet0  # <- this seems to cause an =
error since we're using old name.


I looked at fixing ifnet_rename() to take a variable to assign to, so =
for instance the call could turn into something like:

ifnet_rename cmdifn  vtnet0 =20

This way cmdifn would be set to 'derp0' and subsequent stuff would work, =
however=85. then I realized that ifnet_rename can take 0 args, or =
MULTIPLE args and will act on either all interfaces or the ones passed =
in.  So passing another var becomes a problem.

I then realized that if I threw together a patch to fix it "the alfred =
way" people would probably be upset.

So I'm asking, any suggestions before I go about just fixing this?

-Alfred