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/listinfo/freebsd-net
To unsubscribe, send any mail
() 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]
in the kernel?)
itojun
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
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
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
: 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
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
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
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
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)
for configured tunnels, there's
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
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
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
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).
itojun
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
nor *BSD official releases.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
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 won't go there.
itojun
To Unsubscribe: send mail
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
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, or between them?
if so, remove them.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
.
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.local).
itojun
To Unsubscribe: send mail
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 unsubscribe freebsd-net in the body of the message
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-current
(), 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
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
(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 meta-script like ${ipaddr-c}. we need what you have
configured exactly.
itojun
To Unsubscribe: send mail
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-net in the body of the message
?
(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
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
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]
with unsubscribe freebsd-net
with other box.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
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
.
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 unsubscribe freebsd-net in the body of the message
against 4.4BSD network stack.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
(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
/network/ipsec/#ipf-interaction
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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
;
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
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]
with "unsubscribe freebsd-net" in the body of the message
or =
the
present implementation of free BSD kernel does not forward the ipv6 packe=
ts.
regards
which IPv6 implementation are you looking at? if you look at
the latest code (like freebsd 4.2-RELEASE or something), you will find
ip6_forward is in sys/netinet6/ip6_forward.c.
itojun
-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
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-net" in the body of the message
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 mail to [EMAIL PROTECTED
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 PROTECTED]
with "unsubscribe freebs
capsulated 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
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 Unsubscribe: send mail to [EMAIL
: 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
error check in userland appication, that's problem in application).
itojun
To Unsubscribe: send mail to [EMAIL
he 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 the sockaddr structure pointed to by address, and
the length of this address is stored in the object pointed to by
a
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
on.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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 change: return ECONNABORTED
itojun
Index: kern
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, nam)
so
u 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 address of the accepted
connection, b
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
- 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
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
rking 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
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
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 PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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 Unsubscribe: send mail to [EMAIL PROTECTED
61 matches
Mail list logo
