NetBSD Problem Report #37439

From mmondor@pulsar-zone.net  Mon Nov 26 22:16:05 2007
Return-Path: <mmondor@pulsar-zone.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id A04B663B888
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 26 Nov 2007 22:16:05 +0000 (UTC)
Message-Id: <200711262215.lAQMFurU012729@ginseng.xisop>
Date: Mon, 26 Nov 2007 17:15:56 -0500 (EST)
From: mmondor@pulsar-zone.net
Reply-To: mmondor@pulsar-zone.net
To: gnats-bugs@NetBSD.org
Subject: tap(4) assigning duplicate MAC addresses
X-Send-Pr-Version: 3.95

>Number:         37439
>Category:       kern
>Synopsis:       tap(4) assigning duplicate MAC addresses
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 26 22:20:00 +0000 2007
>Closed-Date:    Sun Jul 27 07:17:15 +0000 2014
>Last-Modified:  Sun Jul 27 07:17:15 +0000 2014
>Originator:     Matthew Mondor
>Release:        NetBSD 4.99.37
>Organization:
>Environment:
        System: NetBSD sat.xisop 4.99.37 NetBSD 4.99.37 (GENERIC_LAPTOP_MM) #4: Sat Nov 24 22:19:54 EST 2007  root@sat.xisop:/usr/src/sys/arch/i386/compile/GENERIC_LAPTOP_MM i386
Architecture: i386
Machine: i386
>Description:
	When creating multiple tap(4) interfaces in a short time frame,
	they are assigned the same MAC address.  This address is calculated
	from the current uptime trivially, not to simply use a hardcoded
	address.  However, it's not difficult to enhance the process.
	A diff is included showing an example.
>How-To-Repeat:
	Create two or more devices using /dev/tap.
>Fix:
	An example solution might look like (untested):


--- if_tap.c.orig	2007-09-10 06:35:54.000000000 -0400
+++ if_tap.c	2007-11-26 17:03:40.000000000 -0500
@@ -87,6 +87,14 @@ static int	tap_sysctl_handler(SYSCTLFN_P
 SYSCTL_SETUP_PROTO(sysctl_tap_setup);

 /*
+ * Since we use a trivial uptime based randomization to
+ * generate tap virtual MAC addresses, this reduces the
+ * likelyhood of having two interfaces with the same address
+ * when multiple interfaces are created rapidly.
+ */
+static uint32_t ui_cnt = 0;
+
+/*
  * Since we're an Ethernet device, we need the 3 following
  * components: a leading struct device, a struct ethercom,
  * and also a struct ifmedia since we don't attach a PHY to
@@ -258,9 +266,11 @@ tap_attach(struct device *parent, struct
 	 * In order to obtain unique initial Ethernet address on a host,
 	 * do some randomisation using the current uptime.  It's not meant
 	 * for anything but avoiding hard-coding an address.
+	 * We also use a counter in order to prevent two identical addresses
+	 * when creating them in a short time frame.
 	 */
 	getmicrouptime(&tv);
-	ui = (tv.tv_sec ^ tv.tv_usec) & 0xffffff;
+	ui = (++ui_cnt + (tv.tv_sec ^ tv.tv_usec)) & 0xffffff;
 	memcpy(enaddr+3, (u_int8_t *)&ui, 3);

 	aprint_verbose("%s: Ethernet address %s\n", device_xname(&sc->sc_dev),

>Release-Note:

>Audit-Trail:
From: Quentin Garnier <cube@cubidou.net>
To: gnats-bugs@NetBSD.org
Cc: mmondor@pulsar-zone.net
Subject: Re: kern/37439: tap(4) assigning duplicate MAC addresses
Date: Tue, 27 Nov 2007 06:00:28 +0100

 --5oH/S/bF6lOfqCQb
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 On Mon, Nov 26, 2007 at 10:20:00PM +0000, mmondor@pulsar-zone.net wrote:
 > >Number:         37439
 > >Category:       kern
 > >Synopsis:       tap(4) assigning duplicate MAC addresses
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Nov 26 22:20:00 +0000 2007
 > >Originator:     Matthew Mondor
 > >Release:        NetBSD 4.99.37
 > >Organization:
 > >Environment:
 >         System: NetBSD sat.xisop 4.99.37 NetBSD 4.99.37 (GENERIC_LAPTOP_M=
 M) #4: Sat Nov 24 22:19:54 EST 2007  root@sat.xisop:/usr/src/sys/arch/i386/=
 compile/GENERIC_LAPTOP_MM i386
 > Architecture: i386
 > Machine: i386
 > >Description:
 > 	When creating multiple tap(4) interfaces in a short time frame,
 > 	they are assigned the same MAC address.  This address is calculated
 > 	from the current uptime trivially, not to simply use a hardcoded
 > 	address.  However, it's not difficult to enhance the process.
 > 	A diff is included showing an example.

 Looking back, what I did was stupid anyway.  I have the device unit
 number which is guaranteed to be unique between tap interfaces.  I'll
 cook something up later.

 --=20
 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
 "See the look on my face from staying too long in one place
 [...] every time the morning breaks I know I'm closer to falling"
 KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

 --5oH/S/bF6lOfqCQb
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (NetBSD)

 iQEVAwUBR0ukbNgoQloHrPnoAQLnEggAieyf1qx+mq2nFnrscoisAz/UWpJ5xftQ
 7lOK1KVEDHsfvR14muTDnX7hRml/SaSHQI40mvqxHSO0rQJbrJxEIFHZHbwGB6s9
 ms/TxeR0VksqDUBucMSOJ7yEt3j26cmTp1YtnBuaIQO+FsOCpf9nWSEXTtIRWmoo
 cl6FiWJAzt5zRE6+3ae8n5mLYvX6ugqaikeZKSyx813ITETHEVjsgyGB75nXaIio
 28nd9RIuo0pc16+mhWiAdgWuWJsGCagbVR5EVxLG8hucv245uKcv4x5Uuj3C3bzp
 KdtM6B6QXCIni4rEDk5Yi04EMSeNgQs6CLp+coI29KLOq2lFETWYIA==
 =GlIA
 -----END PGP SIGNATURE-----

 --5oH/S/bF6lOfqCQb--

State-Changed-From-To: open->closed
State-Changed-By: ozaki-r@NetBSD.org
State-Changed-When: Sun, 27 Jul 2014 07:17:15 +0000
State-Changed-Why:
Should be fixed by if_tap 1.70


>Unformatted:

Home	PR Database Search