if ipv6_gateway_enable is also
set (as per rfc4861).
All you need is something like ifconfig_em0_ipv6=inet6 accept_rtadv
Great, it works!
I spoke a little too soon, I could not connect to a remote host until I did
some pings, eg..
maarsy-acq:~telnet -NK6 ipv6.google.com 80
Trying 2404:6800
On 29/03/2011, at 19:05, Sergey Kandaurov wrote:
This is repeatable after a reboot, I haven't experienced with FreeBSD 8.x.
I would assume an NDP communication problem or some such,
it would be interesting to see this sort of traffic, also ifconfig and
ndp -a output.
Grr.. I had to
On 29/03/2011, at 22:04, Bernd Walter wrote:
Grr.. I had to reinstall today because I forgot to create a swap partition
and now I can't reproduce the problem :(
NDP effectively replaces ARP for IPv6.
Like ARP it is also learning by received packets and not only by direct
query and because
this sort of traffic, also ifconfig and
ndp -a output.
Grr.. I had to reinstall today because I forgot to create a swap partition
and now I can't reproduce the problem :(
NDP effectively replaces ARP for IPv6.
Like ARP it is also learning by received packets and not only by direct
query
is also
set (as per rfc4861).
All you need is something like ifconfig_em0_ipv6=inet6 accept_rtadv
Great, it works!
I spoke a little too soon, I could not connect to a remote host until I did
some pings, eg..
maarsy-acq:~telnet -NK6 ipv6.google.com 80
Trying 2404:6800:8004::68...
^C
hosts ignore rtadv packets if ipv6_gateway_enable is also
set (as per rfc4861).
All you need is something like ifconfig_em0_ipv6=inet6 accept_rtadv
Great, it works!
I spoke a little too soon, I could not connect to a remote host until I did
some pings, eg..
maarsy-acq:~telnet -NK6 ipv6
On Tue, Mar 29, 2011 at 11:43:57PM +1030, Daniel O'Connor wrote:
It is running a fairly old FreeBSD (6.x..), maybe there are bugs there..
I don't think there are general bugs about neighbor discovery in FreeBSD
since the beginning, but NIC drivers might have multicast bugs and
although you are
switches in plastic routers support it as well.
IPv4 multicast and IPv6 multicast is very similar, but they use non
colliding MAC ranges, so pure IPv4 multicast switches are not a problem
for IPv6 multicast, but I'm a bit worried that some cheap devices have
alpha quality IPv6 multicast support
Hi,
I am trying to get a -CURRENT box to get an IPv6 address via RTADV, however I
am not having any luck.
I have tried the following in rc.conf :-
ipv6_enable=YES
ipv6_gateway_enable=YES
ifconfig_em0_ipv6=RTADV
(the last one I haven't seen before but it didn't seem to have an effect anyway
On 28 March 2011 16:55, Daniel O'Connor dar...@dons.net.au wrote:
Hi,
I am trying to get a -CURRENT box to get an IPv6 address via RTADV, however I
am not having any luck.
I have tried the following in rc.conf :-
ipv6_enable=YES
ipv6_gateway_enable=YES
ifconfig_em0_ipv6=RTADV
(the last
On 29/03/2011, at 1:37, Sergey Kandaurov wrote:
1) ipv6_enable is obsolete in HEAD, see UPDATING.
Ahh UPDATING, of course, thanks :)
2) Normally hosts ignore rtadv packets if ipv6_gateway_enable is also
set (as per rfc4861).
All you need is something like ifconfig_em0_ipv6=inet6
is something like ifconfig_em0_ipv6=inet6 accept_rtadv
Great, it works!
I spoke a little too soon, I could not connect to a remote host until I did
some pings, eg..
maarsy-acq:~telnet -NK6 ipv6.google.com 80
Trying 2404:6800:8004::68...
^C
maarsy-acq:~ping6 metatron
PING6(56=40+8+8 bytes) 2001
I had occasion to think about this, and I was wondering if someone is
working to add
either or both of these features, Intel's hardware supports it, it does not
seem that
hard to add, or am I missing something?
Cheers,
Jack
___
On Wed, 20 Oct 2010, Jack Vogel wrote:
Hi,
I had occasion to think about this, and I was wondering if someone is
working to add
either or both of these features, Intel's hardware supports it, it does not
seem that
hard to add, or am I missing something?
Strange that I had been thinking of
to it. TSO is a TCP segmentation
so it also is a matter of IPv6 allowing it to do so, at least that is my
present understanding.
SCTP offload can only be handled in the igb and ixgbe drivers, none of
the em hardware can do it (at least not as of today).
Personally its TSO that I care most about
suppose you should prefix it with inet6 keyword.
There are 2 examples in rc.conf (search for Sample IPv6).
Ah!
It didn't occur to me that I might need TWO inet6's! I'll give that a go
when
I play with this again tomorrow.
It's just one inet6; put there what you would pass
in rc.conf (search for Sample IPv6).
Ah!
It didn't occur to me that I might need TWO inet6's! I'll give that a go
when
I play with this again tomorrow.
It's just one inet6; put there what you would pass to ifconfig on the
command line. The fact that ifconfig defaults to inet
Hi
IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):
$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen
128
$ route -n add -inet6 default 2001::
On 10/15/2010 11:04 AM, Mark Murray wrote:
Hi
IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):
$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen
128
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/15/2010 11:04, Mark Murray wrote:
Hi
IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):
$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:
On Fri, Oct 15, 2010 at 07:04:47PM +0100, Mark Murray wrote:
Hi
IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):
$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:::::2 2001::
Alexey Shuvaev writes:
gifconfig_gif0_ipv6=2001:::::2 2001:::::1
prefixlen 128
I suppose you should prefix it with inet6 keyword.
There are 2 examples in rc.conf (search for Sample IPv6).
Ah!
It didn't occur to me
IPv6).
Ah!
It didn't occur to me that I might need TWO inet6's! I'll give that a go when
I play with this again tomorrow.
It's just one inet6; put there what you would pass to ifconfig on the
command line. The fact that ifconfig defaults to inet is the
problem leading to more confusion
prefixlen 64
It's likely that you need to add inet6 before fe80 there:
ifconfig_bridge0_ipv6=inet6 fe80::2%bridge0 prefixlen 64
Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem.
I'm glad to hear that, although now I have a sinking feeling about the
state
=inet6 fe80::2%bridge0 prefixlen 64
Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem.
--
Bruce Cran
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
before fe80 there:
ifconfig_bridge0_ipv6=inet6 fe80::2%bridge0 prefixlen 64
Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem.
I'm glad to hear that, although now I have a sinking feeling about the
state of the -current code. In your OP you said you updated to
-current, what
I updated my router to the latest -CURRENT yesterday and now I'm getting an
error on startup from ifconfig saying the the IPv6 addresses I've configured
are wrong (bad value). The settings I've got in rc.conf are:
# IPv4 setup
defaultrouter=a.b.c.d
gateway_enable=YES
ifconfig_vr0=a.b.c.d
On 04/24/10 17:54, Bruce Cran wrote:
I updated my router to the latest -CURRENT yesterday
Did you run mergemaster after you upgraded? How old/what version of
FreeBSD did you upgrade from?
and now I'm getting an
error on startup from ifconfig saying the the IPv6 addresses I've configured
code.
No, in this case devd(8) invokes rc.d/netif as it is created. The
old code does ifconfig inet6 -ifdisabled before it becomes up
when ipv6_prefer=YES, and the new code always does ifconfig inet6
ifdisabled when no ifconfig_gif0_ipv6 line, respectively.
do Note that IPv6 link-local
, consistent user interface.
do Note that IPv6 link-local addresses (those that start with fe80::) will
do be automatically configured whenever possible. You may need to remove
do IPv6 link-local addresses manually using ifconfig(8) ...
No, the ifdisabled flag set via devd(8) prevents
Doug Barton do...@freebsd.org wrote
in 4bca2b55.9000...@freebsd.org:
do I strongly disagree with this because some IPv6
do applications depend on link-local address automatically added on
do cloned interfaces
do
do Can you please give a configuration example that would create the
do
Now we're getting somewhere. :)
On 04/18/10 12:04, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bca2b55.9000...@freebsd.org:
do I strongly disagree with this because some IPv6
do applications depend on link-local address automatically added on
do cloned interfaces
do
To add a little history to the discussion:
In June of last year you posted a patch to the -rc list to update our
treatment of IPv6 configuration in rc.d and bring it on par with how we
configure IPv4. At the time I did not give your patch adequate review,
and subsequent to it being committed
Nigel:
Here is a patch for your issue I think.
Its off of a head machine but I think it should apply. If not
let me know.
See if this does not fix the issue.
Thanks
R
Index: ip6_output.c
===
--- ip6_output.c(revision
Opps:
I was a little to quick, .. that one won't work.. but I
think this one will (need to have the right magic header
goo :-D)
Try this please (this one will build and actually do something :-D)
R
Index: ip6_output.c
===
---
round[tm] or is there some instability with IPv6 in
FreeBSD-current?
--
bye, Micha
I hate forms!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Has anyone else tried out the most basic IPv6 test: ndp -I iface and
then ping6 fe80::normal address without %iface extension? I was
greeted by recursion on a non-recursive lock. After some sleuthing,
I tried to determine what conditions could be tested for that would
indicate this must not call
On Sat, Oct 25, 2003 at 03:34:53AM +0900, Hajimu UMEMOTO wrote:
Hi,
I've just committed to switch Advanced Sockets API for IPv6 from
RFC2292 to RFC3542 (aka RFC2292bis). Though I believe this commit
doesn't break backward compatibility againt existing binaries, it
breaks backward
Hi,
I've just committed to switch Advanced Sockets API for IPv6 from
RFC2292 to RFC3542 (aka RFC2292bis). Though I believe this commit
doesn't break backward compatibility againt existing binaries, it
breaks backward compatibility of API.
Now, the applications which use Advanced Sockets API
Hello,
After upgrading a system to -CURRENT of yesterday night, making IPv6
connections to another host in the same subnet does not work (remains in
[connec] state). Some messing about with routes solved that, but it
panicked quickly thereafter. After a reboot it panicked again with a
similar
when capturing
locally, this packet appears before and after the ICMP6 echo request.
These packets seem to contain the ipv6 packet to be sent but offset incorrectly
and with the wrong data. The destination MAC address seems to be the start
of the ipv6 packet. What are these null I packets
Craig Rodrigues wrote:
Is anyone actively working on importing the latest IPv6 implementation
from KAME to CURRENT?
Not offically anyway, it seems.
SUZUKI Shinsuke [EMAIL PROTECTED] mentioned his plans on KAME
synchronisation:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=577922+582433
Hi,
On Sun, 10 Aug 2003 17:41:40 +0100
Matt [EMAIL PROTECTED] said:
matt ipv6_network_interfaces=xl1 lo0
This line should be `ipv6_network_interfaces=xl1 gif0'.
matt ipv6_ifconfig_xl1=fec0:0:0:1::1 prefixlen 64
matt ipv6_ifconfig_gif0=2001:470:1F00:::32F 2001:470:1F00:::32E prefixlen
Hi,
Is anyone actively working on importing the latest IPv6 implementation
from KAME to CURRENT? I am trying to port the sctp.org implementation
of SCTP to -CURRENT, and am getting hung up on the mismatch
between KAME's IPv6 implementation and -CURRENT's.
I am giving a shot at importing some
Hi,
I may have done something really stupid here but if I have I can not see what
it is. Basically I have some configuration in rc.conf to set up a gif tunnel
for ipv6. I have used the same config I used to use on 5.0-RELEASE a few
months ago but I removed that config when the tunnel broker I
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
matt ipv6_network_interfaces=xl1 lo0
This line should be `ipv6_network_interfaces=xl1 gif0'.
Heh. I KNEW it was going to be something stupid I forgot about. Yes it works
fine now.
Thank you very much!
Regards, Matt.
--
email: [EMAIL PROTECTED] -
On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
about mallocing data w/ a lock aquired.
dmesg output:
malloc() of 64 with the following non-sleepablelocks held:
exclusive sleep mutex netisr lock r = 0
Hiten Pandya wrote:
On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
about mallocing data w/ a lock aquired.
dmesg output:
malloc() of 64 with the following non-sleepablelocks held:
exclusive
On Sat, 21 Jun 2003, Hiten Pandya wrote:
On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
about mallocing data w/ a lock aquired.
dmesg output:
malloc() of 64 with the following
held:
exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215
malloc() of 64 with the following non-sleepablelocks held:
exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215
If I disable IPv6 in /etc/rc.conf, the above warnings don't appear.
I tried
= 0 (0xc0271890) locked @ net/netisr.c:215
malloc() of 64 with the following non-sleepablelocks held:
exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215
If I disable IPv6 in /etc/rc.conf, the above warnings don't appear.
I tried to follow the code path in IPv6's
). I know there's probably a better way to accomplish that,
but couldn't think of any at the time so that's what I did :)
Anyway, when I was done, I reset the MTU on my ethernet interface back
to 1500. IPv4 is working fine, but IPv6 is still acting like I have a
low MTU set. All IPv6 TCP
that,
but couldn't think of any at the time so that's what I did :)
Anyway, when I was done, I reset the MTU on my ethernet interface back
to 1500. IPv4 is working fine, but IPv6 is still acting like I have a
low MTU set. All IPv6 TCP connections are limiting the MSS to around 28
bytes of data per packet
Hi all,
I make a patch to support IPv6 for libradius.
This is a quick hack.
Unfortunatly, I can't test it over IPv6 environment, only IPv4 environment.
Because, I don't have a RADIUS which supports IPv6 access.
This patch extents radius.conf(5) format.
- specify 10 or more RADISU (original
Hi,
On Mon, 20 Jan 2003 20:48:56 -0500 (EST)
Andrew Gallatin [EMAIL PROTECTED] said:
gallatin The ifdefs are there because the linux hack^W OS uses a different
gallatin syscall table on each platform, with a different ABI (eg, the same
gallatin syscall may take 3 args on x86 and 2 on alpha).
and a
dwmalone syscall wrapper (extending Ian's work in this area). I took these
dwmalone patches far enough to get the linux version of telnet to speak IPv6.
Your approach of having syscall wrapper reduces the overhead of
copyout(), and seems good. I thought that doing copyout() is slightly
into my patch, then replaced the
previous one. How about this?
http://www.imasy.or.jp/~ume/FreeBSD/linux-ipv6.diff
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe
Hajimu UMEMOTO writes:
dwmalone2) The patches wouldn't compile on the alpha 'cos of some
dwmaloneifdefs in the linux emulation code. I just hadn't got around
dwmaloneto resolving this.
Oops, thank you for pointing this out. It seems that other than
linux_connect() are
Hi,
I wrote an IPv6 support for Linux sym. I've tested it with RHL8's
ftp(1) and ports/www/linux-phoenix, and it seems nicely running with
both an IPv4 and an IPv6.
You can obtain my patch from:
http://www.imasy.or.jp/~ume/FreeBSD/linux-ipv6.diff
Please review it.
Sincerely
On Mon, Jan 20, 2003 at 12:49:26AM +0900, Hajimu UMEMOTO wrote:
I wrote an IPv6 support for Linux sym. I've tested it with RHL8's
ftp(1) and ports/www/linux-phoenix, and it seems nicely running with
both an IPv4 and an IPv6.
You can obtain my patch from:
http://www.imasy.or.jp/~ume
Hi,
On Wed, 30 Oct 2002 16:50:20 +0100
Ronald van der Pol [EMAIL PROTECTED] said:
Ronald.vanderPol On Tue, Oct 29, 2002 at 00:38:39 +0900, Hajimu UMEMOTO wrote:
Please review it. If there is no objection, I'll commit it at next
weekend.
Ronald.vanderPol Reviewed -stable, looks OK. Would
On Tue, Oct 29, 2002 at 00:38:39 +0900, Hajimu UMEMOTO wrote:
Please review it. If there is no objection, I'll commit it at next
weekend.
Reviewed -stable, looks OK. Would be nice to have this fix. Thanks.
rvdp
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Hi,
Current rc doesn't support IPv6 setup for ipfilter. So I made the
patches. The former is for both 4-STABLE and 5-CURRENT. In addition
to the former one, 5-CURRENT requires the latter one for
/etc/rc.d/ipfilter.
This patch is not for /etc/rc.network6 as usual IPv6 related setups
.ip6.v6only
net.inet6.ip6.v6only: 1
The prefered way to handle IPv6 as well as IPv4 connects you should
listen to both addresses.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail
FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep 9
10:23:22 EDT 2002
[EMAIL PROTECTED]:/admins/obj/admins/src/sys/FEMME i386
foo.c:
#include stdio.h
#include stdlib.h
#include stdarg.h
#include string.h
#include netdb.h
#include unistd.h
#include netinet/in.h
#include
THis works fine on DP-1.
So it broke somewhere between then and now.
-Trish
--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD
To
sysctl net.inet6.ip6.v6only=0
-Trish
--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD
To Unsubscribe: send mail to [EMAIL PROTECTED]
On Wed, 18 Sep 2002 21:44:33 -0400 (EDT),
Trish Lynch [EMAIL PROTECTED] said:
sysctl net.inet6.ip6.v6only=0
This should also work:
*** foo.c.orig Thu Sep 19 12:05:04 2002
--- foo.c Thu Sep 19 12:05:56 2002
***
*** 14,19
--- 14,20
struct sockaddr_in6 addr;
I've got the following panic a few times using IPv6 on a recent
-current (while scping a file usually):
panic: mutex inp not owned at ../../../netinet/tcp_output.c:131
panic: from debugger
the trace back seems to involve getting an ICMP message and then
calling tcp code.
David.
#0
All,
I just cvsuped and built a new kernel and world last night, updating from a
2 week old -current that was working fine. Now, TCP seems broken. After I
open and close a single TCP session, any further TCP opens result in either
a failure (connection refused) or a system deadlock. ICMP
Hi,
I've just committed to change an IPv4-mapped IPv6 address off by
default.
The existing applications may be affected this change. The
applications which depend on an IPv4-mapped IPv6 address will become
listen only an IPv6 socket.
Apache2 is known having this problem. You may need
Hi,
On Thu, 25 Jul 2002 12:50:49 -0400
Jeroen C.van Gelderen [EMAIL PROTECTED] said:
jeroen May I ask what motivated this change?
Yes. There is discussion that an IPv4-mapped IPv6 address has
potential security weakness in developping application and/or
operating servers. NetBSD's default
Umemoto-san,
May I ask what motivated this change?
-J
On Thursday, Jul 25, 2002, at 11:51 US/Eastern, Hajimu UMEMOTO wrote:
Hi,
I've just committed to change an IPv4-mapped IPv6 address off by
default.
The existing applications may be affected this change. The
applications which depend
The following patch fixes this problem for me. When a tcp6 was
encountered then v6bind is set to 1 and was not being cleared
after the check to ignore IPv6. This patch may not be entirely
correct, but its simple and does fix the problem I reported
earlier. The v4bind check that should have
This worked 3 days ago but I just upgraded to -CURRENT from today
and its not quite working now. If you have tcp6 lines in your
inetd.conf but do not have IPv6 enabled in the kernel your inetd
will stop adding services after it encounters the first line with
a tcp6 in it:
mysystem# inetd -d
ADD
Hello:
Do FreeBSD-5.0 developers plan to implement divert sockets for IPv6
and ip6fw ?
It would be difficult to do it ?
Thanks.
JFRH.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Hi folks--
It's been pointed out to me that a program I wrote (net/pchar in ports)
can't compile on -CURRENT. After a little poking around, I've narrowed
the problem down to the following test case:
tomcat:bmah% cat foo.cc
#include sys/types.h
#include sys/param.h
#include netdb.h
#include
On Sun, Jul 01, 2001 at 09:33:27PM +0200, Gerhard Sittig wrote:
On Sun, Jul 01, 2001 at 10:54 -0700, matt wrote:
I don't think ipf is complete in its ipv6 support yet.You can
use ipfw instead.
Ipf has been supporting IPv6 for quite some time. It's just that
one has to enable
Hi,
On yesterdays -current I'm having some problems making ipfilter
DTRT with ipv6 packets:
bm# ipfstat -6io
block out quick on xl0 from any to any
block out quick on vx0 from any to any
block in quick on xl0 from any to any
block in quick on vx0 from any to any
(passing ipv6 traffic
I don't think ipf is complete in its ipv6 support
yet.You can use ipfw instead.
==
WWW.XGFORCE.COM
The Next Generation Load Balance and
Fail Safe Server Clustering Software
for the Internet.
==
- Original Message
db
The kernel config is just GENERIC + IPSEC. IPV6 is configured and running.
Thanks,
skd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Sun, Jul 01, 2001 at 10:54 -0700, matt wrote:
I don't think ipf is complete in its ipv6 support yet.You can
use ipfw instead.
Ipf has been supporting IPv6 for quite some time. It's just that
one has to enable this support in the Makefile.
$ grep INET6 contrib/ipfilter/Makefile
#INET6
Thus spake Michael Harnois ([EMAIL PROTECTED]):
Building the kernel without INET6 makes this error go away. cvsup as
of about two hours ago.
Is it fixed now?
Ume has committed a fix to the mbuf locks recently.
Alex
(I just got the same panic with a different traceback with a kernel
from
At Wed, 13 Jun 2001 15:45:03 + (UTC),
Michael Harnois wrote:
Building the kernel without INET6 makes this error go away. cvsup as
of about two hours ago.
Do you define WITNESS or not?
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
gee - being like SysV is more comprehensible than worrying about IPv6
-mo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Mar 26, 2001 at 04:46:45PM -0500, Mike O'Dell wrote:
gee - being like SysV is more comprehensible than worrying about IPv6
Perhaps if you're living in 1994 :-)
Kris
PGP signature
As I already wrote in a prior statement, Alfred Perlstein and
I ported TI_RPC to FreeBSD. It compiles with recent CURRENT.
http://www.attic.ch/patches/rpc.diff_01152001-2.sh.tgz
All you have to do is to start rpc.diff_01152001-2.sh in the
source tree and make a buildworld and then run
Dans votre courrier du 25 Jan 16:49 vous ecrivez :
In your previous mail you wrote:
It is not impossible to support IPv6 NFS without switching to TI-RPC,
INRIA IPv6 has the code (IIRC).
= this code was ported to FreeBSD 4.2. I'll give more details as soon as
I am back to my
Hi,
So, I have merged in the newest libc changes and fixed some
buildworld issues. It still needs some _THREAD_SAFE fixes I
guess, cause we build now thread-safe libc per default. But
we can do this later ...
Go into your CURRENT source tree and execute the shell archive,
it will create the
Argl, the correct URL is of course:
http://www.attic.ch:80/patches/rpc.diff_04022001.sh.tgz
Cheers:
Martin
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone:
that NFS can be made IPv6 aware). What is the latest on that?
:
: rvdp
I don't think anyone is working on IPV6 issues at the moment.
(I have cc-ed [EMAIL PROTECTED])
This came up about half a year ago in the KAME snap mailing list.
I think the conclusion was: a migration from &quo
is a pre-requisite for making NFS IPv6 aware.
So, I was wondering whether a switch to TI-RPC is planned. I know
it is a major task.
I don't think this is within the KAME-project scope. On NetBSD, the
NetBSD crowd has done this almost a year ago (I believe) and NFS over
IPv6 works just great on N
I don't think this is within the KAME-project scope. On NetBSD, the
NetBSD crowd has done this almost a year ago (I believe) and NFS over
IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot
from the NetBSD work, reducing the major-ness of the task?
The above is correct
On Thu, 25 Jan 2001 [EMAIL PROTECTED] wrote:
I don't think this is within the KAME-project scope. On NetBSD, the
NetBSD crowd has done this almost a year ago (I believe) and NFS over
IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot
from the NetBSD work, reducing
In your previous mail you wrote:
It is not impossible to support IPv6 NFS without switching to TI-RPC,
INRIA IPv6 has the code (IIRC).
= this code was ported to FreeBSD 4.2. I'll give more details as soon as
I am back to my office (ie. next week).
However, if you
The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6)
is TI-RPC based, and it was done by NetBSD guys not KAME guys.
Sorry, I was not clear. The question about moving towards TI-RPC was
directed to freebsd-current. Just out of interest. No critisism intended
Hi,
Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find
the latest snapshot here:
http://www.attic.ch/rpc.diff_01114001.tgz
Patches and bugfixes are welcome.
Martin
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX
* Martin Blapp [EMAIL PROTECTED] [010125 11:07] wrote:
Hi,
Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find
the latest snapshot here:
http://www.attic.ch/rpc.diff_01114001.tgz
Patches and bugfixes are welcome.
Can you post a summary of how you've done it
At 25 Jan 2001 19:08:14 GMT,
Martin Blapp wrote:
http://www.attic.ch/rpc.diff_01114001.tgz
I cannot fetch it. Gone into attic? :-)
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Hi, I'll place a new version tomorrow on the server.
be patient untill then.
Martin
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax:
201 - 300 of 461 matches
Mail list logo
