Re: IPV6/KAME/protosw integration cleanup
Jun-ichiro itojun Hagino wrote: > > >Please note that the ip6protosw is ALSO very broken > > unfortunately, you are wrong. yes, protosw is supposed to be > protocol-independent. however, due to the nature of IPv6 extension > headers (you can have infinite number of them) you can blow the kernel > stack very easily. therefore, we had to do ip6protosw.h. > please read my Usenix paper (on m_pulldown and mbuf issues in BSD > IPv6 support) two years ago. I didn't say it could be easily fixed, and note that I am not touching it now.. > > itojun -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
Jun-ichiro itojun Hagino wrote:
>
> >Well what is there now is plainly unacceptable
> >I think that it was asked for as a VERY SHORT TERM hack.
> >But it has been there a long time...
> >I see no reasons so far to not make most of these changes..
>
> well, you are ignoging our design decisions. they are all done
> for reasons.
no, I just disagree about some of them.
>
> >1/ removal of "control" argument from rip6_input and prepend control mbuf
> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto
> >type for input. (I have not confirmed that the information in control
> >is a valid mbuf but it is an mbuf pointer).
>
> i don't see any "control" argument in rip6_input in kame tree, as well
> as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision
> are you looking at?
Sorry, wrong function.. it was output
here is the fix
@@ -295,16 +295,12 @@
* Tack on options user may have setup with control call.
*/
int
-#if __STDC__
-rip6_output(struct mbuf *m, ...)
-#else
-rip6_output(m, va_alist)
+rip6_output(m, so, sockaddr)
struct mbuf *m;
- va_dcl
-#endif
-{
struct socket *so;
- struct sockaddr_in6 *dstsock;
+ struct sockaddr *sockaddr;
+{
+ struct sockaddr_in6 *dstsock = (struct sockaddr_in6 *)sockaddr;
struct mbuf *control;
struct in6_addr *dst;
struct ip6_hdr *ip6;
@@ -315,14 +311,12 @@
struct ifnet *oifp = NULL;
int type = 0, code = 0; /* for ICMPv6 output statistics only */
int priv = 0;
- va_list ap;
-
- va_start(ap, m);
- so = va_arg(ap, struct socket *);
- dstsock = va_arg(ap, struct sockaddr_in6 *);
- control = va_arg(ap, struct mbuf *);
- va_end(ap);
+ if (m->m_type == MT_CONTROL) {
+ control = m;
+ m = m->m_next;
+ } else
+ control = NULL;
in6p = sotoin6pcb(so);
priv = 0;
@@ -718,7 +712,11 @@
> >2/ remove all var-args.. This is a disgusting hach that makes it impossible
> >for the compiler to catch mismatched functions and arguments.
> >NetBSD should know better than this.. they changed it.. they can bear the costs
> >of compatibility.. we are NOT going to do that.
> >3/ define all prototypes in terms of predefined types to allow
> >the compiler to catch wrong assignments quicker (or to change them quicker).
> >(this was planned a long time ago but not done for reasons I forget)
>
> i can partially buy this, but for *BSD code sharing, i do need a
> compromise here. permit us to use varargs.
>
no.
it can be in the netbsd compatibility code.
it's going away.
> >4/ Addition of the "proto" field to output to allow ipprotosw to be completely
> >removed. (the special type for that filed need not be done as I only did that
> >to ensure that KAME was not using it somewhere to pass something OTHER than
> >an proto type.) (other protocols can ignore this field).
>
> no you can't remove "proto" argument from the argument list.
> because of the way ipv6 extension header chain (and IPv4 AH/ESP
> header) is designed, proto argument has to be passed around, otherwise
> we can't know which protocol we are processing (think of raw ip header
> processing, like rip_input).
I din't say remove..
I said ADD.
>
> itojun
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
It strikes me that, although some code cleanup may be called for, a week is too agressive a deadline for many of them to be pushed through, especially in light of the code maintenance issue on the KAME side. I suggest that we look at a more gradual approach, as there's no rush right now for 5.0-RELEASE, and attempt to address technical issues one at a time (rather than a mega-patch). This would allow changes to be integrated as necessary into the KAME tree one-by-one, allow synchronization with code on other platforms, and allow the resolution of any technical problems to be done in a manner that all consumers of the KAME code can accept. Increasing the differences between the FreeBSD and KAME trees will only serve to exacerbatese these difficilties, especially in light of other changes coming in on the FreeBSD side (such as fine-grained locking). We benefit a great deal from the work performed by the KAME team, and I think I speak for everyone on the FreeBSD side when I say that we certainly wish to continue to be able to take advantage of the KAME IP stack work :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 12 Aug 2001, Julian Elischer wrote: > Julian Elischer wrote: > > Here is the patch I will consider committing in a week (unless I see these > issues > being handled elsewhere) > > -- > ++ __ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > | ( OZ)\___ ___ | country ! > +- X_.---._/presently in San Francisco \_/ \\ > v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
>> >1/ removal of "control" argument from rip6_input and prepend control mbuf >> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto >> >type for input. (I have not confirmed that the information in control >> >is a valid mbuf but it is an mbuf pointer). >> i don't see any "control" argument in rip6_input in kame tree, as well >> as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision >> are you looking at? >Sorry, wrong function.. it was output ok, >here is the fix xx_output() has never been governed by protocol switch structure and therefore ther are numerous variations we see in the tree. i don't see your problem at all. >> i can partially buy this, but for *BSD code sharing, i do need a >> compromise here. permit us to use varargs. >no. are you the one who decide the rule here? >it can be in the netbsd compatibility code. >it's going away. more #ifdef = more bug, and kame/freebsd gets left behind. i really hate all the cosmetic differences *BSD has. freebsd has more of it than anyone else. >> no you can't remove "proto" argument from the argument list. >> because of the way ipv6 extension header chain (and IPv4 AH/ESP >> header) is designed, proto argument has to be passed around, otherwise >> we can't know which protocol we are processing (think of raw ip header >> processing, like rip_input). >I din't say remove.. >I said ADD. so are you proposing to compromise protocol-independent protosw for the sake of IP? I guess your opinion is too IP centric... itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: prefixes advertised by routers.
> On Thu, 09 Aug 2001 01:04:54 -0400, > [EMAIL PROTECTED] said: > Assume that two prefix are advertised by router to hosts in the network. After some >time the administrator deletes one of the prefixes and the future router >advertisement will carry only one prefix. > What will hosts do with the deleted prefix? > Whether the addresses will be deleted after some time? What is this time? After the lifetime of the removed prefix expires. >> From the specs i found that the addresses are deleted only if the router advertises >prefix with valid life time of zero. Whether the rtadvd daemon has to send any such >message with deleted prefix life time set to zero? Yes. However, we should also note that the autoconfigured address is not (immediately) invalidated by an RA with the valid lifetime being 0, unless the RA is authenticated by IPsec. We'll see two-hour lag before the actual expiration. For more details, please read carefully RFC 2462. > I feel that the addresses should be deleted immediately if a router stops >advertising the prefix. No, they shouldn't. First of all, there is no effective mechanism that a host knows a router stops advertising RA. The only thing it can is to decrement lifetimes when it does not hear succeeding RAs. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: getaddrinfo() returning AF_INET only?
> On Sat, 11 Aug 2001 01:32:42 +0900 (JST), > Hajimu UMEMOTO <[EMAIL PROTECTED]> said: roam> Is there a configuration file or environment variable or some other roam> way to make getaddrinfo(3) not return AF_INET6 addresses even if roam> those are available? I know that most utilities that use getaddrinfo(3) roam> have an IPv4-only command-line option, but is there a way to turn it roam> on globally? > There is no option to do so. But, I believe it shouldn't cause any > problem. I also want to know why the original requester wanted to disable IPv6. Is it just a personal preference, or is there any essential problems with listing (and preferring) IPv6 addresses? > However, current getaddrinfo() doesn't see sortlist at all. It breaks > backward compatibility against gethostbyname(). So, I'm writing a > code to add sortlist facility to getaddrinfo(). Though the patch I > sent to cvs-all touches only IPv4 address, I have the version which > touches IPv6 address as well here. Once the patch is applied, you can > write as following into /etc/resolv.conf: > sortlist 0.0.0.0/0.0.0.0 ::/0 > It means I want to see IPv4 address 1st. > There is a discussion at IPng about destination address selection. > This feature may be conflict with it in the future. So, I'm wandering > if committing it into FreeBSD is better? Any suggestion? Recent KAME snaps have (partial) support of the destination address selection algorithm. At this moment, however, it does not support the flexible policy table, which is a generalization of the sortlist mechanism. Since the policy table has really an extension of sortlist, we will not be able to just reuse sortlist as an implementation of the table, when we add full support of the policy table. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
> On Sun, 12 Aug 2001 18:40:02 +0900, > [EMAIL PROTECTED] said: >> When KAME was added the mesh was less that perfect but there was so much to >> be done that some shortcuts needed to be taken. >> >> now that time has passed some of these can be cleaned up. >> >> 1/ Merging ipprotosw.h and protosw.h >> 2/ removal of all varargs stuff from the kernel >> (this revealing the mismatched prototypes they were hiding) >> removal of lotso warnings from the KAME stuff. > the change does add pain to KAME integration side on upgrades. > note that KAME codebase uses the same code across multiple *BSDs. > please don't do this. I tend to agree with itojun. Although I understand FreeBSD guys want to make code from KAME cleaner in terms of FreeBSD's own point of view, it will make future merge from KAME to FreeBSD harder. This is a trade-off issue, but at this moment, I think we'll still need further merge from KAME to FreeBSD, so I'd prefer keeping the code "as is" for a while. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
Jun-ichiro itojun Hagino wrote: > > >> >1/ removal of "control" argument from rip6_input and prepend control mbuf > >> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto > >> >type for input. (I have not confirmed that the information in control > >> >is a valid mbuf but it is an mbuf pointer). > >> i don't see any "control" argument in rip6_input in kame tree, as well > >> as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision > >> are you looking at? > >Sorry, wrong function.. it was output > > ok, > > >here is the fix > > xx_output() has never been governed by protocol switch structure > and therefore ther are numerous variations we see in the tree. > i don't see your problem at all. then why is it in ip6protosw? julian@jules:grep rip6_output */*.c net/if_gif.c: in6_gif_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output,rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: icmp6_input, rip6_output,rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: encap6_input,rip6_output,0, rip6_ctloutput, netinet6/in6_proto.c: encap6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: pim6_input, rip6_output,0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output,0, rip6_ctloutput, rip_output is also in protosw and I've changed that to pass a sockaddr* instead of a long. if it's in a protosw then it MUST have the same prototype as defined in the protosw. (no "if"s or "but"s) Using varargs to try hide this bug is not an acceptable answer. define ip6protosw's output to have the right definition. then it can be enforced by the compiler. > > >> i can partially buy this, but for *BSD code sharing, i do need a > >> compromise here. permit us to use varargs. > >no. > are you the one who decide the rule here? I think I can round up quite a lot of support here on NOT using varargs for things they were never designed for. The only thing varargs achieve here is the masking and hiding of bugs. I doubt that it is a design goal of KAME to hide bugs. I have seen no good argument for their use. printf's use of varargs in the kernel is shakey enough, but there is support for it in the compiler. > > >it can be in the netbsd compatibility code. > >it's going away. > > more #ifdef = more bug, and kame/freebsd gets left behind. > i really hate all the cosmetic differences *BSD has. freebsd has more > of it than anyone else. NetBSD is the one using varargs in the protosw are they not? > > >I din't say remove.. > >I said ADD. > > so are you proposing to compromise protocol-independent protosw > for the sake of IP? I guess your opinion is too IP centric... I propose to ammend our protosw to add the third argument you require. thus making the two structures the same, and then deleting the ipprotosw. It is needed for any protocol that wants to tunnel over another protocol. it could be generically useful. Certainly IP has always contrilled what is in the networking, but this need not be useful purely for IP. It must solve a class of problems that could also occur with other protocols. Certainly it's preferable to having a different structure for IP vs generic. IPV6 has it's own problems but we'll look at that later as it's still to early. > > itojun > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
note: I cannot respond to this address directly. JINMEI Tatuya / 神明達哉 wrote: > > > On Sun, 12 Aug 2001 18:40:02 +0900, > > [EMAIL PROTECTED] said: > > >> When KAME was added the mesh was less that perfect but there was so much to > >> be done that some shortcuts needed to be taken. > >> > >> now that time has passed some of these can be cleaned up. > >> > >> 1/ Merging ipprotosw.h and protosw.h > >> 2/ removal of all varargs stuff from the kernel > >> (this revealing the mismatched prototypes they were hiding) > >> removal of lotso warnings from the KAME stuff. > > > the change does add pain to KAME integration side on upgrades. > > note that KAME codebase uses the same code across multiple *BSDs. > > please don't do this. If other BSDs WANT varargs for this they are crazier than I thought. > > I tend to agree with itojun. Although I understand FreeBSD guys want > to make code from KAME cleaner in terms of FreeBSD's own point of > view, it will make future merge from KAME to FreeBSD harder. This is > a trade-off issue, but at this moment, I think we'll still need > further merge from KAME to FreeBSD, so I'd prefer keeping the code "as > is" for a while. > Although I understand KAME guys want to make code from KAME cleaner in terms of KAME's own point of view, it will make future merge from Almost anywhere else to FreeBSD harder. varargs is not an acceptable solution. please find some other method. (make a macro start that is defined differently for each platform for example). -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPV6/KAME/protosw integration cleanup
Robert Watson wrote: > > It strikes me that, although some code cleanup may be called for, a week > is too agressive a deadline for many of them to be pushed through, > especially in light of the code maintenance issue on the KAME side. I sugggest no changes in 4.x They have had over a year for cleaning it up.. how much time do they need considering I've given them patches for most of it.. > I > suggest that we look at a more gradual approach, as there's no rush right > now for 5.0-RELEASE, and attempt to address technical issues one at a time > (rather than a mega-patch). This would allow changes to be integrated as > necessary into the KAME tree one-by-one, allow synchronization with code > on other platforms, and allow the resolution of any technical problems to > be done in a manner that all consumers of the KAME code can accept. I've asked them to start working on it.. If they don't even start then I'll act but if they start cleaning up the code (90% of the WARNING messages we see in a kernel compile come from potential bugs introduced with KAME) I'm happy to let them do it at their own pace.. as long as there IS a pace. > > Increasing the differences between the FreeBSD and KAME trees will only > serve to exacerbatese these difficilties, especially in light of other > changes coming in on the FreeBSD side (such as fine-grained locking). We > benefit a great deal from the work performed by the KAME team, and I think > I speak for everyone on the FreeBSD side when I say that we certainly wish > to continue to be able to take advantage of the KAME IP stack work :-). Sure, but we need to make sure that it sticks to quality goals. How for example can you audit for correct function passing if they start using random varargs in protocol modules? what if someone wants to use a differnt combination of modules to those envisionned by the writers? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > [EMAIL PROTECTED] NAI Labs, Safeport Network Services > > On Sun, 12 Aug 2001, Julian Elischer wrote: > > > Julian Elischer wrote: > > > > Here is the patch I will consider committing in a week (unless I see these > > issues > > being handled elsewhere) > > > > -- > > ++ __ _ __ > > | __--_|\ Julian Elischer | \ U \/ / hard at work in > > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > > | ( OZ)\___ ___ | country ! > > +- X_.---._/presently in San Francisco \_/ \\ > > v -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
