> generated against 6.0-CURRENT and I included Sam's commit
> message.
>
>Later,
>George
the fix is already in kame repository. tnx.
itojun
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/lis
much appreciated.
>| The URL for the conference: http://ipv6.india.hp.com/summit/index.htm
>itojun has quite a few on his website.
check the following URLs.
http://www.kame.net/
http://www.tahi.org/
conformance test results
http://www.kame.
>Note though that itojun warned me that this code might conflict
>with future use of the link2 flag from the KAME project.
FYI: latest kame code already uses LINK2, to control ingress filter
behavior in gif/stf.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED
t negotiated (from the protocol spec), so
- if Win2K uses no pfs group, racoon obeys
- if racoon proposes either pfs group 1/2, Win2K rejects
hope this helps.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ress).
>There must be something wrong in the routing table which is
>not deleted when the interface address changes. Problem is,
>it is not shown by netstat -nra -- so where should i look ?
rt_ifa in struct rtentry?
itojun
PS: i like the hostname larry have used :-)
To Un
e able to respond. anyway, i'll forward this note
to [EMAIL PROTECTED] (subscription: see www.kame.net/snap-users)
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
destionation address, or (2) refresh rt_ifa
every time interface address changes. not sure which one is better -
(2) has problem with manually configured rt_ifa (some people controls
source address selection by route -ifa).
itojun
To Unsubscribe: send mail to [EMAIL PR
removing the old address... which
>maybe is not occurring for some reason ?
rtinit() do not seem to take care about cloned routes.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
he world - major ones are gated
interpretation and cisco interpretation)
we (as KAME) will try to improve the behavior, like non-working ones
get rejected on ifconfig time or such.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
about 5 to 8 packets were sent with IPComp
> applied, but I never saw any return or ack packets for
> netperf.
are there any strange number increase in netstat -sn on receiver side?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
in/output ends, because we will see data stream with different sizes.
- zlib memory management - heavy use of malloc?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
pc_syscalls.c side... hold on.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
need some change in uipc_syscalls.c side... hold on.
this diff is taken against 4.2-RELEASE (in kame tree), sorry.
also i need to say that i ran no tests (i have no environment).
uipc_syscalls.c change: make very sure to nuke file descriptor on errors
uipc_socket.c ch
>Looks good to me (although the patch is mixed in with a bunch
>of other crud). I've tested it out locally and will commit it
>unless there are any objections.
it is because of cvs issue. the important portion is below.
itojun
@@ -320,11 +359,8 @@ soaccept(so, n
quot; presented above.
(it will only happen you are very unlucky - it is timing issue)
BIND 9.1.1rc1 now includes workaround (no assert).
itojun
> 727. [port] Work around OS bug where accept() succeeds but
>fails to fill in the peer ad
y broken before I get it, why bother giving it to me??
can we cancel sorwakeup() (happens on handshake completion)?
I believed not.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
an return 0-length sockaddr,
standard-wise, at least for connection-oriented socket.
new behavior: return ECONNABORTED.
SUSv2 suggests this behavior. it is much safer as accept(2) will fail
so almost every application will go to error case (if you don't have
i'm not sure if it is legal to return zero-length sockaddr when
the kernel is given enough space to return the sockaddr.
(the last paragraph do not fit to TCP)
itojun
If address is not a null pointer, the address of the peer for the accepted
connection is stored in th
>Does anyone know how to disable IPv6 on a single interface, but leave the
>other interfaces IPv6 enabled? Is this even possible under freeBSD 4.2?
I've sent you a reply to your message on [EMAIL PROTECTED]
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &
lternatives for the above for Linux .
interface management ioctls are not standardized in any place
(as far as I know of). if you would like to support both *BSD and
linux, you definitely need some #ifdef in your code, or use
/sbin/ifconfig.
itojun
To Unsubscrib
packet by using IPsec transport mode against
gif-encapsulated packet, however, it does not look exactly the same.
if the other end is picky about packet format, they may drop it
because it does not conform to RFC2401.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
they'd give you
subnets...
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
J is good location. ;-)
I guess the operational cost is too high for us, and there are way
too high possibility for abuse. you know, iijlab have only few people
and they all are dead busy :-)
itojun@I'm not speaking for my company.
To Unsubscribe: send mail to [EMAIL P
> > it does a return(0) and does not free the mbuf. I checked -current
>> > > and it is still like that.
will correct it. thanks for reporting.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>> > will correct it. thanks for reporting.
http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r1=1.135&r2=1.136
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
reebsd behavior (return 0-length sockaddr) was also wrong,
it kills a set of applications including sendmail and BIND910.
new freebsd behavior (ECONNABORTED) is at least SUSv2 conformant,
and I expect it to be the behavior of other stacks.
itojun
To Unsubscribe: send
need to do something for
other sys/net* families. maybe we need another per-domain/per-socket
flag for this?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>I'll do it right now if itojun doesn't mind (to save him a task :-) )
>and get authorization from Jordan to commit.
please go ahead, i can review the diff if you want me to.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ne
t;considered ready enough.
KAME does mobile-ip6 only. we don't do mobile-ip4.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ip6_forward is in sys/netinet6/ip6_forward.c.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
would be better we can see all-kernel implementation sooner,
that uses normal socket system calls. otherwise it will be hard
for normal programmers to use it...
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ck that compiled binary
package on IPv4/v6 dual stack machine. if configure checks for the
presense of AF_INET6 support on build machine, the compiled binary
package won't support IPv6 on IPv4/v6 dual stack machine.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED
>Is there:
> - a way to make FreeBSD display a discovered PMTU?
netstat -rnal (or something alike)?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ockaddr_in6 *)sa)->sin6_addr, 16);
break;
default:
errx(1, "unknown address family %d", sa->sa_family);
}
you don't need to know what kind of address family is supported by
the kernel underneath, in this code fragment.
itojun
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
bragged
>about FreeBSD running rock solid :0(.
checking - did you have kernel panics in kernel IPsec code (then pls
send-pr), or you are just talking about an example?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ular card (crypto portion of course).
i have got no response at all.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
s, due to buffer size management, as well as variable-length
packed struct .
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
panic
- FreeBSD 4.2-RELEASE + KAME SNAP 200104xx has problem, with kernel
panic
if you can get a kernel stack trace on panic, it would be really useful.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ddr.sin_add16[1] = ifp->if_index.
>Please tell me its significance & how it is useful & why u have chosen to use as such.
http://orange.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION
(see section 1.3)
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
dialup, DaemonPortOptions
will choke while your modem line is not connected.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>Well, I have had the same problem. The solution was in removing IPv6
>support. I have not done any futher investigations.
please file a bug report to sendmail.org.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
apsulating twice with the "gif and IPsec tunnel mode"
setup, and the setup won't interoperate with other box.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
real reason.
i believe this is not the real reason, as multiple SPD entry works
fine here (and other places). so i'm trying to understand what
differentiates your setup and my setup.
so, please send us every configuration you have. preferably
not the me
xperimental
set of code. if your setup works with plain FreeBSD 4.3-RELEASE,
and if it is a network for production use, i'd suggest you to use
4.3-RELEASE instead of SNAP kit.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ne
y.c
revision 1.185 change the situation?
(pls grab the latest tree via anoncvs)
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
packet filter/NAT code, so unifying packet classifier is a
big big job. try looking at amount of #ifdefs in ipfilter, altq
and kame ipsec code.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
hout tunnelling... :-)
if you have various commercial vendor routers, please try to decipher
what they are doing internally about it, from the manuals.
maybe it gives you a good hint (or bad hint).
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
IPFILTER and I have encouraged others to do the
>same so that you guys can concentrate on IPFILTER and don't have
>to bother with IPFW etc.
i (or we) have never picked a single preferred filtering code for us,
i guess.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
. the
behavior has been there, and it should still work.
i'd suggest you to use bpf for both inbound and outbound instead
itojun
PS: i've committed a change to ecn code. hope the fix corrects the behavior.
thanks for reporting.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
not work?
similarly to 2, you MUST specify the outgoing scope identifier, like
"telnet linklocal%if0".
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ithin sys/netinet6/icmp6.c:icmp6_input(), icmp6_rip6_input()
is called. rtadvd(8) listens to raw IPv6 socket (IPPROTO_ICMPV6)
and accepts data through the socket.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
INK.
for the routing entries used by gif multi desination mode, rt_gateway
field is not distinguishable (if it is outer addr or inner addr).
also i guess it unsuitable to compare with NBMA networks, as with
most of the NBMA networks i guess rt_gateway field takes an
>I just put the patch for merging latest KAME into FreeBSD:
> http://www.imasy.or.jp/~ume/ipv6/test/freebsd5-kame20010528-20010604.diff.gz
thanks!
itojun
sys/kern/uipc_mbuf2.c
PULLDOWN_STAT cases are just for debugging and should be unnecessary
for FreeBSD-c
tic tunnelling is likely to get deprecated
in the near future. so if you are serious about implementing/
using it, i'd suggest looking at ISATAP instead.
draft-ietf-ngtrans-isatap-01.txt
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
are at this moment using 1-bit mbuf flag to remember which mbuf
is authenticated or not. this way, we cannot handle tunelled AH case.
check out the latest manpage for a little bit better description:
http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/man/man4/ipsec.4
itojun
tivity
- seeing certain packet
- not related to command/activity, looks like some sort of timer issue
- whatever
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
re a lot of
applications that does not.
also, with AF_UNIX, {NI,AI}_NUMERIC{HOST,SERV} does not have proper
interpretation. you will need to pick some interpretation (maybe
you may want to follow what NRL did for linux glibc/NRL IPv6 stack)
again, if i were you i
eally necessary.
try to diagnose if the packets are going through the ethernet
interface, by using tcpdump on real ethernet device.
("tcpdump -n -i fxp0" if you are using fxp0 as ether interface)
do you happen to have an packet filter on these nodes, o
cessary for us)
on KAME tree, but not on *BSD-current nor *BSD official releases.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
most never raised voice, or okay so
far) with varargs. what's the difference in passing "control" arg
in m->m_nextpkt from varargs? it's cryptic to the same degree.
there's no big difference. it's the matter of taste and you are
e
jumbogram means patckets with >= 2^16 bytes.
usual terminology confusion. in this thread, it should mean
GbE jumbo frames - we need to understand the meaning of the word
in context dependent manner...
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ticast packet filter initialization.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
automatic tunnels as mentioned in
RFC1933 (which uses IPv4 compatible address).
to configure tunnel endpoint for configured IPv6-over-IPv4 tunnels,
use gifconfig(8).
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
# ifconfig gif0 up
# ifconfig gif0 inet6 fe80:: -alias
# ifconfig gif0 inet6 fe80::8007:54 prefixlen 64 alias
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ree. there are a lot of
other warnings i see from kernel compilation. why don't you attack
other folks as well.
itojun
PS: i have unsubscribed from the list. i can't take this stress any more.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>yes itojun, you are right with your remark, on the other side I don't
>see by all available RFC's about tunneling IPv6 over IPv4, how
>can somebody perform it, without such a Link Local Address!
>(In this sense it is very relevant what JINMEI, Tatuya wrote)
rol the behavior of policy lookups. it has nothing to do
with "privileged port" (port number < 1024).
if you need more discussions you'd need to specify the line numberes
for the code you are worrying about.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
platform? from cc: it seems to be freebsd,
but which revision?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
herefore, i agree with enabling RES_INSECURE1 by default.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
in the kernel?)
itojun
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
output, on both ends
- netstat -rn output, on both ends
- simple network diagram (like intermediate routers) between both ends
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
did you try running these benchmarks on loopback interface?
(i.e. sender and receiver on the same node)
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
vior (returning a real sockaddr)?
again, *BSD never worked right (in terms of SUSv2 definition of
"right"). see Stevens "unix network programming" section I
mentioned earlier in this thread.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
d work on both
IPv4-only, IPv6-only and IPv4/v6 dual stack kernels, by using
getaddrinfo(3) and getnameinfo(3). you do not need to check if you
write applications properly.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
above questions are not
specific to IPv6, but is a question against 4.4BSD network stack.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ay is in inner header, and gif(4) multi-destination mode
uses it to determinte outer header).
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
t;ifconfig gif# create".
not sure if gif# has a good usage model. if you type "ifconfig gif#
create" you have little idea about the new interface name, hence you
can't configure it after the command (think of the case where you put
the command into /etc/rc.
>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 #... :-)
t? like you want to setup a tricky VPN gateway?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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
ery 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.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
s to be passed around, otherwise
we can't know which protocol we are processing (think of raw ip header
processing, like rip_input).
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
see it for yourself.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/protosw.h
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/protosw.h
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/protosw.h
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
varargs, therefore, it is misleading to say "many freebsd hackers".
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>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"
be evaluated under certain
interface's context).
4 is also incorrect. SPD is implemented as a radix tree, separate
from IPv4 (or IPv6) routing table. therefore, it has nothing
to do with normal routing table.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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
herefore, i agree with enabling RES_INSECURE1 by default.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
s effects and
>compatibility against existing applications.
correct. i've quoted the wrong portion.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
truct llinfo_nd6)
on other OSes we call nd6_nud_hint() in a useful way. please do not
remove it. (more diffs between OSes = more pain for us)
itojun
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
91 matches
Mail list logo
