kern/79183: tap driver emits spurious ipv6 packet before if is up

[Marc Lehmann]

>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 at 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: