>Number:         23125
>Category:       kern
>Synopsis:       Destroying a configured gif tunnel causes panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 10 18:37:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Frederick Bruckman
>Release:        NetBSD 1.6ZC
>Organization:
>Environment:
	
	
System: NetBSD rapture.immanent.net 1.6ZC NetBSD 1.6ZC (RAPTURE) #1: Tue Oct 7 08:27:38 CDT 2003 fredb@rapture.immanent.net:/usr/obj/usr/src/sys/arch/i386/compile/RAPTURE i386
Architecture: i386
Machine: i386
>Description:
	
	Destroying a configured gif tunnel consistently leads to a panic,
	as below. As of NetBSD-1.6Q, this used to neatly delete the tunnel,
	routes, and all the aliases.

	I've tried, one at a time, a patch posted to current users,

	http://mail-index.netbsd.org/current-users/2003/10/10/0000.html

	the patch in PR kern/22792, and reverting all the recent
	changes to if_clone_lookup() (src/sys/net/if.c, 1.128-130),
	but none of that made any difference.

>How-To-Repeat:
	

    # ifconfig gif0
    gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
	    tunnel inet 64.135.203.89 --> 64.71.128.82
	    inet6 2001:470:1f00:ffff::513 -> 2001:470:1f00:ffff::512 prefixlen 128
	    inet6 fe80::200:c0ff:fed3:51d5%gif0 ->  prefixlen 64 scopeid 0x7
    # ifconfig gif0 destroy
    uvm_fault(0xc6b79f00, 0, 0, 1) -> 0xe
    kernel: page fault trap, code=0
    Stopped in pid 2941.1 (ifconfig) at     netbsd:if_detach+0x1cb: movl    0x14(%ebx),%edi
    db> bt
    if_detach(c0665c00,0,900,c0345170,c6dd7ea4) at netbsd:if_detach+0x1cb
    gif_clone_destroy(c0665c00,0,b7d,c6ba1738,c6ba1738) at netbsd:gif_clone_destroy+0x63
    if_clone_destroy(c6dd7ea4,c6dfda06,c6dd7e2c,c015d5a7,334) at netbsd:if_clone_destroy+0x4a
    ifioctl(c05e6e58,80206979,c6dd7ea4,c6dfd86c,0) at netbsd:ifioctl+0xa1b
    sys_ioctl(c6b7cee0,c6dd7f64,c6dd7f5c,0,c6dd7fa4) at netbsd:sys_ioctl+0x126
    syscall_plain(c6dd7fa8,1f,1f,1f,1f) at netbsd:syscall_plain+0x74
    db>
    >Fix:
	    <how to correct or work around the problem, if known (multiple lines)>
	    Manual deleting the tunnel and the aliases first, allows
	    you to destroy the interface safely. For the above, that
	    would be:

	# ifconfig gif0 deletetunnel
	# ifconfig gif0 inet6 -alias 2001:470:1f00:ffff:513
	# ifconfig gif0 inet -alias fe80::200:c0ff:fed3:51d5
	# ifconfig gif0 destroy

	    Needless to say, this is messy and suboptimal.

>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
 	
 	
 	Sources as of Thurs, Oct 09, 2003