> No, but the problem is that there was no increase (actually, no
> record at all) under ipsec: IPComp. The number on the sending
> side seemed right. The increase matched the ones I saw from
> tcpdump. It looked like the IPComp packets either weren't
> logged or wer
> What you pointed out below is true. But I am more
> interested in the relative performance since the number
> I measured were under exactly the same setup and traffic
> condition. I am just curious why IPComp was _relatively_
> (and signigicantly) slower than most
>> for background (like when this happens) see previous articles
>> on this thread.
>> current behavior: return 0-length sockaddr.
>Yeah, that is totally broken.
>Hmm.. how long has this been the "current behavior" ?
>ISTR at one time you would instead get the actual sockaddr of th
>I'm wondering how one is supposed to test for INET6 support in the
>kernel. Currently a few places do it in a somewhat bogus fashion
>like this:
what are you planning to do after checking IPv6 support in the kernel?
applications should be written so that it would work on both
> Please refer if_attach() of .
> Iam unable to understand why you are constructing a string from interface name &
>interface unit number ( ifnet structure members ifp->if_unit & ifp->if_name) &
>storing in the data member of sockaddr_dl structure. Iam also confused why you are
>storing the har
hello, regarding to the note on:
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/local/www/db/text/2001/freebsd-net/20010506.freebsd-net
the symptom is repeatable. however, it seems to me that the multi
destination mode is poorly documented, and needs ce
>The cloning API isn't quite that of NetBSD because the NetBSD API only
>supported the creation of staticaly numbered interfaces which can lead
>to races and starvation in theory. This patch instead allows interfaces
>to implement wildcard interface creation via "ifconfig gif# create".
n
>It is printed to stdout. Since status is not printed on creation, it is
>the only thing on stdout so it is easy to hand in a script:
i see. thanks.
>newgif=3D`ifconfig gif# create`
>ifconfig $newgif 10.0.0.1 10.0.0.2
you may need to have backslash before #... :-)
itojun
To
>I can only find a way to define a global SPD using setkey. Is it possible
>to define an (IPv4) SPD on a per interface basis using KAME / FreeBSD4?
>If not, are there any plans to add this in the future?
>Is there any reason one wouldn't want to have this?
no. do you want SPD per interf
>> >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
>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
>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.
>I have still not heard any reason for the varargs here..
>except "it's needed for portability"..
>portability with WHO?
portability with other *BSD projects (NetBSD, OpenBSD, BSD/OS, MacOSX
maybe).
>BSD4.4 certainly didn't have varargs there
4.4BSD did not have pro
>We are planning to fill your (and many freebsd hackers') requirements.
just a nitpicking.
- i don't think julian is in the position to set the requirement
for freebsd. is he?
- i have never heard from other people about (against) the use of
varargs,
>By the way, RFC2893 has the following text:
(snip)
>Thus, people would say that KAME (FreeBSD) is not compliant to RFC
>2893.
i guess you did not check the original question.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>> 1. Has anyone else seriously looked at doing this?
>> 2. Has anyone compared the OpenBSD and KAME implementations and understand
>> their relative strengths? (e.g. is there some reason to work with KAME other
>> than it's already in the system)
>
>i have summarized what some people argued to me
if you want MPLS on BSD, check out http://www.ayame.org/.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> Yes, and I know why the restriction is in RFC 1884 and it
> is a reasonable restriction.
I don't think so, IP source address is easy to forge and it does not
add any meaning protection. DNSSEC is the only way if you want trusted
responsees. therefore, i agr
>>> Yes, and I know why the restriction is in RFC 1884 and it
>>> is a reasonable restriction.
>> I don't think so, IP source address is easy to forge and it does not
>> add any meaning protection. DNSSEC is the only way if you want trusted
>> responsees. therefore, i agree with e
> >> > + nd6_nud_hint() is only called as nd6_nud_hint(NULL, NULL, 0);
> >> > in some cases from netinet/tcp_input.c
> >> > With these args, the routine is a NOP. I propose to remove it
> >> > (and the associated field, ln_byhint, in struct llinfo_nd6)
on other OSes we call nd6_nud_h
20 matches
Mail list logo
