From owner-freebsd-bugs@FreeBSD.ORG Thu Mar 24 04:00:14 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC9016A4CE for ; Thu, 24 Mar 2005 04:00:14 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C3043D5D for ; Thu, 24 Mar 2005 04:00:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j2O40D7K067710 for ; Thu, 24 Mar 2005 04:00:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j2O40Das067664; Thu, 24 Mar 2005 04:00:13 GMT (envelope-from gnats) Resent-Date: Thu, 24 Mar 2005 04:00:13 GMT Resent-Message-Id: <200503240400.j2O40Das067664@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Marc Lehmann Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CFE816A4CE for ; Thu, 24 Mar 2005 03:56:32 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A6943D48 for ; Thu, 24 Mar 2005 03:56:32 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j2O3uV9G095197 for ; Thu, 24 Mar 2005 03:56:31 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j2O3uVdP095196; Thu, 24 Mar 2005 03:56:31 GMT (envelope-from nobody) Message-Id: <200503240356.j2O3uVdP095196@www.freebsd.org> Date: Thu, 24 Mar 2005 03:56:31 GMT From: Marc Lehmann To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: kern/79183: tap driver emits spurious ipv6 packet before if is up X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2005 04:00:14 -0000 >Number: 79183 >Category: kern >Synopsis: tap driver emits spurious ipv6 packet before if is up >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 24 04:00:13 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Marc Lehmann >Release: 5.2.1-RELEASE >Organization: >Environment: FreeBSD goof.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386 >Description: The gnu virtual private ethernet daemon, when started directly after kldload if_tap.ko outputs (and exits): FATAL: tap packet not originating on current node received (if-up script not working properly?), exiting. on subsequent starts it works fine UNTIL the moduleis unloaded and loaded again. When gvpe does, roughly, is: 1) open tap device 2) run ifconfig on it, _changing_ the mac address, i.e. ifconfig tap0 euther FE:FD:80:00:00:01 mtu 1500 up 3) starts read'ing from the tap handle ktrace reveals that gvpe receives this frame: 0x0000 3333 ff7b b700 00bd fc7b b700 86dd 6000 |33.{.....{....`.| 0x0010 0000 0020 0001 fe80 0000 0000 0000 02bd |... ............| 0x0020 fcff fe7b b700 ff02 0000 0000 0000 0000 |...{............| 0x0030 0001 ff7b b700 3a00 0100 0502 0000 8300 |...{..:.........| 0x0040 5df1 0000 0000 ff02 0000 0000 0000 0000 |]...............| 0x0050 0001 ff7b b700 |...{..| which is a ipv6 frame (type 86dd) to "3333 ff7b b700" from "00bd fc7b b700" (wire order), which is _not_ the configured mac address. As mentioned, this happens only after the first time the module is loaded, on subsequent program runs no such bogus frame is being received. It looks (pure speculation) that the ipv6 subsystem generates a frame and sends it down the tap device before it is set "UP". That assumes that ifconfig indeed first sets the mac address and only then sets the if "up". If that is the case, I would consider this a kernel bug, as the tap driver should not send ethernet frames to a device that is "down". >How-To-Repeat: kldload if_tap.ko cat /dev/tap0 >file & ifconfig tap0 ether fd:00:00:00:00:01 mtu 1500 up now file contains some ethernet frames that have a src mac != fd:00:00:00:00:01, which (imho :) shouldn't happen. >Fix: >Release-Note: >Audit-Trail: >Unformatted: