From nobody@FreeBSD.org  Sat Apr  8 22:15:12 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 276FD37B553
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  8 Apr 2000 22:15:11 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id WAA19417;
	Sat, 8 Apr 2000 22:15:12 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Message-Id: <200004090515.WAA19417@freefall.freebsd.org>
Date: Sat, 8 Apr 2000 22:15:12 -0700 (PDT)
From: greg@greg.rim.or.jp
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: Can not routing IPV6 packet with tun-device
X-Send-Pr-Version: www-1.0

>Number:         17873
>Category:       kern
>Synopsis:       Can not routing IPV6 packet with tun-device
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr  8 22:20:01 PDT 2000
>Closed-Date:    Mon Jul 17 16:23:22 PDT 2000
>Last-Modified:  Mon Jul 17 16:24:04 PDT 2000
>Originator:     Kensaku Masuda
>Release:        FreeBSD 4.0-STABLE i386
>Organization:
>Environment:
Enable INET6 And setting up INET6 routing.
>Description:
        V6 enviroment was completed. And after setting up tun device
for V6. creating a static routeing information by

        od -h /dev/tun0 &
        route add -inet6 default -interface tun0

And execute

        ping6 -I tun0 fe80::1

At normal case. V6 packet was routed into interface tun0. But packet was
rejected before tun device.
        So problem dose exist on initializing routine. if tun device
is staticaly network interface, Seem to be no problem. But it is not.
Must execute a initializing routine "in6_ifattach" directly.


>How-To-Repeat:
        Open and configure some tun for v6. And send some v6 packet
which is routed into tun device.

>Fix:
This is a diffs for net/if_tun.c

begin 644 if_tun.c.diff
M'XL(`-:S[3@"`VU274_C,!!\;G[%"EXH^702A6M[5$5W5*I42@5!]VB%Q*:6
M2A)BI[J>X+^SCM42X*3(BF=F=W8G<5T7!*>J+;W<JQKQ-/C#"IBS1R`)D&@<
MQ.,H@3`(`LNV[:-TD&Y:N*H;`%2-QO&/,2%&-9N!2RZ<!&P\+V`VLP#.?0LL
M.!5EOFT+!B=5K:@HF?(V)Y;]'4XTWB_X*??2K[,F>_8VTV]X4^4:UL9QA)9V
M'#LDZ)Q/!2\8A\7J.NV7H8?V\45I^K&R$-QR]2Q'?=*;[%"08$5"!<^4RO*-
MKOVL\74\^YI)0YFVGWW]QYIWIE]QD^PN:PZ[$#)R1IAB&#GX*?0V`\%K=XI"
M4>5J"Y>`!8)WETF/K5I5M\K0YKW/\FWV))%<S.=T?;M8I;?=":\=<O.P3!>_
MKN[3R=<PC@WT@M`U2.G=?1B%DX]5CR)9%I[@+_0Y^[ME):KQ8M[[L\B*JQQ)
MF1N4FF#/D!_^9X!>]EKB()-0/<8Z7#L0X#/\F,7&CIAU7_Y[F=+5PW+I@!3_
@6,7/6OS=U'"HS0NV<Z=2T*+9D<-$;]8[SBY;51X#``!U
`
end


>Release-Note:
>Audit-Trail:

From: Brian Somers <brian@Awfulhak.org>
To: greg@greg.rim.or.jp
Cc: freebsd-gnats-submit@FreeBSD.ORG, brian@hak.lan.Awfulhak.org
Subject: Re: kern/17873: Can not routing IPV6 packet with tun-device 
Date: Sun, 09 Apr 2000 11:30:38 +0100

 > 
 > >Number:         17873
 > >Category:       kern
 > >Synopsis:       Can not routing IPV6 packet with tun-device
 [.....]
 > This is a diffs for net/if_tun.c
 
 This breaks the if_tun module.  If the module is built with INET6 
 defined, it'll fail to load on a non-INET6 kernel.  If it's not, 
 it can't call in6_ifattach.
 
 if_tun.c is already broken by calling if_attach() here.
 
 We need to abstract the interface creation in a way similar to the 
 way data's dispatched via sys/net/intrq.c.  Maybe there should be a 
 all_ifattach() that's unconditionally built into the kernel and does 
 something like
 
 #ifdef INET
 	if_attach(ifp);
 #endif
 #ifdef INET6
 	in6_ifattach(ifp, IN6_IFT_P2P, 0, 0);
 #endif
 
 and so on ?  There'd need to be a more generic way of telling it to 
 use IN6_IFT_P2P, and I'm not sure why the if_type = IFT_RS232 bit is 
 necessary....
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
 
 
 
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Sun Apr 9 03:46:09 PDT 2000 
Responsible-Changed-Why:  
I've got an interest in keeping if_tun.ko as functional as the built in version. 

From: Brian Somers <brian@Awfulhak.org>
To: greg@greg.rim.or.jp (Kensaku Masuda)
Cc: brian@Awfulhak.org, freebsd-gnats-submit@FreeBSD.ORG,
	brian@hak.lan.Awfulhak.org, brian@hak.lan.Awfulhak.org
Subject: Re: kern/17873: Can not routing IPV6 packet with tun-device 
Date: Thu, 13 Apr 2000 14:33:20 +0100

 > <200004091030.LAA02368@hak.lan.Awfulhak.org>$B$N5-;v$K$*$$$F(B
 > brian@Awfulhak.org$B$5$s$O=q$-$^$7$?!#(B
 > 
 > >This breaks the if_tun module.
 > 
 > Oh, Sorry, this is kernel built-in case.
 
 if_tun is built as a module too.  Any changes to it should work for 
 /sys/modules.
 
 > >                                If the module is built with INET6 
 > >defined, it'll fail to load on a non-INET6 kernel.  If it's not, 
 > 
 > In this case. tun device was staticaly linked in the kernel.
 > 
 > >if_tun.c is already broken by calling if_attach() here.
 > 
 > Where do I call in6_ifattach() collectly ? In if_attach() ?
 > I think it seems to be not wrong.
 > 
 > >all_ifattach() that's unconditionally built into the kernel and does 
 > >something like
 > 
 > Look like little dirty, if all_ifattach called at opening tun device.
 > But these code has no problem basicly for me.
 
 The idea here is to move the ``#ifdef INET6'' decisions out of 
 if_tun.c as this decision cannot be made at module build time.  if 
 there was a global all_ifattach() function that if_tun calls at softc 
 creation time, it would make the problem go away.
 
 > >#ifdef INET
 > >	if_attach(ifp);
 > >#endif
 > >#ifdef INET6
 > >	in6_ifattach(ifp, IN6_IFT_P2P, 0, 0);
 > >#endif
 > 
 > So, if quated lines will be changed like this.
 > 
 > 	in6_ifattach(ifp, ifp->if_type, 0, 0);
 > 
 > and insert into some where.
 
 Ok, but that still needs to be done somewhere in *every* compiled 
 kernel so that the module doesn't get built with #ifdefs that will 
 fail in some environments.
 
 > ---
 > Fingerprint16 = 4F CC 44 F8 54 BE 45 3A  4F 9F 1C 4E 5E 3B 91 E9
 > Fingerprint20 = 12CA 6B2D DC50 8248 A636  992B 0292 F548 D65F 4D5B
 > -----------------+-----------------------------------$BA}ED!!7r:n(B---+
 > $B;0!&O;$r<i$m$&!*(B | greg@greg.rim.or.jp                            |
 > $B!!$*2H$X5"$m$&!*(B |   greg@fxis.fujixerox.co.jp                    |
 >                  |     http://www.st.rim.or.jp/~greg/             |
 > -----------------+------------------------------------------------+
 
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Thu Jul 13 06:33:12 PDT 2000 
State-Changed-Why:  
Could the submitter confirm if just setting ifp->if_type in if_tun.c 
solves the problem (as discussed in April) ? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=17873 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Mon Jul 17 16:23:22 PDT 2000 
State-Changed-Why:  
if_type set in if_tun.c as per discussions. 
I'll MFC on Wednesday 

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