From nobody@FreeBSD.org  Thu Mar 24 03:56:32 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4CFE816A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; 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 <freebsd-gnats-submit@FreeBSD.org>; 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 <freebsd-gnats-submit@FreeBSD.org>; 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 <gvpe@schmorp.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: tap driver emits spurious ipv6 packet before if is up
X-Send-Pr-Version: www-2.3

>Number:         79183
>Category:       kern
>Synopsis:       tap driver emits spurious ipv6 packet before if is up
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    emax
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 24 04:00:13 GMT 2005
>Closed-Date:    Fri Mar 25 17:38:56 GMT 2005
>Last-Modified:  Fri Mar 25 17:38:56 GMT 2005
>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:
Responsible-Changed-From-To: freebsd-bugs->emax 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Thu Mar 24 09:32:19 GMT 2005 
Responsible-Changed-Why:  
if_tap was written by Maksim. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=79183 
State-Changed-From-To: open->analyzed 
State-Changed-By: emax 
State-Changed-When: Thu Mar 24 23:50:04 GMT 2005 
State-Changed-Why:  
I do not think this is a problem with if_tap. In fact, I do not think this is 
a problem at all. What happens here is that ifconfig(8) executes "up" command 
before it sets the link address. As soon as the "up" command is processed 
the ethernet frame appears on /dev/tap, but at this time link address is still 
not changed. The change of link address happens after all the commands were 
executed. 

As workaround I suggest to split single ifconfig(8) command into two, i.e. 

ifconfig tap0 ether fd:00:00:00:00:01 mtu 1500 
ifconfig tap0 up 


http://www.freebsd.org/cgi/query-pr.cgi?pr=79183 
State-Changed-From-To: analyzed->closed 
State-Changed-By: emax 
State-Changed-When: Fri Mar 25 17:34:32 GMT 2005 
State-Changed-Why:  
The bug is closed with resolution 'NO BUG'. Suggested workaround was discussed 
with the person who has submitted the bug. It was confirmed that the suggested 
workaround indeed works. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=79183 
>Unformatted:

I do not think this is a problem with if_tap. In fact, I do not think this is
a problem at all. What happens here is that ifconfig(8) executes "up" command
before it sets the link address. As soon as the "up" command is processed
the ethernet frame appears on /dev/tap, but at this time link address is still
not changed. The change of link address happens after all the commands were
executed.

As workaround I suggest to split single ifconfig(8) command into two, i.e.

ifconfig tap0 ether fd:00:00:00:00:01 mtu 1500
ifconfig tap0 up

